On Wed, Feb 28, 2024 at 2:31 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Wed, 28 Feb 2024 14:19:11 -0800 > "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote: > > > > > > > > > Well, to your initial point, cond_resched() does eventually invoke > > > > preempt_schedule_common(), so you are quite correct that as far as > > > > Tasks RCU is concerned, cond_resched() is not a quiescent state. > > > > > > Thanks for confirming. :-) > > > > However, given that the current Tasks RCU use cases wait for trampolines > > to be evacuated, Tasks RCU could make the choice that cond_resched() > > be a quiescent state, for example, by adjusting rcu_all_qs() and > > .rcu_urgent_qs accordingly. > > > > But this seems less pressing given the chance that cond_resched() might > > go away in favor of lazy preemption. > > Although cond_resched() is technically a "preemption point" and not truly a > voluntary schedule, I would be happy to state that it's not allowed to be > called from trampolines, or their callbacks. Now the question is, does BPF > programs ever call cond_resched()? I don't think they do. > > [ Added Alexei ] I'm a bit lost in this thread :) Just answering the above question. bpf progs never call cond_resched() directly. But there are sleepable (aka faultable) bpf progs that can call some helper or kfunc that may call cond_resched() in some path. sleepable bpf progs are protected by rcu_tasks_trace. That's a very different one vs rcu_tasks.
