Messages in this thread | | | Date | Tue, 8 Sep 2015 13:02:42 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 2/2] rcu: Fix up timeouts for forcing the quiescent state |
| |
On Mon, Sep 07, 2015 at 05:21:02PM +0200, Petr Mladek wrote: > On Fri 2015-09-04 16:49:46, Paul E. McKenney wrote: > > On Fri, Sep 04, 2015 at 02:11:30PM +0200, Petr Mladek wrote: > > > The deadline to force the quiescent state (jiffies_force_qs) is currently > > > updated only when the previous timeout passed. But the timeout used for > > > wait_event() is always the entire original timeout. This is strange. > > > > They tell me that kthreads aren't supposed to every catch signals, > > hence the WARN_ON() in the early-exit case stray-signal case. > > Yup, I have investigated this recently. All signals are really blocked > for kthreads by default. There are few threads that use signals but > they explicitly enable it by allow_signal().
Good! ;-)
> > In the case where we were awakened with an explicit force-quiescent-state > > request, we do the scan, and then wait the full time for the next scan. > > So the point of the delay is to space out the scans, not to fit a > > pre-determined schedule. > > > > The reason we get awakened with an explicit force-quiescent-state > > request is that a given CPU just got inundated with RCU callbacks > > or that rcutorture wants to hammer this code path. > > > > So I am not seeing this as anything in need of fixing. > > > > Am I missing something subtle here? > > There is the commit 88d6df612cc3c99f5 ("rcu: Prevent spurious-wakeup > DoS attack on rcu_gp_kthread()"). It suggests that the spurious > wakeups are possible. > > I would consider this patch as a fix/clean up of this Dos attack fix. > Huh, I forgot to mention it in the commit message. > > To be honest, I personally do not know how to trigger the spurious > wakeup in the current state of the code. I am trying to convert > the kthread into the kthread worker API and there I got the spurious > wakeups but this is another story.
You can do it via rcutorture, but that is not an in-production concern.
You can also do it by having all CPUs invoke call_rcu() in a tight loop.
> Thanks a lot for reviewing.
And thank you for your interest in the Linux-kernel RCU implementation!
Thanx, Paul
| |