Re: oom is broken in mmotm 2010-11-09-15-31 tree?

[Michel Lespinasse <walken@google.com>]

On Wed, Dec 1, 2010 at 12:15 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Dec 1, 2010 at 11:29 AM, CAI Qian <caiqian@redhat.com> wrote:
>>>
>>> Hi, just a head-up. When testing oom for this tree, my workstation is
>>> immediately having no response to ssh, Desktop actions and so on apart
>>> from ping. I am trying to bisect but looks like git public server is
>>> having problem.
>>
>> This turned out that it was introduced by,
>>
>>  d065bd810b6deb67d4897a14bfe21f8eb526ba99
>>  mm: retry page fault when blocking on disk transfer
>>
>> It was reproduced by:
>> 1) ssh to the test box.
>> 2) try to trigger oom a few times using a malloc program there.
>
> Interesting. That commit is not supposed to make any semantic
> difference at all. And even if we do end up in the retry path, the
> arch/x86/mm/fault.c code is very explicitly designed so that it
> retries only _once_.
>
> Michel, any ideas? I could see problems with the mmap_sem if
> VM_FAULT_OOM is set at the same time as VM_FAULT_RETRY, but I can't
> see how that could ever happen.
>
> Anybody?
>
> CAI, can you get any output from sysrq-W when this happens?

Things are known to be broken between
d065bd810b6deb67d4897a14bfe21f8eb526ba99 and
d88c0922fa0e2c021a028b310a641126c6d4b7dc. CAI, do you have that in
your tree ? Also, can you test at
d065bd810b6deb67d4897a14bfe21f8eb526ba99 with
d88c0922fa0e2c021a028b310a641126c6d4b7dc cherry-picked on ?

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>