• Paul E. McKenney's avatar
    rcu: Narrow early boot window of illegal synchronous grace periods · 52d7e48b
    Paul E. McKenney authored
    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 code worked "by accident" for awhile, but started failing as soon
    as expedited RCU grace periods switched over to workqueues in commit
    8b355e3b ("rcu: Drive expedited grace periods from workqueue").
    Note that the code was buggy even before this commit, as it was subject
    to failure on real-time systems that forced all expedited grace periods
    to run as normal grace periods (for example, using the rcu_normal ksysfs
    parameter).  The callchain from the failure case is as follows:
    
    early_amd_iommu_init()
    |-> acpi_put_table(ivrs_base);
    |-> acpi_tb_put_table(table_desc);
    |-> acpi_tb_invalidate_table(table_desc);
    |-> acpi_tb_release_table(...)
    |-> acpi_os_unmap_memory
    |-> acpi_os_unmap_iomem
    |-> acpi_os_map_cleanup
    |-> synchronize_rcu_expedited
    
    The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y,
    which caused the code to try using workqueues before they were
    initialized, which did not go well.
    
    This commit therefore reworks RCU to permit synchronous grace periods
    to proceed during this mid-boot phase.  This commit is therefore a
    fix to a regression introduced in v4.9, and is therefore being put
    forward post-merge-window in v4.10.
    
    This commit sets 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.
    
    Fixes: 8b355e3b ("rcu: Drive expedited grace periods from workqueue")
    Reported-by: default avatar"Zheng, Lv" <lv.zheng@intel.com>
    Reported-by: default avatarBorislav Petkov <bp@alien8.de>
    Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: default avatarStan Kain <stan.kain@gmail.com>
    Tested-by: default avatarIvan <waffolz@hotmail.com>
    Tested-by: default avatarEmanuel Castelo <emanuel.castelo@gmail.com>
    Tested-by: default avatarBruno Pesavento <bpesavento@infinito.it>
    Tested-by: default avatarBorislav Petkov <bp@suse.de>
    Tested-by: default avatarFrederic Bezies <fredbezies@gmail.com>
    Cc: <stable@vger.kernel.org> # 4.9.0-
    52d7e48b
rcu.h 4.74 KB