Re: [PATCH] futex: replace bare barrier() with a READ_ONCE()

2016-03-01 Thread Jianyu Zhan
On Wed, Mar 2, 2016 at 2:39 PM, Darren Hart wrote: > I believe you are correct with respect to the retry and while condition being > an > appropriate place for the application of READ_ONCE. The question is why is > this > preferred to the existing barrier()? I suggest: > > While barrier() is a f

Re: [PATCH] futex: replace bare barrier() with a READ_ONCE()

2016-03-01 Thread Darren Hart
On Wed, Mar 02, 2016 at 10:31:18AM +0800, Jianyu Zhan wrote: > On Wed, Mar 2, 2016 at 9:37 AM, Darren Hart wrote: > > read_once will use a *volatile assignment instead of calling barrier() > > directly for a word size argument. > > > > With weak statements like "apparently" (above) and "could be"

Re: [PATCH] futex: replace bare barrier() with a READ_ONCE()

2016-03-01 Thread Jianyu Zhan
On Wed, Mar 2, 2016 at 9:37 AM, Darren Hart wrote: > read_once will use a *volatile assignment instead of calling barrier() > directly for a word size argument. > > With weak statements like "apparently" (above) and "could be" (from the > original > post: This patch replaces this bare barrier() w

Re: [PATCH] futex: replace bare barrier() with a READ_ONCE()

2016-03-01 Thread Darren Hart
On Tue, Mar 01, 2016 at 08:44:48AM +0800, Jianyu Zhan wrote: > On Tue, Mar 1, 2016 at 6:22 AM, Darren Hart wrote: > > You've mention it causes problems a few times, but you do not specify what > > problem it causes or how it manifests. > > > > Is this a theoretical bug, or have you experienced a f

Re: [PATCH] futex: replace bare barrier() with a READ_ONCE()

2016-02-29 Thread Jianyu Zhan
On Tue, Mar 1, 2016 at 6:22 AM, Darren Hart wrote: > You've mention it causes problems a few times, but you do not specify what > problem it causes or how it manifests. > > Is this a theoretical bug, or have you experienced a failure case. If so, how > did this manifest? Do you have a reproducer w

Re: [PATCH] futex: replace bare barrier() with a READ_ONCE()

2016-02-29 Thread Darren Hart
On Mon, Feb 29, 2016 at 07:41:33PM +0800, Jianyu Zhan wrote: > Commit e91467ecd1ef ("bug in futex unqueue_me") introduces a barrier() > in unqueue_me(), to address a pointer aliasing problem in s390x, between > q->lock_ptr and local variable lock_ptr. > > Since there is a retry logic to reload q->

[PATCH] futex: replace bare barrier() with a READ_ONCE()

2016-02-29 Thread Jianyu Zhan
Commit e91467ecd1ef ("bug in futex unqueue_me") introduces a barrier() in unqueue_me(), to address a pointer aliasing problem in s390x, between q->lock_ptr and local variable lock_ptr. Since there is a retry logic to reload q->lock_ptr into local variable lock_ptr, s390x generates code that aliase