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

[Kairui Song <ryncsn@gmail.com>]

On Thu, Aug 13, 2026 at 03:02:22AM +0800, Breno Leitao 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@debian.org>
> ---
>  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;
>  		si = NULL;
>  		goto out;
>  	}
> 
> -- 
> 2.53.0-Meta
> 

Looks good to me but interesting b4 shazam will apply a Fixed tag to this,
maybe it picked up the "Fixes" in discussion.
I checked the discussion and the history behind this, 2799e77529c2
caused the loop, and 23b230ba8ac3 caused the pr_err spam. But before
2799e77529c2 it wasn't correct either, it was OOM kill.

So anyway, the fix is good, we might omit the fixes tag on this I
think, the behavior was never correct.

Acked-by: Kairui Song <kasong@tencent.com>