On Tue 10-10-17 19:58:53, Tetsuo Handa wrote:
> Commit 5d17a73a2ebeb8d1 ("vmalloc: back off when the current task is
> killed") revealed two bugs [1] [2] that were not ready to fail vmalloc()
> upon SIGKILL. But since the intent of that commit was to avoid unlimited
> access to memory reserves, we should have checked tsk_is_oom_victim()
> rather than fatal_signal_pending().
>
> Note that even with commit cd04ae1e2dc8e365 ("mm, oom: do not rely on
> TIF_MEMDIE for memory reserves access"), it is possible to trigger
> "complete depletion of memory reserves"
How would that be possible? OOM victims are not allowed to consume whole
reserves and the vmalloc context would have to do something utterly
wrong like PF_MEMALLOC to make this happen. Protecting from such a code
is simply pointless.
> and "extra OOM kills due to depletion of memory reserves"
and this is simply the case for the most vmalloc allocations because
they are not reflected in the oom selection so if there is a massive
vmalloc consumer it is very likely that we will kill a large part the
userspace before hitting the user context on behalf which the vmalloc
allocation is performed.
I have tried to explain this is not really needed before but you keep
insisting which is highly annoying. The patch as is is not harmful but
it is simply _pointless_ IMHO.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
