Re: [PATCH v2 3/3] mm: fail the fault on a malformed swap entry instead of retrying it

On Mon, Aug 17, 2026 at 06:22:41AM +0800, Barry Song wrote:
> On Thu, Aug 13, 2026 at 6:02 PM Breno Leitao <[email protected]> wrote:
> >
> > do_swap_page() returns 0 when get_swap_device() fails, which the fault
> > handler reads as "handled". For an entry that can never become valid
> > the retry takes the same fault again, so the thread spins forever,
> > retrying on the same fault.
> >
> > Return VM_FAULT_SIGBUS (Bad access) for a malformed entry (pr_err() was
> > called at get_swap_device()).
> >
> > Signed-off-by: Breno Leitao <[email protected]>
> > ---
> >  mm/memory.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 7201e848129a7..fa2b3d2ad3202 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -4957,6 +4957,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >         /* Prevent swapoff from happening to us, and reject a bad entry. */
> >         si = get_swap_device(entry);
> >         if (IS_ERR_OR_NULL(si)) {
> > +               /* A malformed entry never becomes valid, so don't retry it. */
> > +               if (IS_ERR(si))
> > +                       ret = VM_FAULT_SIGBUS;
> 
> 
> Hi Breno,
> 
> Since you now return VM_FAULT_SIGBUS, the page fault should no
> longer retry repeatedly. Do we still need patch 1/3, which adds the
> rate-limited printk?

Yes, I still think we need it, for a few reasons:

1) A different bug could just as easily trigger the same message
   flood again.
2) I don't see a case where flooding the log with this message
   would help. If it keeps firing, something else is already
   broken, and the repeated message itself adds nothing useful.
3) From a monitoring perspective, I'd guess 95% of our log
   messages should be rate limited anyway, and this one would fall into
   this category.

You think this one shouldn't be ratelimited?

Thanks for the review,
--breno