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
| ||
|
Date: Thu, 15 Dec 2022 15:10:27 -0800 From: "Paul E. McKenney" <paulmck@...nel.org> To: Steven Rostedt <rostedt@...dmis.org> Cc: Masami Hiramatsu <mhiramat@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com> 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@...nel.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
Powered by blists - more mailing lists