[GIT PULL] RCU changes for v6.17

[GIT PULL] RCU changes for v6.17

[Neeraj Upadhyay]

Hello Linus,

When the merge window opens, please pull this RCU update.

The following changes since commit 86731a2a651e58953fc949573895f2fa6d456841:

  Linux 6.16-rc3 (2025-06-22 13:30:08 -0700)

are available in the Git repository at:

  ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/rcu/linux.git tags/rcu.release.v6.17

for you to fetch changes up to cc1d1365f0f414f6522378867baa997642a7e6b2:

  Merge branches 'rcu-exp.23.07.2025', 'rcu.22.07.2025', 'torture-scripts.16.07.2025', 'srcu.19.07.2025', 'rcu.nocb.18.07.2025' and 'refscale.07.07.2025' into rcu.merge.23.07.2025 (2025-07-23 21:42:20 +0530)

Please note that below patch, which was initially picked for RCU next
testing has been removed, as it gave false positives with RCU torture
test. 

https://lore.kernel.org/rcu/20250429134304.3824863-6-frederic@kernel.org/

----------------------------------------------------------------
RCU pull request for v6.17

This pull request contains the following branches:

rcu-exp.23.07.2025

  - Protect against early RCU exp quiescent state reporting during exp
    grace period initialization.

  - Remove superfluous barrier in task unblock path.

  - Remove the CPU online quiescent state report optimization, which is
    error prone for certain scenarios.

  - Add warning for unexpected pending requested expedited quiescent
    state on dying CPU.

rcu.22.07.2025

  - Robustify rcu_is_cpu_rrupt_from_idle() by using more accurate
    indicators of the actual context tracking state of a CPU.

  - Handle ->defer_qs_iw_pending field data race.

  - Enable rcu_normal_wake_from_gp by default on systems with <= 16 CPUs.

  - Fix lockup in rcu_read_unlock() due to recursive irq_exit() calls.

  - Refactor expedited handling condition in rcu_read_unlock_special().

  - Documentation updates for hotplug and GP init scan ordering,
    separation of rcu_state and rnp's gp_seq states, quiescent state
    reporting for offline CPUs.

torture-scripts.16.07.2025

  - Cleanup and improve scripts : remove superfluous warnings for disabled
    tests; better handling of kvm.sh --kconfig arg; suppress some confusing
    diagnostics; tolerate bad kvm.sh args; add new diagnostic for build
    output; fail allmodconfig testing on warnings.

  - Include RCU_TORTURE_TEST_CHK_RDR_STATE config for KCSAN kernels.

  - Disable default RCU-tasks and clocksource-wdog testing on arm64.

  - Add EXPERT Kconfig option for arm64 KCSAN runs.

  - Remove SRCU-lite testing.

rcutorture.16.07.2025

  - Start torture writer threads creation after reader threads to handle
    race in SRCU-P scenario.

  - Add SRCU down_read()/up_read() test.

  - Add diagnostics for delayed SRCU up_read(), unmatched up_read(), print
    number of up/down readers and the number of such readers which
    migrated to other CPU.

  - Ignore certain unsupported configurations for trivial RCU test.

  - Fix splats in RT kernels due to inaccurate checks for BH-disabled
    context.

  - Enable checks and logs to capture intentionally exercised unexpected
    scenarios (too short readers) for BUSTED test.

  - Remove SRCU-lite testing.

srcu.19.07.2025

  - Expedite SRCU-fast grace periods.

  - Remove SRCU-lite implementation.

  - Add guards for SRCU-fast readers.

rcu.nocb.18.07.2025

  - Dump NOCB group leader state on stall detection.

  - Robustify nocb_cb_kthread pointer accesses.

  - Fix delayed execution of hurry callbacks when LAZY_RCU is enabled.

refscale.07.07.2025

  - Fix multiplication overflow in "loops" and "nreaders" calculations.

----------------------------------------------------------------
Artem Sadovnikov (1):
      refscale: Check that nreaders and loops multiplication doesn't overflow

Frederic Weisbecker (6):
      rcu/exp: Protect against early QS report
      rcu: Robustify rcu_is_cpu_rrupt_from_idle()
      rcu/nocb: Dump gp state even if rdp gp itself is not offloaded
      rcu/exp: Remove confusing needless full barrier on task unblock
      rcu/exp: Remove needless CPU up quiescent state report
      rcu/exp: Warn on QS requested on dying CPU

