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

On Mon, Aug 17, 2026 at 05:40:59PM +0800, Barry Song wrote:
> > > 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?

Oh, do_swap_page() is only one of the get_swap_device() call sites, and
I am only returning SIGBUS from do_swap_page(). The other callers are
unchanged, and whether any of them can loop on the same entry and flood
needs a closer look.

> Or are there still cases where returning SIGBUS won’t prevent the
> printk flooding?

For the path I hit, do_swap_page(), SIGBUS does prevent the flood.
I cannot say the same for the other callers yet.

That is also why I would like to keep patch 1 standing on its own: it is
a cheap backstop no matter which caller is spinning, and it can go to
stable independently of patches 2 and 3.

Thanks for the solid questions,
--breno