linux-kernel - Re: [PATCH 01/13] rcu/nocb: Fix potential missed nocb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Feb 2021 01:48:13 +0100
From:   Frederic Weisbecker <frederic@...nel.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Boqun Feng <boqun.feng@...il.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Neeraj Upadhyay <neeraju@...eaurora.org>,
        Josh Triplett <josh@...htriplett.org>,
        Stable <stable@...r.kernel.org>,
        Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH 01/13] rcu/nocb: Fix potential missed nocb_timer rearm

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 :-)

Thanks.