Joel Fernandes (5):
      rcu: Fix rcu_read_unlock() deadloop due to IRQ work
      rcu: Refactor expedited handling check in rcu_read_unlock_special()
      rcu: Document GP init vs hotplug-scan ordering requirements
      rcu: Document separation of rcu_state and rnp's gp_seq
      rcu: Document concurrent quiescent state reporting for offline CPUs

Neeraj Upadhyay (AMD) (1):
      Merge branches 'rcu-exp.23.07.2025', 'rcu.22.07.2025', 'torture-scripts.16.07.2025', 'srcu.19.07.2025', 'rcu.nocb.18.07.2025' and 'refscale.07.07.2025' into rcu.merge.23.07.2025

Paul E. McKenney (32):
      rcutorture: Print only one rtort_pipe_count splat
      rcutorture: Start rcu_torture_writer() after rcu_torture_reader()
      rcutorture: Make rcutorture_one_extend_check() account for hard IRQs
      rcutorture: Add tests for SRCU up/down reader primitives
      rcutorture: Pull rcu_torture_updown() loop body into new function
      rcutorture: Complain if an ->up_read() is delayed more than 10 seconds
      rcutorture: Check for ->up_read() without matching ->down_read()
      rcutorture: Check for no up/down readers at task level
      rcutorture: Print number of RCU up/down readers and migrations
      rcutorture: Drop redundant "insoftirq" parameters
      rcutorture: Make Trivial RCU ignore onoff_interval and shuffle_interval
      rcutorture: Make BUSTED scenario check and log readers
      torture: Suppress torture.sh "Zero time" messages for disabled tests
      torture: Permit multiple space characters in kvm.sh --kconfig argument
      torture: Make torture.sh KCSAN runs set CONFIG_RCU_TORTURE_TEST_CHK_RDR_STATE=y
      torture: Default --no-rcutasksflavors on arm64
      torture: Default --no-clocksourcewd on arm64
      rcu: Protect ->defer_qs_iw_pending from data race
      torture: Provide EXPERT Kconfig option for arm64 KCSAN torture.sh runs
      torture: Suppress "find" diagnostics from torture.sh --do-none run
      torture: Extract testid.txt generation to separate script
      torture: Add textid.txt file to --do-allmodconfig and --do-rcu-rust runs
      torture: Make torture.sh tolerate runs having bad kvm.sh arguments
      torture: Add "ERROR" diagnostic for testing kernel-build output
      torture: Make torture.sh --allmodconfig testing fail on warnings
      torture: Remove support for SRCU-lite
      rcutorture: Remove SRCU-lite scenarios
      rcutorture: Remove support for SRCU-lite
      srcu: Expedite SRCU-fast grace periods
      srcu: Remove SRCU-lite implementation
      checkpatch: Remove SRCU-lite deprecation
      srcu: Add guards for SRCU-fast readers

Tze-nan Wu (1):
      rcu: Fix delayed execution of hurry callbacks

Uladzislau Rezki (Sony) (2):
      rcu: Enable rcu_normal_wake_from_gp on small systems
      Documentation/kernel-parameters: Update rcu_normal_wake_from_gp doc

Zqiang (2):
      rcutorture: Fix rcutorture_one_extend_check() splat in RT kernels
      rcu/nocb: Fix possible invalid rdp's->nocb_cb_kthread pointer access

 Documentation/RCU/Design/Data-Structures/Data-Structures.rst |  33 ++++++
 Documentation/RCU/Design/Requirements/Requirements.rst       | 128 +++++++++++++++++++++++
 Documentation/admin-guide/kernel-parameters.txt              |   3 +-
 include/linux/srcu.h                                         |  54 ++--------
 include/linux/srcutiny.h                                     |   3 -
 include/linux/srcutree.h                                     |  38 -------
 kernel/rcu/rcutorture.c                                      | 356 +++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
 kernel/rcu/refscale.c                                        |  42 ++------
 kernel/rcu/srcutree.c                                        |   2 +
 kernel/rcu/tree.c                                            |  80 ++++++++++++---
 kernel/rcu/tree.h                                            |  13 ++-
 kernel/rcu/tree_exp.h                                        |  59 ++---------
 kernel/rcu/tree_nocb.h                                       |  10 +-
 kernel/rcu/tree_plugin.h                                     | 122 ++++++++++++++++++----
 kernel/rcu/tree_stall.h                                      |   3 +-
 scripts/checkpatch.pl                                        |   2 -
 tools/testing/selftests/rcutorture/bin/kvm-build.sh          |   2 +-
 tools/testing/selftests/rcutorture/bin/kvm.sh                |  15 +--
 tools/testing/selftests/rcutorture/bin/mktestid.sh           |  29 ++++++
 tools/testing/selftests/rcutorture/bin/torture.sh            |  78 +++++++++++---
 tools/testing/selftests/rcutorture/configs/rcu/BUSTED        |   3 +
 tools/testing/selftests/rcutorture/configs/rcu/CFLIST        |   1 -
 tools/testing/selftests/rcutorture/configs/rcu/SRCU-L        |  10 --
 tools/testing/selftests/rcutorture/configs/rcu/SRCU-L.boot   |   3 -
 24 files changed, 770 insertions(+), 319 deletions(-)
 create mode 100755 tools/testing/selftests/rcutorture/bin/mktestid.sh
 delete mode 100644 tools/testing/selftests/rcutorture/configs/rcu/SRCU-L
 delete mode 100644 tools/testing/selftests/rcutorture/configs/rcu/SRCU-L.boot

