public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: kbuild test robot <fengguang.wu@intel.com>,
	kbuild-all@01.org, linux-kernel@vger.kernel.org,
	mark.rutland@arm.com
Subject: Re: [rcu:rcu/next 30/45] include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier_depends'
Date: Thu, 19 Oct 2017 11:07:25 +0100	[thread overview]
Message-ID: <20171019100725.GD30231@arm.com> (raw)
In-Reply-To: <20171017164409.GP3521@linux.vnet.ibm.com>

Hi Paul [adding Mark],

On Tue, Oct 17, 2017 at 09:44:09AM -0700, Paul E. McKenney wrote:
> Good point -- I should have removed that as soon as you posted the
> update.  I have removed it now.

Thanks!

> 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.

> 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

> 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()".
> 
> 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.

> 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.
> 
> 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@arm.com>

Will

  reply	other threads:[~2017-10-19 10:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-14 23:29 [rcu:rcu/next 30/45] include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier_depends' kbuild test robot
2017-10-17 16:14 ` Will Deacon
2017-10-17 16:44   ` Paul E. McKenney
2017-10-19 10:07     ` Will Deacon [this message]
2017-10-19 10:27       ` Mark Rutland
2017-10-19 17:46         ` Paul E. McKenney
2017-10-20 12:44           ` Mark Rutland
2017-10-20 16:50             ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171019100725.GD30231@arm.com \
    --to=will.deacon@arm.com \
    --cc=fengguang.wu@intel.com \
    --cc=kbuild-all@01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox