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

[Barry Song]

On Mon, Aug 17, 2026 at 5:30 PM Breno Leitao <leitao@xxxxxxxxxx> wrote:
>
> On Mon, Aug 17, 2026 at 06:22:41AM +0800, Barry Song wrote:
> > On Thu, Aug 13, 2026 at 6:02 PM Breno Leitao <leitao@xxxxxxxxxx> 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 <leitao@xxxxxxxxxx>
> > > ---
> > >  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?

I’m fine with rate limiting. I’m just curious: now that you return
`SIGBUS`, the PF won’t retry, so you shouldn’t get flooded with
printk messages, right?
Or are there still cases where returning SIGBUS won’t prevent the
printk flooding?

Best Regards
Barry