Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Wed, 4 Oct 2023 09:47:04 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Frederic Weisbecker <frederic@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Yong He <zhuangel570@gmail.com>,
        Neeraj upadhyay <neeraj.iitr10@gmail.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <urezki@gmail.com>, RCU <rcu@vger.kernel.org>
Subject: Re: [PATCH 0/5] srcu fixes
Message-ID: <02d3ae63-8e52-4931-acf6-32ef69a6511a@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <20231003232903.7109-1-frederic@kernel.org>
 <f214737a-6856-455f-ac86-9f7ec605b902@paulmck-laptop>
 <1d21ceee-56d3-4784-9e6f-0a766c773833@paulmck-laptop>
 <811d08e3-efb8-4398-8fbc-6b5d030afb15@paulmck-laptop>
 <ZR0yMdyoA5biYYxg@lothringen>
 <77322b72-1d95-46c6-9837-1d811b36336c@paulmck-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <77322b72-1d95-46c6-9837-1d811b36336c@paulmck-laptop>
Precedence: bulk

On Wed, Oct 04, 2023 at 07:06:58AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 04, 2023 at 11:36:49AM +0200, Frederic Weisbecker wrote:
> > On Tue, Oct 03, 2023 at 08:30:45PM -0700, Paul E. McKenney wrote:
> > > On Tue, Oct 03, 2023 at 08:21:42PM -0700, Paul E. McKenney wrote:
> > > > On Tue, Oct 03, 2023 at 05:35:31PM -0700, Paul E. McKenney wrote:
> > > > > On Wed, Oct 04, 2023 at 01:28:58AM +0200, Frederic Weisbecker wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > This contains a fix for "SRCU: kworker hung in synchronize_srcu":
> > > > > > 
> > > > > > 	http://lore.kernel.org/CANZk6aR+CqZaqmMWrC2eRRPY12qAZnDZLwLnHZbNi=xXMB401g@mail.gmail.com
> > > > > > 
> > > > > > And a few cleanups.
> > > > > > 
> > > > > > Passed 50 hours of SRCU-P and SRCU-N.
> > > > > > 
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > > > > > 	srcu/fixes
> > > > > > 
> > > > > > HEAD: 7ea5adc5673b42ef06e811dca75e43d558cc87e0
> > > > > > 
> > > > > > Thanks,
> > > > > > 	Frederic
> > > > > 
> > > > > Very good, and a big "Thank You!!!" to all of you!
> > > > > 
> > > > > I queued this series for testing purposes, and have started a bunch of
> > > > > SRCU-P and SRCU-N tests on one set of systems, and a single SRCU-P and
> > > > > SRCU-N on another system, but with both scenarios resized to 40 CPU each.
> > > 
> > > The 200*1h of SRCU-N and the 100*1h of SRCU-p passed other than the usual
> > > tick-stop errors.  (Is there a patch for that one?)  The 40-CPU SRCU-N
> > > run was fine, but the 40-CPU SRCU-P run failed due to the fanouts setting
> > > a maximum of 16 CPUs.  So I started a 10-hour 40-CPU SRCU-P and a pair
> > > of 10-hour 16-CPU SRCU-N runs on one system, and 200*10h of SRCU-N and
> > > 100*10h of SRCU-P.
> > > 
> > > I will let you know how it goes.
> > 
> > Very nice! It might be worth testing the first patch alone as
> > well if we backport only this one.
> 
> The 10-hour 40-CPU SRCU-P run and pair of 10-hour 16-CPU SRCU-N runs
> completed without failure.  The others had some failures, but I need
> to look and see if any were unexpected.  In the meantime, I started a
> two-hour 40-CPU SRCU-P run and a pair of one-hour 16-CPU SRCU-N runs on
> just that first commit.  Also servicing SIGSHOWER and SIGFOOD.  ;-)

And the two-hour 40-CPU SRCU-P run and a pair of two-hour 16-CPU SRCU-N
runs (on only the first commit) completed without incident.

The other set of overnight full-stack runs had only tick-stop errors,
so I started a two-hour set on the first commit.

So far so good!

							Thanx, Paul

> > Thanks!
> > 
> > 
> > > 							Thanx, Paul
> > > 
> > > > > While that is in flight, a few questions:
> > > > > 
> > > > > o	Please check the Co-developed-by rules.  Last I knew, it was
> > > > > 	necessary to have a Signed-off-by after each Co-developed-by.
> > > > > 
> > > > > o	Is it possible to get a Tested-by from the original reporter?
> > > > > 	Or is this not reproducible?
> > > > > 
> > > > > o	Is it possible to convince rcutorture to find this sort of
> > > > > 	bug?  Seems like it should be, but easy to say...
> > > > 
> > > > And one other thing...
> > > > 
> > > > o	What other bugs like this one are hiding elsewhere
> > > > 	in RCU?
> > > > 
> > > > > o	Frederic, would you like to include this in your upcoming
> > > > > 	pull request?  Or does it need more time?
> > > > 
> > > > 						Thanx, Paul
> > > > 
> > > > > > ---
> > > > > > 
> > > > > > Frederic Weisbecker (5):
> > > > > >       srcu: Fix callbacks acceleration mishandling
> > > > > >       srcu: Only accelerate on enqueue time
> > > > > >       srcu: Remove superfluous callbacks advancing from srcu_start_gp()
> > > > > >       srcu: No need to advance/accelerate if no callback enqueued
> > > > > >       srcu: Explain why callbacks invocations can't run concurrently
> > > > > > 
> > > > > > 
> > > > > >  kernel/rcu/srcutree.c | 55 ++++++++++++++++++++++++++++++++++++---------------
> > > > > >  1 file changed, 39 insertions(+), 16 deletions(-)