On 2019-09-17 09:36:22 [-0500], Scott Wood wrote: > > On non-RT you can (but should not) use the counter part of the function > > in random order like: > > local_bh_disable(); > > local_irq_disable(); > > local_bh_enable(); > > local_irq_enable(); > > Actually even non-RT will assert if you do local_bh_enable() with IRQs > disabled -- but the other combinations do work, and are used some places via > spinlocks. If they are used via direct calls to preempt_disable() or > local_irq_disable() (or via raw spinlocks), then that will not go away on RT > and we'll have a problem. lockdep_assert_irqs_enabled() is a nop with CONFIG_PROVE_LOCKING=N and RT breaks either way. > > Since you _can_ use it in random order Paul wants to test that the > > random use of those function does not break RCU in any way. Since they > > can not be used on RT in random order it has been agreed that we keep > > the test for !RT but disable it on RT. > > For now, yes. Long term it would be good to keep track of when > preemption/irqs would be disabled on RT, even when running a non-RT debug > kernel, and assert when bad things are done with it (assuming an RT-capable > arch). Besides detecting these fairly unusual patterns, it could also > detect earlier the much more common problem of nesting a non-raw spinlock > inside a raw spinlock or other RT-atomic context. you will be surprised but we have patches for that. We need first get rid of other "false positives" before plugging this in. > -Scott Sebastian
