Re: WARNING in memory_failure() at include/linux/huge_mm.h:635 triggered

[Zi Yan <ziy@nvidia.com>]

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

> 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.

More details:
later at sg_vma_fault(), the driver just handles a page fault by supplying
a subpage from a pre-allocated compound page[3]. We then get a large folio
without !CONFIG_TRANSPARENT_HUGEPAGE.

[3] https://elixir.bootlin.com/linux/v6.18.6/source/drivers/scsi/sg.c#L1241

>
> 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


--
Best Regards,
Yan, Zi