Hello, Peter. On Mon, Jun 24, 2024 at 11:34:26AM +0200, Peter Zijlstra wrote: > I'm confused. Once you've loaded the BPF thing, 'all' tasks you care > about should already be in the bpf class. So any fork() thereafter > should not need to switch classes. > > This means we can have this rwsem be strictly for the bpf tasks as > Thomas suggested. > > What are we missing? Maybe I am confused but let's say the BPF scheduler gets unloaded and reloaded. What would prevent a forking thread which didn't acquire the read lock from racing against the second loading? Also, let's say we can make it conditional but would the extra complication be justifiable? percpu_down_read()'s hot path is one likely() cond test followed by this_cpu_inc() wrapped in preempt_disable(). I'm not really sure eliding that can justify much. That said, as Thomas pointed out, the dl cancel path is silly. Let me clean that up. Thanks. -- tejun
