Messages in this thread | | | Date | Thu, 15 Dec 2022 15:10:27 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] tracing: Do not synchronize freeing of trigger filter on boot up |
| |
On Thu, Dec 15, 2022 at 05:39:13PM -0500, Steven Rostedt wrote: > On Thu, 15 Dec 2022 11:01:58 -0800 > "Paul E. McKenney" <paulmck@kernel.org> wrote: > > > What case? > > > > Here is one: > > > > o The newly spawned init process does something that uses RCU, > > but is preempted while holding rcu_read_lock(). > > > > o The boot thread, which did the preempting, waits for a grace > > period. If we use rcu_scheduler_active, all is well because > > synchronize_rcu() will do a real run-time grace period, thus > > waiting for that reader. > > > > But system_state has not yet been updated, so if synchronize_rcu() > > were instead to pay attention to that one, there might be a > > tragically too-short RCU grace period. > > The thing is, preemption is disabled the entire time here. > > That is, from: > > void kthread_show_list(void); > noinline void __ref rest_init(void) > { > struct task_struct *tsk; > int pid; > > rcu_scheduler_starting(); > > through: > > system_state = SYSTEM_SCHEDULING; > > complete(&kthreadd_done); > > > Preemption is disabled and other CPUs have not even been started yet. > > Although the might_sleep() call might schedule the kernel_init() task but > that will only block on the completion. > > In other words, I don't think anything can cause any issues this early in > the boot up.
The nice thing about the current placement of rcu_scheduler_starting() is that there is not yet any other task to switch to. ;-)
Thanx, Paul
| |