Re: [PATCH v2] mm/madvise: avoid skipping pages after splitting large folios

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

On 8/6/26 16:34, Lorenzo Stoakes (ARM) wrote:
> On Thu, Aug 06, 2026 at 01:35:30PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> Let's at least split out the folio check into a helper to make things
>>> clearer:
>>>
>>> static bool poison_splits_folio(const struct folio *folio)
>>> {
>>> 	/* Hugetlb is, as always, a world unto itself. */
>>> 	if (folio_test_hugetlb(folio))
>>> 		return false;
>>> 	/* Soft-offline errors out, hwpoison traverse DAX intact. */
>>> 	if (folio_is_zone_device(folio))
>>> 		return false;
>>> 	return true;
>>> }
>>>
>>> Then for your patch:
>>>
>>> -		size = PAGE_SIZE;
>>> -		if (folio_test_hugetlb(folio) || folio_is_zone_device(folio))
>>> -			size = folio_size(folio);
>>> +		size = poison_splits_folio(folio) ? PAGE_SIZE : folio_size(folio);
>>>
>>> I tried writing something that was neater and nicer but AI kept pointing
>>> out how it was totally broken and I really really hate this code (not your
>>> fault :).
>>
>> No, I don't think any such special casing on folios is the right way to handle it.
> 
> I mean the issue here is the stride varies depending on whether the thing is
> hugetlb or not (and some weird DAX thing), and the poisoning causes a split
> otherwise so if you want to poison a range you have to account for that.

We GUP'ed a single page and now try to be smart about which other pages we'd GUP
next.

That's just wrong, and hugetlb special-casing is just ugly.

The problem here is that, if we GUP'ed a page and poisoned it, the GUP'ing the
next page might fail and we'd return an error.

But maybe that error can simply be handled? We have FOLL_HWPOISON.

So maybe we can just use FOLL_HWPOISON and skip over the entries that already
return -EHWPOISON?

-- 
Cheers,

David