linux-kernel - Re: [PATCH v3] mm/memory-failure: Use raw_spinlock_t in struct memory_failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <af72159b-8142-ccab-5ccb-cca3ea3cdca9@huawei.com>
Date: Fri, 9 Aug 2024 09:45:27 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Waiman Long <longman@...hat.com>
CC: <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, Huang Ying
	<ying.huang@...el.com>, Len Brown <len.brown@...el.com>, Juri Lelli
	<juri.lelli@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>, Naoya
 Horiguchi <nao.horiguchi@...il.com>
Subject: Re: [PATCH v3] mm/memory-failure: Use raw_spinlock_t in struct
 memory_failure_cpu

On 2024/8/8 2:11, 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.
> 
> Also move the pr_err() out of the lock critical section and after
> put_cpu_ptr() to avoid indeterminate latency and the possibility of
> sleep with this call.
> 
> Fixes: 0f383b6dc96e ("locking/spinlock: Provide RT variant")
> Signed-off-by: Waiman Long <longman@...hat.com>

LGTM. Thanks.
Acked-by: Miaohe Lin <linmiaohe@...wei.com>

Thanks.
.