On 2022-03-07 13:53:27 [-0800], Paul E. McKenney wrote: > > Correct, verified. But this means, that a task within a rcu_read_lock() > > section gets preempted for > 26 seconds before that timer fires. That > > delay during boot implies that something went wrong while it might > > happen at run-time under "normal" circumstances. So I wouldn't try to > > get this case covered. > > The point being that there is no problem with the timer being queued, > just that it won't go off until later in the boot process. Which in > turn means that all that is lost is the RCU CPU stall warning should one > be needed. Is that correct, or am I missing a turn in there somewhere? Correct. Before do_pre_smp_initcalls() there is no ksoftirqd so timers won't be processed. Therefore even the 26secs timer triggers, there will be no RCU-stall warning. Also I'm not sure how much of preemption can happen at this point since there is not much going on. Any delay at this points to a lockup and at this point the lockup detector isn't even fully operational (it does not trigger here during test). > > > > swait_event_timeout_exclusive() appears innocent. > > > > > > I agree that it would rarely need to block, but if the task executing the > > > synchronize_rcu() preempted one of the readers, wouldn't it have to block? > > > Or am I missing some code path that excludes that possibility? > > > > As explained above, it means ~20secs delay during bootup which I don't > > see happen. Once ksoftirqd is up, it is covered. > > Also: If _more_ users require a timer to expire so the system can > > continue to boot I am willing to investigate _why_ this is needed > > because it does delay boot up progress of the system. > > Just to double-check -- in RT, ksoftirqd is up and running before the boot > sequence reaches the call to rcu_end_inkernel_boot() from kernel_init()? Yes, this is the case. rcu_end_inkernel_boot() is really at the end of the boot process, we reached even SYSTEM_RUNNING ;) > This looks good to me, independent of the other discussion. From what > I can see, this code path is infrequent, so using hrtimer all the time > should not be a problem. Okay. > Unless there are objections, I will pull this one in. Good. Less patches for me to carry around. Thank you. > Thanx, Paul > Sebastian
