On Thu, Jun 15, 2023 at 09:13:41PM +0200, Sebastian Andrzej Siewior wrote: > On 2023-06-15 09:43:11 [-0700], Paul E. McKenney wrote: > > On Wed, Jun 14, 2023 at 10:34:30AM +0200, Sebastian Andrzej Siewior wrote: > > > bpf_free_inode() is invoked as a RCU callback. Usually RCU callbacks are > > > invoked within softirq context. By setting rcutree.use_softirq=0 boot > > > option the RCU callbacks will be invoked in a per-CPU kthread with > > > bottom halves disabled which implies a RCU read section. > > > > > > On PREEMPT_RT the context remains fully preemptible. The RCU read > > > section however does not allow schedule() invocation. The latter happens > > > in mutex_lock() performed by bpf_trampoline_unlink_prog() originated > > > from bpf_link_put(). > > > > Just to make sure that I understand, you are proposing that the RCU > > callbacks continue to run with BH disabled, but that BH-disabled regions > > are preemptible in kernels built with CONFIG_PREEMPT_RT=y? > > > > Or did I miss a turn in there somewhere? > > I'm not proposing anything, just stating what we have. On PREEMPT_RT > you are preemptible within the RCU callback but must not invoke > schedule(). Similar to the RCU read section on CONFIG_PREEMPT where you > are preemptible but must not invoke schedule(). Thank you for the clarification! The main risk of preemptible RCU callbacks is callback flooding, but RCU priority boosting should take care of that. Thanx, Paul
