Re: [PATCH v9 08/15] hugetlb: Use the has_hwpoisoned flag

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/21/26 23:32, Matthew Wilcox wrote:
> On Fri, Sep 18, 2026 at 03:44:12PM +0200, David Hildenbrand (Arm) wrote:
>> I'm a terrible person and it took me way too long to get back to this :(
>>
>>>
>>> You make it sound so easy ;-)
>>
>> Heh, as long as you hold a folio reference it really is :)
>>
>>>
>>> If we don't hold a reference on the folio, then the folio (whether it's
>>> hugetlb or not) can be split.  And then folio_test_hwpoison() can hit
>>> the assertion that it's now a tail page.
>>
>> Right. I am/was missing the connection to "generic_file_read_iter() in hugetlbfs".
> 
> We might be able to split this into two series at this point.  

That would be good, because I suspect the "generic_file_read_iter() in
hugetlbfs" part is less controversial than the hugetlb cleanup and we can just
merge that easily without touching too much other code.

[...]

>>> If we could get rid of HVO, we could do it entirely on struct page.
>>
>> That's what I hope we will achieve at some point.
> 
> I'm not sure that's a realistic hope in the next few years. 

:(

> Even if
> we get struct page down to 8 bytes, that's 2MB of memory per 1GiB allocation
> (assuming 4KiB pages).  Always a tempting target for someone looking for
> memory savings.

Ack

> 
> I would prefer an out-of-line tree that doesn't rely on a bit in struct
> page.  Maybe a bit in struct folio wuld be fine (which tells you whether
> it's OK to skip the tree search).

Yes, that would likely be better. A single bit would likely just remove any
overhead of checking in the common case (no hwpoison).

Not sure what to do with non-folio things.

> 
>>> Or, as above, entirely rearchitecture hwpoison handling to not be based
>>> around pages or folios any more.
>>>
>>>
>>> Blame Sashiko!  I'm going to ignore it in future, but it's really good
>>> at nerd-sniping "hey all of this is already broken and you could fix it
>>> as part of this series".
>>
>> Right, and this is only the tip of the iceberg, because the entire hwpoison
>> infrastructure is a complete hacked-on racy piece of ... engineering excellence.
>>
>> To summarize my question: is it possible to separate for this series the
>> pagecache part (Use generic_file_read_iter() in hugetlbfs) from all the hugetlb
>> hwpoison rework?
>>
>> OTOH, if it's really not avoidable, please let me know.
> 
> I think Sashiko will whine and complain incessantly if we drop the
> race elimination patches off the front.  I can try it, but is it worth
> doing?  

Note that Sashiko will apparently no longer complain about preexisting stuff.
I've been told that these reports are now collected elsewhere.

So I wouldn't worry about Sashiko crying about hwpoison stuff that was broken
for ever. I'd rather have fixes for that handled separately (after we properly
discuss a better long-term solution to handle most these races and where to
store hwpoison information long-term).


-- 
Cheers,

David