Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752453AbdF3Rbf (ORCPT ); Fri, 30 Jun 2017 13:31:35 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:49521 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751710AbdF3Rbe (ORCPT ); Fri, 30 Jun 2017 13:31:34 -0400 Date: Fri, 30 Jun 2017 10:31:26 -0700 From: "Paul E. McKenney" To: Boqun Feng Cc: Alan Stern , Will Deacon , Linus Torvalds , Andrea Parri , Linux Kernel Mailing List , priyalee.kushwaha@intel.com, =?utf-8?Q?Stanis=C5=82aw?= Drozd , Arnd Bergmann , ldr709@gmail.com, Thomas Gleixner , Peter Zijlstra , Josh Triplett , Nicolas Pitre , Krister Johansen , Vegard Nossum , dcb314@hotmail.com, Wu Fengguang , Frederic Weisbecker , Rik van Riel , Steven Rostedt , Ingo Molnar , Luc Maranget , Jade Alglave Subject: Re: [GIT PULL rcu/next] RCU commits for 4.13 Reply-To: paulmck@linux.vnet.ibm.com References: <20170629113848.GA18630@arm.com> <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) X-TM-AS-GCONF: 00 x-cbid: 17063017-0008-0000-0000-00000252BEA6 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007298; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00880954; UDB=6.00439220; IPR=6.00661108; BA=6.00005448; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016025; XFM=3.00000015; UTC=2017-06-30 17:31:31 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17063017-0009-0000-0000-000035DD9D0C Message-Id: <20170630173126.GZ2393@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-30_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300274 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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