Hi Waimain, On 06/08/24 10:25, Waiman Long wrote: > The memory_failure_cpu structure is a per-cpu structure. Access to its > content requires the use of get_cpu_var() to lock in the current CPU > and disable preemption. The use of a regular spinlock_t for locking > purpose is fine for a non-RT kernel. > > Since the integration of RT spinlock support into the v5.15 kernel, > a spinlock_t in a RT kernel becomes a sleeping lock and taking a > sleeping lock in a preemption disabled context is illegal resulting in > the following kind of warning. > > [12135.732244] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 > [12135.732248] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 270076, name: kworker/0:0 > [12135.732252] preempt_count: 1, expected: 0 > [12135.732255] RCU nest depth: 2, expected: 2 > : > [12135.732420] Hardware name: Dell Inc. PowerEdge R640/0HG0J8, BIOS 2.10.2 02/24/2021 > [12135.732423] Workqueue: kacpi_notify acpi_os_execute_deferred > [12135.732433] Call Trace: > [12135.732436] <TASK> > [12135.732450] dump_stack_lvl+0x57/0x81 > [12135.732461] __might_resched.cold+0xf4/0x12f > [12135.732479] rt_spin_lock+0x4c/0x100 > [12135.732491] memory_failure_queue+0x40/0xe0 > [12135.732503] ghes_do_memory_failure+0x53/0x390 > [12135.732516] ghes_do_proc.constprop.0+0x229/0x3e0 > [12135.732575] ghes_proc+0xf9/0x1a0 > [12135.732591] ghes_notify_hed+0x6a/0x150 > [12135.732602] notifier_call_chain+0x43/0xb0 > [12135.732626] blocking_notifier_call_chain+0x43/0x60 > [12135.732637] acpi_ev_notify_dispatch+0x47/0x70 > [12135.732648] acpi_os_execute_deferred+0x13/0x20 > [12135.732654] process_one_work+0x41f/0x500 > [12135.732695] worker_thread+0x192/0x360 > [12135.732715] kthread+0x111/0x140 > [12135.732733] ret_from_fork+0x29/0x50 > [12135.732779] </TASK> > > Fix it by using a raw_spinlock_t for locking instead. IIUC this is executed to recover a fault condition already, so maybe latencies are of no interest at that point, but I wonder if something like https://elixir.bootlin.com/linux/v6.10.1/source/Documentation/locking/locktypes.rst#L434 would still work and save us from introducing a raw_spinlock? Or maybe the critical section is anyway tiny and we don't care either? Thanks, Juri
