| Message ID | 20240806142535.1033323-1-longman@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/memory-failure: Use raw_spinlock_t in struct memory_failure_cpu | expand |
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
On 8/6/24 11:53, Juri Lelli wrote: > 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? There are only 2 critical sections that makes use of this lock - memory_failure_queue() and memory_failure_work_func(). In memory_failure_queue(), there is a kfifo_put() and either schedule_work_on() or pr_err(). In memory_failure_work_func(), the critical section is just a kfifo_get(). kfifo_get() and kfifo_put() are not using loop and their run time, though not very short, shouldn't be long. The schedule_work_on() will take its own raw_spinlock_t to do its work anyway. So the only call that may have a long runtime is pr_err() before the printk rework lands. Fortunately, we can easily take the pr_err() call out of the critical section. As memory_failure_queue() is not a frequently called function and I doubt there will be much contention in the lock, I believe it is easier to understand to just use raw_spinlock_t than using migrate_disable() without using get_cpu_var(). Also if there is hardware issue leading to the call to memory_failure_queue(), a bit extra latency due to the use of raw_spinlock_t is not the most important concern anyway. I will post a v2 patch to move pr_err() call out of the lock critical section. Cheers, Longman
diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 581d3e5c9117..d40377b3edc8 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -2417,7 +2417,7 @@ struct memory_failure_entry { struct memory_failure_cpu { DECLARE_KFIFO(fifo, struct memory_failure_entry, MEMORY_FAILURE_FIFO_SIZE); - spinlock_t lock; + raw_spinlock_t lock; struct work_struct work; }; @@ -2449,13 +2449,13 @@ void memory_failure_queue(unsigned long pfn, int flags) }; mf_cpu = &get_cpu_var(memory_failure_cpu); - spin_lock_irqsave(&mf_cpu->lock, proc_flags); + raw_spin_lock_irqsave(&mf_cpu->lock, proc_flags); if (kfifo_put(&mf_cpu->fifo, entry)) schedule_work_on(smp_processor_id(), &mf_cpu->work); else pr_err("buffer overflow when queuing memory failure at %#lx\n", pfn); - spin_unlock_irqrestore(&mf_cpu->lock, proc_flags); + raw_spin_unlock_irqrestore(&mf_cpu->lock, proc_flags); put_cpu_var(memory_failure_cpu); } EXPORT_SYMBOL_GPL(memory_failure_queue); @@ -2469,9 +2469,9 @@ static void memory_failure_work_func(struct work_struct *work) mf_cpu = container_of(work, struct memory_failure_cpu, work); for (;;) { - spin_lock_irqsave(&mf_cpu->lock, proc_flags); + raw_spin_lock_irqsave(&mf_cpu->lock, proc_flags); gotten = kfifo_get(&mf_cpu->fifo, &entry); - spin_unlock_irqrestore(&mf_cpu->lock, proc_flags); + raw_spin_unlock_irqrestore(&mf_cpu->lock, proc_flags); if (!gotten) break; if (entry.flags & MF_SOFT_OFFLINE) @@ -2501,7 +2501,7 @@ static int __init memory_failure_init(void) for_each_possible_cpu(cpu) { mf_cpu = &per_cpu(memory_failure_cpu, cpu); - spin_lock_init(&mf_cpu->lock); + raw_spin_lock_init(&mf_cpu->lock); INIT_KFIFO(mf_cpu->fifo); INIT_WORK(&mf_cpu->work, memory_failure_work_func); }
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. Fixes: ea8f5fb8a71f ("HWPoison: add memory_failure_queue()") Signed-off-by: Waiman Long <longman@redhat.com> --- mm/memory-failure.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)