On 02/11, Oleg Nesterov wrote:
>
> On 02/11, Tetsuo Handa wrote:
> >
> > (Asking Oleg this time.)
>
> Well, sorry, I ignored the previous discussion, not sure I understand you
> correctly.
>
> > > Though, more serious behavior with this reproducer is (B) where the system
> > > stalls forever without kernel messages being saved to /var/log/messages .
> > > out_of_memory() does not select victims until the coredump to pipe can make
> > > progress whereas the coredump to pipe can't make progress until memory
> > > allocation succeeds or fails.
> >
> > This behavior is related to commit d003f371b2701635 ("oom: don't assume
> > that a coredumping thread will exit soon"). That commit tried to take
> > SIGNAL_GROUP_COREDUMP into account, but actually it is failing to do so.
>
> Heh. Please see the changelog. This "fix" is obviously very limited, it does
> not even try to solve all problems (even with coredump in particular).
>
> Note also that SIGNAL_GROUP_COREDUMP is not even set if the process (not a
> sub-thread) shares the memory with the coredumping task. It would be better
> to check mm->core_state != NULL instead, but this needs the locking. Plus
> that process likely sleeps in D state in exit_mm(), so this can't help.
>
> And that is why we set SIGNAL_GROUP_COREDUMP in zap_threads(), not in
> zap_process(). We probably want to make that "wait for coredump_finish()"
> sleep in exit_mm() killable, but this is not simple.
on a cecond thought, perhaps it makes sense to set SIGNAL_GROUP_COREDUMP
anyway, even if a CLONE_VM process participating in coredump is not killable.
I'll recheck tomorrow.
> Sorry for noise if the above is not relevant.
>
> Oleg.
--
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>