On Tue, Feb 04, 2025 at 10:06:15PM +0100, Eric Dumazet wrote: > On Tue, Feb 4, 2025 at 10:00 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > > On Tue, 4 Feb 2025 21:10:59 +0100 Eric Dumazet wrote: > > > > Test output: > > > > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/61-l2tp-sh/ > > > > Decoded: > > > > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/vm-crash-thr2-0 > > > > > > Oh well. So many bugs. > > > > TBH I'm slightly confused by this, and the previous warnings. > > > > The previous one was from a timer callback. > > > > This one is with BH disabled. > > > > I thought BH implies RCU protection. We certainly depend on that > > in NAPI for XDP. And threaded NAPI does the exact same thing as > > xfrm_trans_reinject(), a bare local_bh_disable(). > > > > RCU folks, did something change or is just holes in my brain again? > > Nope, BH does not imply rcu_read_lock() You are both right? ;-) The synchronize_rcu() function will wait for all types of RCU readers, including BH-disabled regions of code. However, lockdep can distinguish between the various sorts of readers. So for example lockdep_assert_in_rcu_read_lock_bh(); will complain unless you did rcu_read_lock_bh(), even if you did something like disable_bh(). If you don't want to distinguish and are happy with any type of RCU reader, you can use lockdep_assert_in_rcu_reader(); I have been expecting that CONFIG_PREEMPT_RT=y kernels will break this any day now, but so far so good. ;-) Thanx, Paul
