This series contains fixup patches to fix the issues I observed when
I did memory failure tests.
Thanks!
Miaohe Lin (2):
mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when
dissolve_free_hugetlb_folio()
mm/hugetlb: fix unable to handle page fault for address
dead000000000108
mm/hugetlb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
2.33.0
Below panic occurs when I did memory failure test:
BUG: unable to handle page fault for address: dead000000000108
PGD 0 P4D 0
Oops: Oops: 0001 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 1073 Comm: bash Not tainted 6.9.0-rc4-next-20240417-dirty #52
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
RIP: 0010:enqueue_hugetlb_folio+0x46/0xe0
RSP: 0018:ffff9e0207f03d10 EFLAGS: 00000046
RAX: 0000000000000000 RBX: 0000000000000000 RCX: dead000000000122
RDX: ffffcbb244460008 RSI: dead000000000100 RDI: ffff976a09da6f90
RBP: ffffcbb244460000 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 7a088d6100000000 R12: ffffffffbcc93160
R13: 0000000000000246 R14: 0000000000000000 R15: 0000000000000000
FS: 00007fdb749b1740(0000) GS:ffff97711fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: dead000000000108 CR3: 00000001078ac000 CR4: 00000000000006f0
Call Trace:
<TASK>
free_huge_folio+0x28d/0x420
dissolve_free_hugetlb_folio+0x135/0x1d0
__page_handle_poison+0x18/0xb0
memory_failure+0x712/0xd30
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x380/0x540
ksys_write+0x64/0xe0
do_syscall_64+0xbc/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fdb74714887
RSP: 002b:00007ffdfc7074e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fdb74714887
RDX: 000000000000000c RSI: 00005653ec7c0e10 RDI: 0000000000000001
RBP: 00005653ec7c0e10 R08: 00007fdb747d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007fdb7481b780 R14: 00007fdb74817600 R15: 00007fdb74816a00
</TASK>
Modules linked in: mce_inject hwpoison_inject
CR2: dead000000000108
---[ end trace 0000000000000000 ]---
RIP: 0010:enqueue_hugetlb_folio+0x46/0xe0
RSP: 0018:ffff9e0207f03d10 EFLAGS: 00000046
RAX: 0000000000000000 RBX: 0000000000000000 RCX: dead000000000122
RDX: ffffcbb244460008 RSI: dead000000000100 RDI: ffff976a09da6f90
RBP: ffffcbb244460000 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 7a088d6100000000 R12: ffffffffbcc93160
R13: 0000000000000246 R14: 0000000000000000 R15: 0000000000000000
FS: 00007fdb749b1740(0000) GS:ffff97711fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: dead000000000108 CR3: 00000001078ac000 CR4: 00000000000006f0
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---
The root cause is that list_del() is used to remove folio from list when
dissolve_free_hugetlb_folio(). But list_move() might be used to reenqueue
hugetlb folio when free_huge_folio() leading to above panic. Fix this
issue by using list_del_init() to remove folio.
Signed-off-by: Miaohe Lin <[email protected]>
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 1da9a14a5513..08634732dca4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1642,7 +1642,7 @@ static void __remove_hugetlb_folio(struct hstate *h, struct folio *folio,
if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
return;
- list_del(&folio->lru);
+ list_del_init(&folio->lru);
if (folio_test_hugetlb_freed(folio)) {
h->free_huge_pages--;
--
2.33.0
On Thu, 18 Apr 2024 10:20:00 +0800 Miaohe Lin <[email protected]> wrote:
> Below panic occurs when I did memory failure test:
>
> BUG: unable to handle page fault for address: dead000000000108
>
> ...
>
> The root cause is that list_del() is used to remove folio from list when
> dissolve_free_hugetlb_folio(). But list_move() might be used to reenqueue
> hugetlb folio when free_huge_folio() leading to above panic. Fix this
> issue by using list_del_init() to remove folio.
>
> ...
>
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1642,7 +1642,7 @@ static void __remove_hugetlb_folio(struct hstate *h, struct folio *folio,
> if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
> return;
>
> - list_del(&folio->lru);
> + list_del_init(&folio->lru);
>
> if (folio_test_hugetlb_freed(folio)) {
> h->free_huge_pages--;
We should cc:stable and find a Fixes:. This appears to predate
6eb4e88a6d27022ea8aff424d47a0a5dfc9fcb34, after which I got lost.
On 2024/4/19 4:38, Andrew Morton wrote:
> On Thu, 18 Apr 2024 10:20:00 +0800 Miaohe Lin <[email protected]> wrote:
>
>> Below panic occurs when I did memory failure test:
>>
>> BUG: unable to handle page fault for address: dead000000000108
>>
>> ...
>>
>> The root cause is that list_del() is used to remove folio from list when
>> dissolve_free_hugetlb_folio(). But list_move() might be used to reenqueue
>> hugetlb folio when free_huge_folio() leading to above panic. Fix this
>> issue by using list_del_init() to remove folio.
>>
>> ...
>>
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -1642,7 +1642,7 @@ static void __remove_hugetlb_folio(struct hstate *h, struct folio *folio,
>> if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
>> return;
>>
>> - list_del(&folio->lru);
>> + list_del_init(&folio->lru);
>>
>> if (folio_test_hugetlb_freed(folio)) {
>> h->free_huge_pages--;
>
> We should cc:stable and find a Fixes:. This appears to predate
> 6eb4e88a6d27022ea8aff424d47a0a5dfc9fcb34, after which I got lost.
It's weird I didn't observe this issue before last merge window while corresponding
code logic seems not changed. I will try again to find a Fixes.
Thanks.
.
> .
>
On 2024/4/19 4:38, Andrew Morton wrote:
> On Thu, 18 Apr 2024 10:20:00 +0800 Miaohe Lin <[email protected]> wrote:
>
>> Below panic occurs when I did memory failure test:
>>
>> BUG: unable to handle page fault for address: dead000000000108
>>
>> ...
>>
>> The root cause is that list_del() is used to remove folio from list when
>> dissolve_free_hugetlb_folio(). But list_move() might be used to reenqueue
>> hugetlb folio when free_huge_folio() leading to above panic. Fix this
>> issue by using list_del_init() to remove folio.
>>
>> ...
>>
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -1642,7 +1642,7 @@ static void __remove_hugetlb_folio(struct hstate *h, struct folio *folio,
>> if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
>> return;
>>
>> - list_del(&folio->lru);
>> + list_del_init(&folio->lru);
>>
>> if (folio_test_hugetlb_freed(folio)) {
>> h->free_huge_pages--;
>
> We should cc:stable and find a Fixes:. This appears to predate
> 6eb4e88a6d27022ea8aff424d47a0a5dfc9fcb34, after which I got lost.
I think this series can be dropped because this didn't fix the root cause.
Please see my v2 patch for details. So this Fixes tag isn't needed anymore.
Thanks.
.
> .
>