On Wed, Sep 16, 2020 at 08:23:52PM +0100, Matthew Wilcox wrote:

On Mon, Sep 14, 2020 at 11:55:24PM +0200, Thomas Gleixner wrote:

...

But just look at any check which uses preemptible(), especially those which check !preemptible():

hmm.

+++ b/include/linux/preempt.h @@ -180,7 +180,9 @@ do { \ #define preempt_enable_no_resched() sched_preempt_enable_no_resched() +#ifndef MODULE #define preemptible() (preempt_count() == 0 && !irqs_disabled()) +#endif #ifdef CONFIG_PREEMPTION #define preempt_enable() \

$ git grep -w preemptible drivers (slightly trimmed by hand to remove, eg, comments) drivers/firmware/arm_sdei.c: WARN_ON_ONCE(preemptible()); drivers/firmware/arm_sdei.c: WARN_ON_ONCE(preemptible()); drivers/firmware/arm_sdei.c: WARN_ON_ONCE(preemptible()); drivers/firmware/arm_sdei.c: WARN_ON_ONCE(preemptible()); drivers/firmware/arm_sdei.c: WARN_ON(preemptible()); drivers/firmware/efi/efi-pstore.c: preemptible(), record->size, record->psi->buf); drivers/irqchip/irq-gic-v4.c: WARN_ON(preemptible()); drivers/irqchip/irq-gic-v4.c: WARN_ON(preemptible()); drivers/scsi/hisi_sas/hisi_sas_main.c: if (!preemptible()) drivers/xen/time.c: BUG_ON(preemptible());

That only looks like two drivers that need more than WARNectomies.

I could easily imagine someone thinking that these did something in CONFIG_PREEMPT_NONE=y kernels. In fact, I could easily imagine myself making that mistake. :-/

Although maybe rcu_read_load_sched_held() or rcu_read_lock_any_held() might get called from a module ...

But yes, from the rcutorture module for certain and also from any other RCU-using module that includes the usual RCU debug checks.

Thanx, Paul