From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934181AbcLQAvD (ORCPT ); Fri, 16 Dec 2016 19:51:03 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:49334 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933737AbcLQAu4 (ORCPT ); Fri, 16 Dec 2016 19:50:56 -0500 Date: Fri, 16 Dec 2016 16:50:45 -0800 From: Darren Hart To: Peter Zijlstra Cc: tglx@linutronix.de, mingo@kernel.org, juri.lelli@arm.com, rostedt@goodmis.org, xlpang@redhat.com, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com, jdesfossez@efficios.com, bristot@redhat.com, paulmck@linux.vnet.ibm.com Subject: Re: [PATCH -v4 04/10] futex: Use smp_store_release() in mark_wake_futex() Message-ID: <20161217005045.GG62123@f23x64.localdomain> References: <20161213083638.938898295@infradead.org> <20161213085730.289714424@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213085730.289714424@infradead.org> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 13, 2016 at 09:36:42AM +0100, Peter Zijlstra wrote: > Since the futex_q can dissapear the instruction after assigning NULL, > this really should be a RELEASE barrier. That stops loads from hitting > dead memory too. > +Paul McKenney Per the introduction of the comment below from: f1a11e0 futex: remove the wait queue I believe the intent was to ensure the plist_del in ... the previous __unqueue_futex(q) ... from getting ahead of the smp_store_release added here, which could result in q being destroyed by the waking task before plist_del can act on it. Is that right? The comment below predates the refactoring which hid plist_del under the __unqueue_futex() making it a bit less clear as to the associated plist_del: However, since this comment, we have moved the wake-up out of wake_futex through the use of wake queues (wake_up_q) which now happens after the hb lock is released (see futex_wake, futex_wake_op, and futex_requeue). Is this race still a valid concern? > Signed-off-by: Peter Zijlstra (Intel) > --- > kernel/futex.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1288,8 +1288,7 @@ static void mark_wake_futex(struct wake_ > * memory barrier is required here to prevent the following > * store to lock_ptr from getting ahead of the plist_del. > */ > - smp_wmb(); > - q->lock_ptr = NULL; > + smp_store_release(&q->lock_ptr, NULL); > } > > static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_q *top_waiter, > > > -- Darren Hart Intel Open Source Technology Center