From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754127AbdJSRrN (ORCPT ); Thu, 19 Oct 2017 13:47:13 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:56712 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752811AbdJSRrB (ORCPT ); Thu, 19 Oct 2017 13:47:01 -0400 Date: Thu, 19 Oct 2017 10:46:57 -0700 From: "Paul E. McKenney" To: Mark Rutland Cc: Will Deacon , kbuild test robot , kbuild-all@01.org, linux-kernel@vger.kernel.org Subject: Re: [rcu:rcu/next 30/45] include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier_depends' Reply-To: paulmck@linux.vnet.ibm.com References: <201710150732.Bveddu9V%fengguang.wu@intel.com> <20171017161458.GA20985@arm.com> <20171017164409.GP3521@linux.vnet.ibm.com> <20171019100725.GD30231@arm.com> <20171019102741.xvv2avrtnif46o6i@lakrids.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171019102741.xvv2avrtnif46o6i@lakrids.cambridge.arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17101917-0024-0000-0000-000002E536A8 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007919; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000238; SDB=6.00933475; UDB=6.00470181; IPR=6.00713763; BA=6.00005651; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017610; XFM=3.00000015; UTC=2017-10-19 17:46:59 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101917-0025-0000-0000-000045C806E0 Message-Id: <20171019174656.GY3521@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-19_09:,, 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-1707230000 definitions=main-1710190245 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 19, 2017 at 11:27:42AM +0100, Mark Rutland wrote: > On Thu, Oct 19, 2017 at 11:07:25AM +0100, Will Deacon wrote: > > On Tue, Oct 17, 2017 at 09:44:09AM -0700, Paul E. McKenney wrote: > > > I am happy to take the patches, but let's make sure that I am up to > > > speed on the current state and dependencies. Here is my current > > > scorecard, please double-check: > > > > > > 1. Your patcheset from October 12th for nuking lockless_dereference(): > > > lkml.kernel.org/r/1507818377-7546-1-git-send-email-will.deacon@arm.com > > > > Yes, that's correct -- those three patches are up-to-date. Very good, applied these on top of v4.14-rc4. > > > 2. Mark Rutland's prepatory patchset for nuking ACCESS_ONCE(): > > > -rcu, v4.14-rc4..251e52a951b0 ("rcutorture: formal: prepare for > > > ACCESS_ONCE() removal"). Depends on #1. > > > > I don't think there's a dependency on #1 here, for the difference it makes. > > Mark has also updated his series on this branch (Acks and fixes), so you > > should pull this instead of picking patches: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git access-once-prep And pulled these in, but capitalizing the "kill". > > > 3. My mop-up patchset for two remaining occurrences of > > > ACCESS_ONCE() in documentation and a comment. No real urgency > > > or dependencies here. -rcu, 11721220e6bf ("treewide: Kill off > > > remaining ACCESS_ONCE()". I split these and applied them on top of the access-once-prep branch. Then I merged #1. > > > 4. Mark's scripted patchset for nuking ACCESS_ONCE(), which will > > > be run my Linus, hopefully at the end of the merge window that > > > takes #1 and #2. > > > > Just FYI, but Mark has also put #3 and #4 on this branch: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git access-once > > > > but those two patches haven't changed since the list posting. > > Given #4 will need to be regenerated, there's not much point picking #3 > from there, but feel free to add my Ack! Good point, and so I added my patches into your prep series. And applied your acks, thank you! > > > 5. My patchset for removing most smp_read_barrier_depends() > > > instances. -rcu, 11721220e6bf..b7a74661caeb ("keyring: Remove > > > now-redundant smp_read_barrier_depends()"). These depend on > > > #1, and many of them are non-trivial, so they will likely > > > straggle in over time as they accumulate sufficient testing > > > and/or acks. Three of them are ready to go in. But they -do- depend on #1 above, at least for Alpha users. So maybe I should target them for the merge window following the removal of ACCESS_ONCE(). > > > 6. Removing smp_read_barrier_depends() from the InfiniBand drivers. > > > These use cases are a bit obscure, so may take some time. > > > Andrea Parri kindly volunteered to chase these down, but could > > > use responses to his queries to the InfiniBand maintainers. > > > These will likely depend on #1, though as Peter Zijlstra pointed > > > out, there is no record of any Alpha systems using InfiniBand, > > > so maybe they can be treated independently. > > > > > > Did I get that right? If I have the wrong patches or am missing some > > > dependencies, please let me know. Otherwise, I will create a branch > > > including available patches from 1-3 and 5 above. > > > > > > Are people comfortable with my pushing the straightforward stuff > > > (that is, excluding #5 and #6) into the next merge window? > > > > That works for me, and you can have my Ack if you need it: > > > > Acked-by: Will Deacon > > Sounds good to me, too. OK, this is now in -rcu on branch rcu/alpha. I then pulled in your commit 8e0bfe6e14e9 ("treewide: kill off ACCESS_ONCE()") on top of this at rcu/alpha-cocci. Again, the smp_read_barrier_depends() waits until this is in-tree. Did I get it right, or did I miss something? Thanx, Paul