On Thu, 1 Nov 2012, Luigi Semenzato wrote:
> > @@ -706,11 +693,11 @@ void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask,
> > return;
> >
> > /*
> > - * If current has a pending SIGKILL, then automatically select it. The
> > - * goal is to allow it to allocate so that it may quickly exit and free
> > - * its memory.
> > + * If current has a pending SIGKILL or is exiting, then automatically
> > + * select it. The goal is to allow it to allocate so that it may
> > + * quickly exit and free its memory.
> > */
> > - if (fatal_signal_pending(current)) {
> > + if (fatal_signal_pending(current) || current->flags & PF_EXITING) {
> > set_thread_flag(TIF_MEMDIE);
> > return;
> > }
>
> I tested this change with my load and it appears to also prevent the deadlocks.
>
> I have a question though. I thought only one process was allowed to
> be in TIF_MEMDIE state, but I don't see anything that prevents this
> code (before or after the change) from setting the flag in multiple
> processes. Is this a problem?
>
The code you've quoted above, prior to being changed by the patch, allows
any thread with a fatal signal to have access to memory reserves, so it's
certainly not only one thread with TIF_MEMDIE set at a time (the oom
killer is not the only thing that can kill a thread). The goal of that
code is to ensure anything that has been killed can allocate successfully
wherever it happens to be running so that it can handle the signal, exit,
and free its memory. My patch is extending that for all threads that are
in the exit path that happen to require memory to exit to prevent a
livelock.
--
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>