On Thu, Jun 20, 2019 at 04:38:47PM -0500, Scott Wood wrote: > 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. It was many years ago, and it is quite possible that I am conflating irqs with bh or some such. If it now works, it now works. > > 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. Ah, sorry for the noise, then! Thanx, Paul