On Thu, 2019-06-20 at 14:20 -0700, Paul E. McKenney wrote: > On Thu, Jun 20, 2019 at 04:06:02PM -0500, Scott Wood wrote: > > On Thu, 2019-06-20 at 13:53 -0700, Paul E. McKenney wrote: > > > And I have to ask... > > > > > > What did you do to test this change to kernel/softirq.c? My past > > > attempts > > > to do this sort of thing have always run afoul of open-coded BH > > > transitions. > > > > Mostly rcutorture and loads such as kernel builds, on a debug > > kernel. By > > "open-coded BH transition" do you mean directly manipulating the preempt > > count? That would already be broken on RT. > > OK, then maybe you guys have already done the needed cleanup work. Cool! Do you remember what code was doing such things? Grepping for the obvious things doesn't turn up anything outside the softirq code, even in the earlier non-RT kernels I checked. > But don't the additions of rcu_read_lock() and rcu_read_unlock() want > to be protected by "!IS_ENABLED(CONFIG_PREEMPT_RT_FULL)" or similar? This is already a separate PREEMPT_RT_FULL-specific implementation. -Scott
