public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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