Re: [GIT PULL] RCU changes for v6.17

[Linus Torvalds]

On Fri, 25 Jul 2025 at 19:46, Neeraj Upadhyay
<Neeraj.Upadhyay@kernel.org> wrote:
>
> This pull request contains the following branches:
>
> rcu-exp.23.07.2025 [..]

I've pulled this, but I do have a request (or two, really)..

The octopus merges look cool, but they have the problem that if there
are subtle bugs introduced by interactions between branches, they are
a pain to bisect. So in general, I advise people to avoid them.

But the *real* thing I note is that merges are more subtle than normal
commits in the first place, and octopus merges are subtler still - and
your have no explanation at all outside of the 'merge X Y and Z into
ABC'.

Please write more of a commit message explaining what those branches
*are* that you are merging.

Which is the second part of the request: when you ask me to merge "the
following branches", the branch names are basically line noise. I'm
not in the least interested in seeing what the date of a branch is.
That adds no value.

So can you please instead describe the branches by what they do than
by some internal branch name you used. I made up my own "names" for
the sub-branches in the merge message, but it would be much nicer if
you did it in the pull request.

So, for example, I changed "rcu-exp.23.07.2025" to be "Expedited grace
period", which seems to be what that branch name was cryptically
trying to say.

            Linus

Re: [GIT PULL] RCU changes for v6.17

[pr-tracker-bot]

The pull request you sent on Sat, 26 Jul 2025 08:16:05 +0530:

> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/rcu/linux.git tags/rcu.release.v6.17

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2db4df0c09eeb209726261f43fc556360b38ec99

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] RCU changes for v6.17

[Paul E. McKenney]

On Wed, Jul 30, 2025 at 11:11:43AM -0700, Linus Torvalds wrote:
> On Fri, 25 Jul 2025 at 19:46, Neeraj Upadhyay
> <Neeraj.Upadhyay@kernel.org> wrote:
> >
> > This pull request contains the following branches:
> >
> > rcu-exp.23.07.2025 [..]
> 
> I've pulled this, but I do have a request (or two, really)..
> 
> The octopus merges look cool, but they have the problem that if there
> are subtle bugs introduced by interactions between branches, they are
> a pain to bisect. So in general, I advise people to avoid them.
> 
> But the *real* thing I note is that merges are more subtle than normal
> commits in the first place, and octopus merges are subtler still - and
> your have no explanation at all outside of the 'merge X Y and Z into
> ABC'.
> 
> Please write more of a commit message explaining what those branches
> *are* that you are merging.
> 
> Which is the second part of the request: when you ask me to merge "the
> following branches", the branch names are basically line noise. I'm
> not in the least interested in seeing what the date of a branch is.
> That adds no value.
> 
> So can you please instead describe the branches by what they do than
> by some internal branch name you used. I made up my own "names" for
> the sub-branches in the merge message, but it would be much nicer if
> you did it in the pull request.
> 
> So, for example, I changed "rcu-exp.23.07.2025" to be "Expedited grace
> period", which seems to be what that branch name was cryptically
> trying to say.

