[PATCH] mm/memory-failure: Use raw_spinlock_t in struct memory_failure_cpu

[PATCH] mm/memory-failure: Use raw_spinlock_t in struct memory_failure_cpu

[Waiman Long]

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(-)

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);
 	}
-- 
2.43.5

Re: [PATCH] mm/memory-failure: Use raw_spinlock_t in struct memory_failure_cpu

[Juri Lelli]

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

Re: [PATCH] mm/memory-failure: Use raw_spinlock_t in struct memory_failure_cpu

[Waiman Long]

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