From: Darren Hart <dvhltc@us.ibm.com>
To: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Peter Zijlstra <peterz@infradead.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Nick Piggin <npiggin@suse.de>, Ingo Molnar <mingo@elte.hu>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ulrich Drepper <drepper@gmail.com>,
"Hansen, Dave" <haveblue@us.ibm.com>
Subject: Re: [PATCH v2] futex: remove rw parameter from get_futex_key()
Date: Tue, 05 Jan 2010 12:41:31 -0800 [thread overview]
Message-ID: <4B43A3FB.9050009@us.ibm.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1001051108150.26884@sister.anvils>
Hugh Dickins wrote:
> On Tue, 5 Jan 2010, KOSAKI Motohiro wrote:
>> From c3e2dfdff84b9b720e646fd6dd3c38fff293c7e6 Mon Sep 17 00:00:00 2001
>> From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> Date: Tue, 5 Jan 2010 11:33:00 +0900
>> Subject: [PATCH] futex: remove rw parameter from get_futex_key()
>>
>> Currently, futex have two problem.
>>
>> A) current futex doesn't handle private file mappings properly.
>>
>> get_futex_key() use PageAnon() to distinguish file and anon. it can
>> makes following bad scenario.
>>
>> 1) thread-A call futex(private-mapping, FUTEX_WAIT). it makes to
>> sleep on file mapping object.
>> 2) thread-B write a variable and it makes cow.
>> 3) thread-B call futex(private-mapping, FUTEX_WAKE). it wake up
>> sleeped thread on the anonymous page. (but it's nothing)
>>
Excellent test case, thank you! Would you consider preparing a patch to
futextest?
http://git.kernel.org/?p=linux/kernel/git/dvhart/futextest.git;a=summary
I did some experimentation here and found that:
o The test works if the *_PRIVATE op codes are used.
This is because the futex keys are generated using only the virtual
address of the page, which doesn't change on a COW.
o If the waiter writes to the val first, it works.
This forces the COW before the waiter generates it's futex key.
So the waiter's key is generated based on the page cache page address
for shared futexes when the value hasn't been written to prior to wait.
The only scenario where I could think of wanting this behavior is if
another process were to try and wake the waiter via the same file backed
page. However, as I understand it, the re-use of the same page for
unwritten-to private pages is an optimization and can't be relied upon.
So this scenario is out. Another would be to use the futex as a very
simple wait queue where the value is never changed. In this case
however, the implementation is racy as the value check is effectively
negated, so this use case is also out.
As such, I see no reason not to always use VERIFY_WRITE and force a COW
prior to generating the futex_key for shared futexes. It is not
necessary for private futexes however as they use only the virtual address.
I am not sure on whether or not it makes sense to avoid the VERIFY_WRITE
on the private futexes. Could be it is just more code for negligible
benefit. Thoughts?
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
next prev parent reply other threads:[~2010-01-05 20:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-24 9:29 [PATCH] futex: Fix ZERO_PAGE cause infinite loop KOSAKI Motohiro
2009-12-24 9:39 ` Peter Zijlstra
2009-12-24 17:15 ` Ulrich Drepper
2009-12-25 1:51 ` KOSAKI Motohiro
2009-12-30 16:03 ` Hugh Dickins
2010-01-05 7:32 ` [PATCH v2] futex: remove rw parameter from get_futex_key() KOSAKI Motohiro
2010-01-05 11:21 ` Hugh Dickins
2010-01-05 20:41 ` Darren Hart [this message]
2010-01-06 2:27 ` KOSAKI Motohiro
2010-01-06 23:14 ` Darren Hart
2010-01-06 23:29 ` Darren Hart
2010-01-13 10:30 ` [tip:core/urgent] futexes: Remove " tip-bot for KOSAKI Motohiro
2010-01-07 6:32 ` [PATCH] mips,mm: Reinstate move_pte optimization KOSAKI Motohiro
2010-01-11 10:15 ` Ralf Baechle
2010-01-05 18:04 ` [PATCH] futex: Fix ZERO_PAGE cause infinite loop Darren Hart
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=4B43A3FB.9050009@us.ibm.com \
--to=dvhltc@us.ibm.com \
--cc=drepper@gmail.com \
--cc=haveblue@us.ibm.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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