Messages in this thread | | | Date | Thu, 5 Oct 2017 12:49:18 +0200 | From | Michal Hocko <> | Subject | Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed" |
| |
On Thu 05-10-17 19:36:17, Tetsuo Handa wrote: > On 2017/10/05 16:57, Michal Hocko wrote: > > On Wed 04-10-17 19:18:21, Johannes Weiner wrote: > >> On Wed, Oct 04, 2017 at 03:32:45PM -0700, Andrew Morton wrote: > > [...] > >>> You don't think they should be backported into -stables? > >> > >> Good point. For this one, it makes sense to CC stable, for 4.11 and > >> up. The second patch is more of a fortification against potential > >> future issues, and probably shouldn't go into stable. > > > > I am not against. It is true that the memory reserves depletion fix was > > theoretical because I haven't seen any real life bug. I would argue that > > the more robust allocation failure behavior is a stable candidate as > > well, though, because the allocation can fail regardless of the vmalloc > > revert. It is less likely but still possible. > > > > I don't want this patch backported. If you want to backport, > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way. > > On 2017/10/04 17:33, Michal Hocko wrote: > > Now that we have cd04ae1e2dc8 ("mm, oom: do not rely on TIF_MEMDIE for > > memory reserves access") the risk of the memory depletion is much > > smaller so reverting the above commit should be acceptable. > > Are you aware that stable kernels do not have cd04ae1e2dc8 ?
yes
> We added fatal_signal_pending() check inside read()/write() loop > because one read()/write() request could consume 2GB of kernel memory.
yes, because this is easily trigerable by userspace.
> What if there is a kernel module which uses vmalloc(1GB) from some > ioctl() for legitimate reason? You are going to allow such vmalloc() > calls to deplete memory reserves completely.
Do you have any specific example in mind? If yes we can handle it. -- Michal Hocko SUSE Labs
| |