[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bc5fb22c-189f-4f45-a7b3-185634ec3e26@redhat.com>
Date: Tue, 6 Aug 2024 12:15:12 -0400
From: Waiman Long <longman@...hat.com>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Miaohe Lin <linmiaohe@...wei.com>, Naoya Horiguchi
<nao.horiguchi@...il.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Huang Ying <ying.huang@...el.com>, Len Brown <len.brown@...el.com>
Subject: Re: [PATCH] mm/memory-failure: Use raw_spinlock_t in struct
memory_failure_cpu
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
Powered by blists - more mailing lists