On Wed, Dec 1, 2010 at 12:15 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > 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? 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@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