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