From: Peter Zijlstra <peterz@infradead.org>
To: Michel Lespinasse <walken@google.com>
Cc: linux-mm <linux-mm@kvack.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>,
Divyesh Shah <dpshah@google.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: FYI: mmap_sem OOM patch
Date: Thu, 08 Jul 2010 12:30:09 +0200 [thread overview]
Message-ID: <1278585009.1900.31.camel@laptop> (raw)
In-Reply-To: <20100707231134.GA26555@google.com>
On Wed, 2010-07-07 at 16:11 -0700, Michel Lespinasse wrote:
> What happens is we end up with a single thread in the oom loop (T1)
> that ends up killing a sibling thread (T2). That sibling thread will
> need to acquire the read side of the mmap_sem in the exit path. It's
> possible however that yet a different thread (T3) is in the middle of
> a virtual address space operation (mmap, munmap) and is enqueue to
> grab the write side of the mmap_sem behind yet another thread (T4)
> that is stuck in the OOM loop (behind T1) with mmap_sem held for read
> (like allocating a page for pagecache as part of a fault.
>
> T1 T2 T3 T4
> . . . .
> oom: . . .
> oomkill . . .
> ^ \ . . .
> /|\ ----> do_exit: . .
> | sleep in . .
> | read(mmap_sem) . .
> | \ . .
> | ----> mmap .
> | sleep in .
> | write(mmap_sem) .
> | \ .
> | ----> fault
> | holding read(mmap_sem)
> | oom
> | |
> | /
> \----------------------------------------------/
So what you do is use recursive locking to side-step a deadlock.
Recursive locking is poor taste and leads to very ill defined locking
rules.
One way to fix this is to have T4 wake from the oom queue and return an
allocation failure instead of insisting on going oom itself when T1
decides to take down the task.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-07-08 10:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-07 23:11 FYI: mmap_sem OOM patch Michel Lespinasse
2010-07-08 0:16 ` KOSAKI Motohiro
2010-07-08 1:11 ` KOSAKI Motohiro
2010-07-08 9:02 ` Peter Zijlstra
2010-07-08 9:24 ` KOSAKI Motohiro
2010-07-08 9:35 ` Peter Zijlstra
2010-07-08 9:51 ` KOSAKI Motohiro
2010-07-08 10:30 ` Peter Zijlstra [this message]
[not found] ` <AANLkTimLSnNot2byTWYuIHE8rhGLXbl1zKsQQhmci1Do@mail.gmail.com>
2010-07-08 10:49 ` Peter Zijlstra
2010-07-08 10:57 ` KOSAKI Motohiro
2010-07-08 11:02 ` Peter Zijlstra
2010-07-08 11:06 ` KOSAKI Motohiro
2010-07-08 11:23 ` Peter Zijlstra
2010-07-09 1:31 ` KOSAKI Motohiro
2010-07-12 21:47 ` David Rientjes
2010-07-13 0:14 ` KOSAKI Motohiro
2010-07-13 21:08 ` David Rientjes
[not found] ` <AANLkTimArLPHrxHNEejiXKNYk9To6qsjglbgzyypXP-c@mail.gmail.com>
2010-07-08 12:43 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1278585009.1900.31.camel@laptop \
--to=peterz@infradead.org \
--cc=dpshah@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=walken@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).