Messages in this thread | | | Date | Fri, 13 Jan 2017 18:02:54 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods |
| |
On Thu, Jan 12, 2017 at 06:38:07PM -0800, Paul E. McKenney wrote: > The current preemptible RCU implementation goes through three phases > during bootup. In the first phase, there is only one CPU that is running > with preemption disabled, so that a no-op is a synchronous grace period. > In the second mid-boot phase, the scheduler is running, but RCU has > not yet gotten its kthreads spawned (and, for expedited grace periods, > workqueues are not yet running. During this time, any attempt to do > a synchronous grace period will hang the system (or complain bitterly, > depending). In the third and final phase, RCU is fully operational and > everything works normally. > > This has been OK for some time, but there has recently been some > synchronous grace periods showing up during the second mid-boot phase. > This commit therefore reworks RCU to permit synchronous grace periods > to proceed during this mid-boot phase. > > This commit accomplishes this by setting a flag from the existing > rcu_scheduler_starting() function which causes all synchronous grace > periods to take the expedited path. The expedited path now checks this > flag, using the requesting task to drive the expedited grace period > forward during the mid-boot phase. Finally, this flag is updated by a > core_initcall() function named rcu_exp_runtime_mode(), which causes the > runtime codepaths to be used. > > Note that this arrangement assumes that tasks are not sent POSIX signals > (or anything similar) from the time that the first task is spawned > through core_initcall() time. > > Reported-by: "Zheng, Lv" <lv.zheng@intel.com> > Reported-by: Borislav Petkov <bp@alien8.de> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested on a bunch of boxes I have access to, looks good.
Tested-by: Borislav Petkov <bp@suse.de>
-- Regards/Gruss, Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
| |