Miaohe Lin
1983184c22
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
...
When I did hard offline test with hugetlb pages, below deadlock occurs:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-11409-gf6cef5f8c37f #1 Not tainted
------------------------------------------------------
bash/46904 is trying to acquire lock:
ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock:
ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}:
__mutex_lock+0x6c/0x770
page_alloc_cpu_online+0x3c/0x70
cpuhp_invoke_callback+0x397/0x5f0
__cpuhp_invoke_callback_range+0x71/0xe0
_cpu_up+0xeb/0x210
cpu_up+0x91/0xe0
cpuhp_bringup_mask+0x49/0xb0
bringup_nonboot_cpus+0xb7/0xe0
smp_init+0x25/0xa0
kernel_init_freeable+0x15f/0x3e0
kernel_init+0x15/0x1b0
ret_from_fork+0x2f/0x50
ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcp_batch_high_lock);
lock(cpu_hotplug_lock);
lock(pcp_batch_high_lock);
rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904:
#0 : ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0
#1 : ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0
#2 : ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0
#3 : ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70
#4 : ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace:
CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x68/0xa0
check_noncircular+0x129/0x140
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fc862314887
Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887
RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001
RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00
In short, below scene breaks the lock dependency chain:
memory_failure
__page_handle_poison
zone_pcp_disable -- lock(pcp_batch_high_lock)
dissolve_free_huge_page
__hugetlb_vmemmap_restore_folio
static_key_slow_dec
cpus_read_lock -- rlock(cpu_hotplug_lock)
Fix this by calling drain_all_pages() instead.
This issue won't occur until commit a6b40850c442 ("mm: hugetlb: replace
hugetlb_free_vmemmap_enabled with a static_key"). As it introduced
rlock(cpu_hotplug_lock) in dissolve_free_huge_page() code path while
lock(pcp_batch_high_lock) is already in the __page_handle_poison().
[linmiaohe@huawei.com: extend comment per Oscar]
[akpm@linux-foundation.org: reflow block comment]
Link: https://lkml.kernel.org/r/20240407085456.2798193-1-linmiaohe@huawei.com
Fixes: a6b40850c442 ("mm: hugetlb: replace hugetlb_free_vmemmap_enabled with a static_key")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Jane Chu <jane.chu@oracle.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-04-16 15:39:50 -07:00
..
2024-03-04 17:01:18 -08:00
2024-03-14 17:43:30 -07:00
2023-12-05 11:17:58 +01:00
2024-02-22 10:24:41 -08:00
2024-03-11 09:38:17 -07:00
2022-08-02 12:34:03 -04:00
2023-10-25 16:47:13 -07:00
2022-09-11 20:25:50 -07:00
2024-02-22 10:24:57 -08:00
2024-02-22 10:24:57 -08:00
2024-02-22 10:24:57 -08:00
2024-03-14 17:43:30 -07:00
2024-01-08 15:27:15 -08:00
2024-02-23 17:27:13 -08:00
2024-03-06 13:04:18 -08:00
2023-04-05 19:42:38 -07:00
2023-12-05 11:17:58 +01:00
2023-06-09 16:25:56 -07:00
2023-06-23 16:59:31 -07:00
2023-06-09 16:25:23 -07:00
2022-11-22 18:50:44 -08:00
2024-03-26 11:07:20 -07:00
2023-12-29 11:58:27 -08:00
2023-06-23 16:58:19 -07:00
2022-11-08 17:37:15 -08:00
2024-04-16 15:39:48 -07:00
2023-12-29 12:22:28 -08:00
2023-08-21 13:07:20 -07:00
2024-04-16 15:39:48 -07:00
2023-10-18 14:34:17 -07:00
2023-12-12 10:57:08 -08:00
2023-10-25 16:47:14 -07:00
2024-04-16 15:39:50 -07:00
2022-10-03 14:03:05 -07:00
2023-12-12 10:11:32 +01:00
2024-04-16 15:39:48 -07:00
2023-08-18 10:12:36 -07:00
2024-03-21 14:41:00 -07:00
2024-01-22 10:31:08 +01:00
2024-03-04 17:01:26 -08:00
2023-12-12 10:57:07 -08:00
2023-12-29 11:58:56 -08:00
2024-02-22 10:24:54 -08:00
2023-04-12 17:36:23 -07:00
2024-04-16 15:39:48 -07:00
2024-03-31 11:32:26 +09:00
2023-08-24 16:20:30 -07:00
2024-02-24 15:53:40 -08:00
2024-03-04 17:01:25 -08:00
2024-03-04 17:01:21 -08:00
2024-02-22 10:24:40 -08:00
2024-04-16 15:39:50 -07:00
2024-02-22 10:24:55 -08:00
2024-04-05 11:21:31 -07:00
2024-03-06 13:04:18 -08:00
2024-03-13 18:38:13 -04:00
2023-12-29 11:58:26 -08:00
2024-03-13 12:12:21 -07:00
2023-12-29 11:58:56 -08:00
2024-02-23 17:28:43 -08:00
2023-08-21 13:07:20 -07:00
2024-03-04 17:01:22 -08:00
2024-03-06 13:04:17 -08:00
2022-10-03 14:02:43 -07:00
2024-03-22 10:41:13 -07:00
2024-02-22 15:27:17 -08:00
2023-08-18 10:12:41 -07:00
2023-12-12 10:57:02 -08:00
2024-02-21 16:00:03 -08:00
2023-10-18 14:34:18 -07:00
2022-09-26 19:46:25 -07:00
2024-02-23 17:48:19 -08:00
2024-03-04 17:01:16 -08:00
2024-03-14 17:43:30 -07:00
2022-09-11 20:26:01 -07:00
2023-08-18 10:12:31 -07:00
2023-01-18 17:12:52 -08:00
2023-12-29 20:22:11 -08:00
2024-03-04 17:01:27 -08:00
2024-04-16 15:39:49 -07:00
2023-12-10 16:51:50 -08:00
2024-01-08 15:27:15 -08:00
2023-08-24 16:20:18 -07:00
2023-12-20 14:48:12 -08:00
2024-02-23 17:48:38 -08:00
2023-12-10 16:51:53 -08:00
2023-06-19 16:19:29 -07:00
2023-12-14 00:23:17 -08:00
2023-08-18 10:12:25 -07:00
2023-12-10 16:51:39 -08:00
2024-02-22 10:24:47 -08:00
2024-03-04 17:01:19 -08:00
2024-02-22 15:27:20 -08:00
2022-10-03 14:03:05 -07:00
2023-08-21 13:38:02 -07:00
2024-03-26 11:07:23 -07:00
2024-03-14 17:43:30 -07:00
2024-01-08 15:27:15 -08:00
2023-10-04 10:32:26 -07:00
2024-01-05 09:58:32 -08:00
2022-10-03 14:03:07 -07:00
2024-01-08 15:27:15 -08:00
2024-03-14 18:03:09 -07:00
2024-03-12 10:16:56 +01:00
2024-03-12 10:16:56 +01:00
2023-08-18 10:12:53 -07:00
2024-02-21 16:00:01 -08:00
2022-10-03 14:03:36 -07:00
2024-02-22 10:24:54 -08:00
2024-03-04 17:01:26 -08:00
2024-03-12 13:07:16 -07:00
2024-02-20 14:20:48 -08:00
2024-03-14 17:43:30 -07:00
2023-12-10 16:51:42 -08:00
2023-04-12 17:36:23 -07:00
2024-03-26 11:07:23 -07:00
2024-03-14 17:43:30 -07:00
2024-04-05 11:21:30 -07:00
2023-11-28 14:08:38 +01:00
2024-03-14 17:43:30 -07:00
2024-01-08 15:27:15 -08:00
2024-02-21 11:36:50 +05:30
2024-02-23 17:48:31 -08:00
2023-06-19 16:19:27 -07:00
2023-06-19 16:19:27 -07:00
2024-03-04 17:01:28 -08:00
2024-03-26 11:14:12 -07:00