Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 24 Feb 2021 17:07:29 -0800
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Frederic Weisbecker <frederic@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Boqun Feng <boqun.feng@gmail.com>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        Neeraj Upadhyay <neeraju@codeaurora.org>,
        Josh Triplett <josh@joshtriplett.org>,
        Stable <stable@vger.kernel.org>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 01/13] rcu/nocb: Fix potential missed nocb_timer rearm
Message-ID: <20210225010729.GN2743@paulmck-ThinkPad-P72>
Reply-To: paulmck@kernel.org
References: <20210223001011.127063-1-frederic@kernel.org>
 <20210223001011.127063-2-frederic@kernel.org>
 <20210224183709.GI2743@paulmck-ThinkPad-P72>
 <20210224220606.GA3179@lothringen>
 <20210225001425.GL2743@paulmck-ThinkPad-P72>
 <20210225004813.GB12431@lothringen>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210225004813.GB12431@lothringen>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Thu, Feb 25, 2021 at 01:48:13AM +0100, Frederic Weisbecker wrote:
> On Wed, Feb 24, 2021 at 04:14:25PM -0800, Paul E. McKenney wrote:
> > On Wed, Feb 24, 2021 at 11:06:06PM +0100, Frederic Weisbecker wrote:
> > > I managed to recollect some pieces of my brain. So keep the above but
> > > let's change the point 10:
> > > 
> > > 10.     CPU 0 enqueues its second callback, this time with interrupts
> > >  	enabled so it can wake directly	->nocb_gp_kthread.
> > > 	It does so with calling __wake_nocb_gp() which also cancels the
> > > 	pending timer that got queued in step 2. But that doesn't reset
> > > 	CPU 0's ->nocb_defer_wakeup which is still set to RCU_NOCB_WAKE.
> > > 	So CPU 0's ->nocb_defer_wakeup and CPU 0's ->nocb_timer are now
> > > 	desynchronized.
> > > 
> > > 11.	->nocb_gp_kthread associates the callback queued in 10 with a new
> > > 	grace period, arrange for it to start and sleeps on it.
> > > 
> > > 12.     The grace period ends, ->nocb_gp_kthread awakens and wakes up
> > > 	CPU 0's ->nocb_cb_kthread which invokes the callback queued in 10.
> > > 
> > > 13.	CPU 0 enqueues its third callback, this time with interrupts
> > > 	disabled so it tries to queue a deferred wakeup. However
> > > 	->nocb_defer_wakeup has a stalled RCU_NOCB_WAKE value which prevents
> > > 	the CPU 0's ->nocb_timer, that got cancelled in 10, from being armed.
> > > 
> > > 14.     CPU 0 has its pending callback and it may go unnoticed until
> > >         some other CPU ever wakes up ->nocb_gp_kthread or CPU 0 ever calls
> > > 	an explicit deferred wake up caller like idle entry.
> > > 
> > > I hope I'm not missing something this time...
> > 
> > Thank you, that does sound plausible.  I guess I can see how rcutorture
> > might have missed this one!
> 
> I must admit it requires a lot of stars to be aligned :-)

It nevertheless constitutes a bug in rcutorture.  Or maybe an additional
challenge for the formal verification people.  ;-)

							Thanx, Paul