On Tue, Mar 24, 2026 at 08:36:36PM +0800, Baolin Wang wrote:
>
>
> On 3/24/26 8:43 AM, Lisa Wang wrote:
> > On Sat, Mar 21, 2026 at 02:30:04PM +0800, Baolin Wang wrote:
> > >
> > >
> > > On 3/20/26 7:30 AM, Lisa Wang wrote:
> > > > Add a shmem memory failure selftest to test the shmem memory failure is
> > > > correct after modifying shmem return value.
> > > >
> > > > Test that
> > > > + madvise() call returns 0 at the first time
> > > > + trigger a SIGBUS when the poisoned shmem page is fault-in again.
> > > >
> > > > Signed-off-by: Lisa Wang <[email protected]>
> > > > ---
> > >
> > > Why not move the shmem memory failure test into memory-failure.c?
> >
> > Do you mean let memory-failure.c kernel code check by itself?
> > The reason I write the selftest instead of combining in memory-failure.c
> > is because
> > + do not need extra checking code in kernel code
> > + make it easier to trace the entire execution flow, starting from the
> > madvise() down through shmem_error_remove_folio() and into the
> > truncate_error_folio() logic.
> >
> > Pleas let me know if I've missed something. Thanks!
>
> That's not quite what I meant. I mean, since there is already a
> memory-failure.c in mm selftests (see [1]), I think we should move the shmem
> memory failure test cases into that file.
Got it. Thank you for pointing out.
Is anyone currently working on the shmem memory failure test? If not, I
will merge it into my next version.
I have a question regarding the current implementation:
```
ret = sigsetjmp(signal_jmp_buf, 1);
if (!self->triggered) {
self->triggered = true;
ASSERT_EQ(variant->inject(self, addr), 0);
FORCE_READ(*addr);
}
```
Here is difficult to distinguish whether the SIGBUS is triggered by the
injection or the read operation. I am considering splitting these into
two separate SIGBUS jump blocks. Is it reasonable for me to split them?
> [1]
> https://lore.kernel.org/all/[email protected]/T/#m18e62ccb3e87316ec37dcde9389c1ba1c56d0951
