On 2022-04-01 17:10:06 [+0800], Zqiang 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 > kasan_cache_shrink+0x9/0x10 > kmem_cache_shrink+0x13/0x20 > acpi_os_purge_cache+0xe/0x20 > acpi_purge_cached_objects+0x21/0x6d > acpi_initialize_objects+0x15/0x3b > acpi_init+0x130/0x5ba > do_one_initcall+0xe5/0x5b0 > kernel_init_freeable+0x34f/0x3ad > kernel_init+0x1e/0x140 > ret_from_fork+0x22/0x30 > > When the kmem_cache_shrink() be 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 lock is > replaced with sleepbale rt spin lock, so the above problem is triggered. > fix it by migrating the release action from the IPI interrupt context > to the task context on RT kernel. >I haven't seen that while playing with kasan. Is this new? >Could we fix in a way that we don't involve freeing memory from in-IRQ? >This could trigger a lockdep splat if the local-lock in SLUB is acquired from in-IRQ context on !PREEMPT_RT. Hi, I will move qlist_free_all() from IPI context to task context, This operation and the next release members in the quarantine pool operate similarly I don't know the phenomenon you described. Can you explain it in detail? Thanks Zqiang > Signed-off-by: Zqiang <qiang1.zhang@xxxxxxxxx> Sebastian
