mbox series

[GIT,PULL] RCU regression fix for v6.4

Message ID 21bdc866-f9ae-4cda-a996-370bde183fd0@paulmck-laptop
State New
Headers
Series [GIT,PULL] RCU regression fix for v6.4 |

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/urgent-rcu.2023.06.11a

Message

Paul E. McKenney June 16, 2023, 4:34 p.m. UTC 
  Hello, Linus,

The following changes since commit ac9a78681b921877518763ba0e89202254349d1b:

  Linux 6.4-rc1 (2023-05-07 13:34:35 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/urgent-rcu.2023.06.11a

for you to fetch changes up to de29a96acceae732c68a4094d08dc49079eefa02:

  notifier: Initialize new struct srcu_usage field (2023-06-07 13:42:02 -0700)

----------------------------------------------------------------
Urgent RCU pull request for v6.4

This commit fixes a spinlock-initialization regression in SRCU that causes
the SRCU notifier to fail.  The fix simply adds the initialization,
but introduces a #ifdef because there is no spinlock to initialize for
the Tiny SRCU used in !SMP builds.

Yes, it would be nice to abstract this somehow in order to hide it in
SRCU, but I still don't see a good way of doing this.

----------------------------------------------------------------
Chen-Yu Tsai (1):
      notifier: Initialize new struct srcu_usage field

 include/linux/notifier.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

Comments

Linus Torvalds June 16, 2023, 6:50 p.m. UTC | #1 
On Fri, 16 Jun 2023 at 09:34, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> Yes, it would be nice to abstract this somehow in order to hide it in
> SRCU, but I still don't see a good way of doing this.

Ehh - like we actually do spinlocks in general, perhaps?

Spinlocks always exist. On UP - with no spinlock debugging - it turns
into a zero-sized data structure, and the spin lock/unlock operations
are no-ops.

Why don't you just do the exact same thing with the "struct
srcu_usage". For Tiny SRCU, just make it an empty struct, with an
empty initializer.

IOW, don't "abstract it out". Abstract it IN. Make tiny-rcu still have
it, just as a no-op.

Anyway, I've pulled your fix, but maybe the above would have been the
cleaner solution?

          Linus
pr-tracker-bot@kernel.org June 16, 2023, 6:57 p.m. UTC | #2 
The pull request you sent on Fri, 16 Jun 2023 09:34:15 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/urgent-rcu.2023.06.11a

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

Thank you!
Paul E. McKenney June 16, 2023, 9:26 p.m. UTC | #3 
On Fri, Jun 16, 2023 at 11:50:31AM -0700, Linus Torvalds wrote:
> On Fri, 16 Jun 2023 at 09:34, Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > Yes, it would be nice to abstract this somehow in order to hide it in
> > SRCU, but I still don't see a good way of doing this.
> 
> Ehh - like we actually do spinlocks in general, perhaps?
> 
> Spinlocks always exist. On UP - with no spinlock debugging - it turns
> into a zero-sized data structure, and the spin lock/unlock operations
> are no-ops.
> 
> Why don't you just do the exact same thing with the "struct
> srcu_usage". For Tiny SRCU, just make it an empty struct, with an
> empty initializer.
> 
> IOW, don't "abstract it out". Abstract it IN. Make tiny-rcu still have
> it, just as a no-op.
> 
> Anyway, I've pulled your fix, but maybe the above would have been the
> cleaner solution?

Good point, thank you!  I will add the lock to Tiny SRCU, shooting for
the v6.6 merge window.

							Thanx, Paul