From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754564AbdCQAfW (ORCPT ); Thu, 16 Mar 2017 20:35:22 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:36766 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752838AbdCQAfU (ORCPT ); Thu, 16 Mar 2017 20:35:20 -0400 Date: Thu, 16 Mar 2017 17:35:05 -0700 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: <20170317003505.GA13135@fury> References: <20161213083638.938898295@infradead.org> <20161213085730.289714424@infradead.org> <20161217005045.GG62123@f23x64.localdomain> <20170222140316.GT6515@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170222140316.GT6515@twins.programming.kicks-ass.net> 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 Wed, Feb 22, 2017 at 03:03:16PM +0100, Peter Zijlstra wrote: > On Fri, Dec 16, 2016 at 04:50:45PM -0800, Darren Hart wrote: > > 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? > > Yes I think so, since __unqueue_futex() dereferences lock_ptr and does > stores in the memory it points to, those stores must not happen _after_ > we NULL lock_ptr itself. Are you referring to the q->lock_ptr = NULL in mark_wake_futex()? So the concern is parallel mark_wake_futex() calls on the same futex? But that can't happen because the call is wrapped by the hb locks. In what scenario can this occur? > futex_wait(), which calls unqueue_me() could have had a spurious wakeup > and observe our NULL store and 'free' the futex_q. Urg. Spurious wakeups... yes... OK, still necessary. Gah. :-( -- Darren Hart VMware Open Source Technology Center