On 2022-05-09 21:14:17 [-0700], Andrew Morton wrote: > BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 > in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 > preempt_count: 1, expected: 0 > ........... > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt16-yocto-preempt-rt #22 > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), > BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 > Call Trace: > <TASK> > dump_stack_lvl+0x60/0x8c > dump_stack+0x10/0x12 > __might_resched.cold+0x13b/0x173 > rt_spin_lock+0x5b/0xf0 > ___cache_free+0xa5/0x180 > qlist_free_all+0x7a/0x160 > per_cpu_remove_cache+0x5f/0x70 > smp_call_function_many_cond+0x4c4/0x4f0 > on_each_cpu_cond_mask+0x49/0xc0 > kasan_quarantine_remove_cache+0x54/0xf0 … > > When the kmem_cache_shrink() was called, the IPI was triggered, the > ___cache_free() is called in IPI interrupt context, the local-lock or > spin-lock will be acquired. On PREEMPT_RT kernel, these locks are > replaced with sleepbale rt-spinlock, so the above problem is triggered. > Fix it by moving the qlist_free_allfrom() from IPI interrupt context to > task context when PREEMPT_RT is enabled. I would prefer something without that ifdef RT. That might still trigger lockdep with CONFIG_PROVE_RAW_LOCK_NESTING since you are in IRQ-off context (IPI) and your ___cache_free() may acquire a spinlock_t. Is it impossible/ impracticable to always access the list cross-CPU (with a lock instead of this_cpu access + IRQ-off)? Or always do what this patch suggest for RT? > [akpm@xxxxxxxxxxxxxxxxxxxx: reduce ifdeffery] > Link: https://lkml.kernel.org/r/20220401134649.2222485-1-qiang1.zhang@xxxxxxxxx > Signed-off-by: Zqiang <qiang1.zhang@xxxxxxxxx> > Acked-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > Cc: Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx> > Cc: Alexander Potapenko <glider@xxxxxxxxxx> > Cc: Andrey Konovalov <andreyknvl@xxxxxxxxx> > Cc: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Sebastian
