Date: Fri, 30 Jun 2017 10:31:26 -0700
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
        Will Deacon <will.deacon@arm.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrea Parri <parri.andrea@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        priyalee.kushwaha@intel.com,
        =?utf-8?Q?Stanis=C5=82aw?= Drozd <drozdziak1@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>, ldr709@gmail.com,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Josh Triplett <josh@joshtriplett.org>, Nicolas Pitre <nico@linaro.org>,
        Krister Johansen <kjlx@templeofstupid.com>,
        Vegard Nossum <vegard.nossum@oracle.com>, dcb314@hotmail.com,
        Wu Fengguang <fengguang.wu@intel.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Rik van Riel <riel@redhat.com>, Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@kernel.org>, Luc Maranget <luc.maranget@inria.fr>,
        Jade Alglave <j.alglave@ucl.ac.uk>
Subject: Re: [GIT PULL rcu/next] RCU commits for 4.13
Reply-To: paulmck@linux.vnet.ibm.com
References: <20170629113848.GA18630@arm.com>
 <Pine.LNX.4.44L0.1706291132310.1571-100000@iolanthe.rowland.org>
 <20170629181126.GA2393@linux.vnet.ibm.com>
 <20170630025126.jhflffwrnedlqrmz@tardis>
 <20170630040241.GR2393@linux.vnet.ibm.com>
 <20170630051654.wsoog5nlwtmbh5y2@tardis>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170630051654.wsoog5nlwtmbh5y2@tardis>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20170630173126.GZ2393@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1279
Lines: 30

On Fri, Jun 30, 2017 at 01:16:54PM +0800, Boqun Feng wrote:
> On Thu, Jun 29, 2017 at 09:02:41PM -0700, Paul E. McKenney wrote:

[ . . . ]

> > > > o	kernel/task_work.c task_work_run()
> > > > 	Seems to rely on the acquire semantics only.  This is to handle
> > > 
> > > I think this one needs the stronger semantics, the smp_mb() is just
> > > hidden in the cmpxchg() before the raw_spin_unlock_wait() ;-)
> > > 
> > > cmpxchg() sets a special value to indicate the task_work has been taken,
> > > and raw_spin_unlock_wait() must wait until the next critical section of
> > > ->pi_lock(in task_work_cancel()) could observe this, otherwise we may
> > > cancel a task_work while executing it.
> > 
> > But either way, replacing the spin_unlock_wait() with a spin_lock()
> > immediately followed by a spin_unlock() should work correctly, right?
> > 
> 
> Yep ;-) I was thinking about the case that we kept spin_unlock_wait()
> with a simpler acquire semantics, and if so, we would actually have to
> do the replace. But I saw your patchset of removing it, so it doesn't
> matter.

Well, there is a fair amount of review and testing between now and
it getting in (assuming that it in fact does get in), but I do very
much appreciate the vote of confidence!  ;-)

							Thanx, Paul