Apologies!  I missed the empty merge-commit commit log when reviewing
this pull request, and I should have spotted that.  :-(

As it happens, I will be sending the pull request for the v6.18 merge
window, so I will stop doing my usual octopus merges (hey, they *were*
cool!) and instead merge each branch separately, with each merge's commit
log giving a synopsis of the commits in the branch being merged.

If you have a best-practice series of merges example in mind, could you
please point me at it?

							Thanx, Paul

Re: [GIT PULL] RCU changes for v6.17

[Linus Torvalds]

On Wed, 30 Jul 2025 at 12:24, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> As it happens, I will be sending the pull request for the v6.18 merge
> window, so I will stop doing my usual octopus merges (hey, they *were*
> cool!) and instead merge each branch separately, with each merge's commit
> log giving a synopsis of the commits in the branch being merged.

Note that octopus merges aren't a no-no per se. Sometimes they make
perfect sense, particularly if there's a handful of really trivial
branches with just a commit or two each.

Then an octopus merge can be a really convenient way to avoid having
as many merges as you have "real" commits.

So don't take my comment as a "never use octopus merges".

Take it more as "octopus merges have some downsides, and making _any_
merge without an explanation for it in the commit message is bad".

The main downside of octopus merges really is just bisectability:
because even if the problem doesn't end up being the merge itself, an
octopus merge can make it fundamentally hard to do the "cut the
history in two roughly equal points for testing".

But again, that's not a problem if you have just a fairly small
handful of purely trivial commits.

So people just need to balance the "octopus merges are cool, and can
avoid pointless repeated silly small merges" with "octopus merges can
make for bisectability issues and should be avoided for anything even
halfway comples".

(Also, try *very* hard to avoid octopus merges when any conflicts
exist - even trivial ones. Octopus merges with conflict resolution
take "that's hard to follow" to a whole other level, to the point
where you really shouldn't even try).

> If you have a best-practice series of merges example in mind, could you
> please point me at it?

It's hard to give a good "typical" example, because I don't think
"typical" exists.

Sometimes a simple one-line merge message just stating "Misc fixes for
subsystem Xyz" really might be the "proper" merge message.

Because maybe that branch really had all just tiny uninteresting
fixes, and git shortlog entirely describes it all to the point that
writing anything more would just be wasting everybody's time.

Honestly, the merge messages you guys send me for *my* RCU merge are
fine - the only thing I ask for is that instead of describing the
branches with an esoteric branch name, you write them out for humans.

So having the header read "Improvements expedited RCU grace periods"
or something is just _soo_ much more understandable than
"rcu-exp.23.07.2025", wouldn't you agree?

As to the merge messages for *your* own merges, where you just put
several branches together in order to send the result to me: knowing
that there will be a more complete message in the upstream merge, I
think the main issue is to think about people who hit that merge
because they have some issue.

So again, it might be because somebody ends up hitting that merge
during bisection, or has some other reason why they are looking at
that merge in particular, rather than the "bigger picture" upstream
merge.

In other words, please write merge messages with the intended audience
in mind. They don't necessarily need to be the same kind of
full-fledged explanation that I want to explain why I'm merging (and
for people who follow the development process: people most definitely
look at the pull requests that come upstream, and it's informative to
not just me, but you find tech press etc looking at them too).

But you should at a minimum think about "what if somebody hits this
during a bisection". Give those random developers a clue about what is
going on. Don't just make it be that "Merge branch XYZ", because that
tells _outsiders_ so little.

Does that make sense as an answer?

Anyway, I'm happy to say that if you are looking for _examples_ of
merges, we have tons of them. I'm proud of the fact that I think
kernel commit messages in general are very good, and when I compare
them to other projects I feel like we tend to do a stellar job. And
I'm not just patting myself on the back, we have tons of good
examples.

So you can do a

    git log --merges

in general, and while you'll find some that just list branches, I
think most of them tend to be very good these days. Look at the
networking and bpf merges, for example (so typically Jakub and
Alexei). Or the SoC merges (Arnd), or the VFS merges (Christian
Brauner).

Or really most of them. I started looking for more names (the ones I
mentioned were people I already knew wrote good merge messages), and
really my reaction was that "most of them are great".

Good on us.

        Linus

Re: [GIT PULL] RCU changes for v6.17

[Paul E. McKenney]

On Wed, Jul 30, 2025 at 03:34:55PM -0700, Linus Torvalds wrote:
> On Wed, 30 Jul 2025 at 12:24, Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > As it happens, I will be sending the pull request for the v6.18 merge
> > window, so I will stop doing my usual octopus merges (hey, they *were*
> > cool!) and instead merge each branch separately, with each merge's commit
> > log giving a synopsis of the commits in the branch being merged.
> 
> Note that octopus merges aren't a no-no per se. Sometimes they make
> perfect sense, particularly if there's a handful of really trivial
> branches with just a commit or two each.
> 
> Then an octopus merge can be a really convenient way to avoid having
> as many merges as you have "real" commits.
> 
> So don't take my comment as a "never use octopus merges".
> 
> Take it more as "octopus merges have some downsides, and making _any_
> merge without an explanation for it in the commit message is bad".
> 
> The main downside of octopus merges really is just bisectability:
> because even if the problem doesn't end up being the merge itself, an
> octopus merge can make it fundamentally hard to do the "cut the
> history in two roughly equal points for testing".
> 
> But again, that's not a problem if you have just a fairly small
> handful of purely trivial commits.
> 
> So people just need to balance the "octopus merges are cool, and can
> avoid pointless repeated silly small merges" with "octopus merges can
> make for bisectability issues and should be avoided for anything even
> halfway comples".
> 
> (Also, try *very* hard to avoid octopus merges when any conflicts
> exist - even trivial ones. Octopus merges with conflict resolution
> take "that's hard to follow" to a whole other level, to the point
> where you really shouldn't even try).

Thank you!

So octopus merges of documentation, torture testing, and other things that
are very unlikely to matter for bisection should be fine.  Branches that
are not going to interact should be fine, give or take any uncertainty in
"not going to interact".  No merge conflicts are permitted in octopus
merges.

On the other hand, given that there are cases where octopus merges are
not fine, it might be more straightforward to merge one branch at a time.
The main loss is that remerging after applying fises is a bit easier
with octopus merges, but that isn't a big deal.

So it might be time to say "goodbye" to octopus merges.  I will try
that for v6.18.

> > If you have a best-practice series of merges example in mind, could you
> > please point me at it?
> 
> It's hard to give a good "typical" example, because I don't think
> "typical" exists.
> 
> Sometimes a simple one-line merge message just stating "Misc fixes for
> subsystem Xyz" really might be the "proper" merge message.
> 
> Because maybe that branch really had all just tiny uninteresting
> fixes, and git shortlog entirely describes it all to the point that
> writing anything more would just be wasting everybody's time.
> 
> Honestly, the merge messages you guys send me for *my* RCU merge are
> fine - the only thing I ask for is that instead of describing the
> branches with an esoteric branch name, you write them out for humans.
> 
> So having the header read "Improvements expedited RCU grace periods"
> or something is just _soo_ much more understandable than
> "rcu-exp.23.07.2025", wouldn't you agree?

Fair point!

> As to the merge messages for *your* own merges, where you just put
> several branches together in order to send the result to me: knowing
> that there will be a more complete message in the upstream merge, I
> think the main issue is to think about people who hit that merge
> because they have some issue.
> 
> So again, it might be because somebody ends up hitting that merge
> during bisection, or has some other reason why they are looking at
> that merge in particular, rather than the "bigger picture" upstream
> merge.

And that argues for putting the material that we currently put into the
pull request into the merge commit logs.

> In other words, please write merge messages with the intended audience
> in mind. They don't necessarily need to be the same kind of
> full-fledged explanation that I want to explain why I'm merging (and
> for people who follow the development process: people most definitely
> look at the pull requests that come upstream, and it's informative to
> not just me, but you find tech press etc looking at them too).
> 
> But you should at a minimum think about "what if somebody hits this
> during a bisection". Give those random developers a clue about what is
> going on. Don't just make it be that "Merge branch XYZ", because that
> tells _outsiders_ so little.
> 
> Does that make sense as an answer?

Very much so, and again thank you.

> Anyway, I'm happy to say that if you are looking for _examples_ of
> merges, we have tons of them. I'm proud of the fact that I think
> kernel commit messages in general are very good, and when I compare
> them to other projects I feel like we tend to do a stellar job. And
> I'm not just patting myself on the back, we have tons of good
> examples.
> 
> So you can do a
> 
>     git log --merges
> 
> in general, and while you'll find some that just list branches, I
> think most of them tend to be very good these days. Look at the
> networking and bpf merges, for example (so typically Jakub and
> Alexei). Or the SoC merges (Arnd), or the VFS merges (Christian
> Brauner).
> 
> Or really most of them. I started looking for more names (the ones I
> mentioned were people I already knew wrote good merge messages), and
> really my reaction was that "most of them are great".
> 
> Good on us.

Thank you, and as you say, lots of examples.  ;-)

							Thanx, Paul