On 2026/5/29 9:50, Lisa Wang wrote: > On Mon, Mar 30, 2026 at 03:20:15PM +0800, Miaohe Lin wrote: >> On 2026/3/20 7:30, Lisa Wang wrote: >>> After modifying truncate_error_folio(), we expect memory_failure() will >>> return 0 instead of MF_FAILED. Also, we want to make sure memory_failure() >>> signaling function is same. >>> >>> Test that memory_failure() returns 0 for guest_memfd, where >>> .error_remove_folio() is handled by not actually truncating, and returning >>> MF_DELAYED. >>> >>> In addition, test that SIGBUS signaling behavior is not changed before >>> and after this modification. >>> >>> There are two kinds of guest memory failure injections - madvise or >>> debugfs. When memory failure is injected using madvise, the >>> MF_ACTION_REQUIRED flag is set, and the page is mapped and dirty, the >>> process should get a SIGBUS. When memory is failure is injected using >>> debugfs, the KILL_EARLY machine check memory corruption kill policy is >>> set, and the page is mapped and dirty, the process should get a SIGBUS. >>> >>> Co-developed-by: Ackerley Tng <[email protected]> >>> Signed-off-by: Ackerley Tng <[email protected]> >>> Signed-off-by: Lisa Wang <[email protected]> >> >> Should we add a testcase for hugetlbfs? It seems >> hugetlbfs_error_remove_folio() behaves same as shmem. > > I agree that it would be more consistent to modify > hugetlbfs_error_remove_folio() to return MF_DELAYED and update > me_huge_page() to align with me_pagecache_clean(). > > However, I prefer to let this patch series focus on the > me_pagecache_clean() path (affecting shmem, guest_memfd and generic > pagecache), because the hugepage memory failure test is not working now > (hugetlb-read-hwpoison.c). Commit 66802526298e changed madvise() > behavior to always force-deliver a SIGBUS to the calling process if it > has the poisoned dirty page mapped. Aligning HugeTLB would require us to > fix this part together. > > To keep this series focused, I would like to handle the HugeTLB > alignment in the follow-up series. Would you be okay with this approach?
Sure, this will be better. Thanks for your work. It's really helpful. :)
