Message-ID: <25CA4D90-A24E-49C6-92D2-08080EC81466@nvidia.com>
Date: Wed, 04 Feb 2026 12:34:35 -0500
From: Zi Yan <ziy@...dia.com>
To: "David Hildenbrand (arm)" <david@...nel.org>
Cc: 是参差 <shicenci@...il.com>, <linux-mm@...ck.org>,
 <linmiaohe@...wei.com>, <akpm@...ux-foundation.org>,
 <linux-kernel@...r.kernel.org>, Matthew Wilcox <willy@...radead.org>
Subject: Re: WARNING in memory_failure() at include/linux/huge_mm.h:635
 triggered

On 4 Feb 2026, at 12:23, Zi Yan wrote:

> On 4 Feb 2026, at 12:15, David Hildenbrand (arm) wrote:
>
>> On 2/4/26 18:12, David Hildenbrand (arm) wrote:
>>> On 2/4/26 13:49, 是参差 wrote:
>>>> Hi,
>>>> I’m reporting a reproducible WARNING triggered in the hwpoison / memory_failure path when injecting a hardware-poison event via madvise(MADV_HWPOISON).
>>>>
>>>> The warning is triggered by a syzkaller C reproducer that:
>>>> maps a file-backed region with MAP_FIXED, touches related VMAs, and then
>>>> calls madvise() with MADV_HWPOISON over a large range.
>>>> The kernel reports a VM_WARN_ON_ONCE_FOLIO(1) from memory_failure() and points to include/linux/huge_mm.h:635, suggesting an unexpected folio/page state encountered while handling a poisoned compound/huge folio.
>>>>
>>>> The target page appears to be a compound head page (order:3) already marked hwpoison. memory_failure() seems to reach a branch that unconditionally warns (VM_WARN_ON_ONCE_FOLIO(1) at include/linux/ huge_mm.h:635), which usually indicates an “unreachable”/unexpected folio type or state transition in the huge/compound folio handling logic during hwpoison processing.
>>>>
>>>> This looks like a kernel-side invariant violation rather than a pure userspace misuse, since the warning is emitted from an unconditional VM_WARN_ON_ONCE_FOLIO(1) site.
>>>>
>>>> Reproducer:
>>>> C reproducer: https://pastebin.com/raw/UxennX2B
>>>> console output: https://pastebin.com/raw/wrhKRwZY
>>>> kernel config: https://pastebin.com/raw/dP93yBLn
>>>>
>>>> Kernel:
>>>>
>>>> HEAD commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
>>>>
>>>>   git tree: torvalds/linux
>>>>
>>>> kernel version: 6.19.0-rc7  (QEMU Ubuntu 24.10)
>>>
>>> @Zi Yan, this is weird.
>>>
>>> We run into the VM_WARN_ON_ONCE_FOLIO(1, folio); in min_order_for_split(),
>>> which is only active with !CONFIG_TRANSPARENT_HUGEPAGE.
>>>
>>> But how do we get a large folio in that case? folio_test_large(folio) succeeded.
>>>
>>> I think we rules out hugetlb before in that function.
>>>
>>>
>>> Looking into the full console output, this is an order-3 folio (fully mapped).
>>>
>>> How do we end up with a large folio here? I am only aware of that happening when something would
>>> allocate an order-3 compound page (not a folio) and map it into the page tables. Yes, that
>>> is nasty and can still happen, not sure yet though whether that is really what the reproducer
>>> triggers.
>>
>> Looking again,
>>
>> mapping:0000000000000000 index:0xffff88800fe2e600
>>
>> At least mapping==0 could indicate a non-folio thing.
>
> From the C repro above, syzbot opened a dev "/dev/sg#" and did mmap on it.
> Is it a device driver issue?

OK, it is CONFIG_CHR_DEV_SG. And the driver allocates a compound page at[1].
Since we initialize folio fields in prep_compound_page(), it becomes a folio
when it is inserted into a VMA.

It seems that my compound page and folio code separation patchset comes right
on time[2]. Basically, compound page should not be a folio.
With !CONFIG_TRANSPARENT_HUGEPAGE, __GFP_COMP for allocating a compound page
that is used as a folio should be rejected.

[1] https://elixir.bootlin.com/linux/v6.18.6/source/drivers/scsi/sg.c#L1868
[2] https://lore.kernel.org/all/20260130034818.472804-1-ziy@nvidia.com/

--
Best Regards,
Yan, Zi

Powered by blists - more mailing lists