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