On Wed, Dec 1, 2010 at 11:29 AM, CAI Qian <caiqian@xxxxxxxxxx> 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?
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href