linux-kernel - Re: [rcu:rcu/next 30/45] include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 20 Oct 2017 13:44:07 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Will Deacon <will.deacon@....com>,
        kbuild test robot <fengguang.wu@...el.com>,
        kbuild-all@...org, linux-kernel@...r.kernel.org
Subject: Re: [rcu:rcu/next 30/45] include/linux/compiler.h:343:2: error:
 implicit declaration of function 'smp_read_barrier_depends'

On Thu, Oct 19, 2017 at 10:46:57AM -0700, Paul E. McKenney wrote:
> 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@....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 <will.deacon@....com>
> > 
> > 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?

rcu/alpha-cocci looks good to me.

Thanks for organising this!

Mark.