Re: [External] Re: [PATCH v2] mm/madvise: avoid skipping pages after splitting large folios
yunhui cui <[email protected]>
| Newsgroups | org.kernel.vger.stable,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <CAEEQ3wngAf7Wse8=zfByvzuuZvvy3kD7gD+HJZjvHTOf1UBiiw@mail.gmail.com> |
Hi Andrew, On Thu, Aug 6, 2026 at 2:29 PM Andrew Morton <[email protected]> wrote: > > On Thu, 6 Aug 2026 13:55:01 +0800 Yunhui Cui <[email protected]> wrote: > > > madvise_inject_error() advances through the requested range using the > > size of the page returned by get_user_pages_fast(). Saving the size > > before error injection is required for hugetlb pages because successful > > soft offlining can dissolve the source huge page. > > > > That stride is incorrect for non-hugetlb large folios in system memory. > > The memory failure handlers split such a folio and handle only the base > > page for the supplied PFN. Advancing by the pre-split folio size then > > skips the remaining pages in the requested range while madvise() still > > reports success. > > > > Advance by PAGE_SIZE for non-hugetlb folios in system memory. Retain > > folio_size() for hugetlb and ZONE_DEVICE folios, as compound Device DAX > > folios are handled as a whole. > > Thanks. > > > Fixes: 19bfbe22f59a ("mm, hugetlb, soft_offline: save compound page order before page migration") > > Cc: [email protected] > > Signed-off-by: Yunhui Cui <[email protected]> > > Should there be an Assisted-by: here? > > When fixing a bug, please always describe the userspace-visible runtime > effects of that bug. Especially when proposing a -stable backport. > > > I asked Gemini this question and then pasted in your email. It told me > stuff, but I don't know if it's correct. In this case it would be good > to hear that description in your own words, please. > > And perhaps a means of reproducing the bug - clearly our selftests/ > coverage here is poor. The issue can be reproduced with the softoffline helper from avocado-misc-tests. With 64K mTHP enabled: ./softoffline -m private -n 50 the test consistently failed with: pfn matches, softoffline failed at 10 After temporarily disabling 64K mTHP: echo never > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled ./softoffline -m private -n 50 the test passed in five consecutive runs: Softoffline succeeded! Thanks, Yunhui