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
