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.
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>