Re: can't oom-kill zap the victim's memory?
From: Raymond Jennings
Date: Sun Sep 20 2015 - 15:07:56 EST
On 09/20/15 11:05, Linus Torvalds wrote:
On Sun, Sep 20, 2015 at 5:56 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
In this case the workqueue thread will block.
What workqueue thread?
pagefault_out_of_memory ->
out_of_memory ->
oom_kill_process
as far as I can tell, this can be called by any task. Now, that
pagefault case should only happen when the page fault comes from user
space, but we also have
__alloc_pages_slowpath ->
__alloc_pages_may_oom ->
out_of_memory ->
oom_kill_process
which can be called from just about any context (but atomic
allocations will never get here, so it can schedule etc).
I think in this case the oom killer should just slap a SIGKILL on the
task and then back out, and whatever needed the memory should just wait
patiently for the sacrificial lamb to commit seppuku.
Which, btw, we should IMO encourage ASAP in the context of the lamb by
having anything potentially locky or semaphory pay attention to if the
task in question has a fatal signal pending, and if so, drop everything
and run like hell so that the task can cough up any locks or semaphores.
So what's your point? Explain again just how do you guarantee that you
can take the mmap_sem.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
Also, I observed that a task in the middle of dumping core doesn't
respond to signals while it's dumping, and I would guess that might be
the case even if the task receives a SIGKILL from the OOM handler. Just
a potential observation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/