Re: [PATCH v2 2/3] mm, swap: distinguish a malformed swap entry from a dying device

On Thu, Aug 13, 2026 at 6:02 PM Breno Leitao <[email protected]> wrote:
>
> get_swap_device() returns NULL for two different things: an entry whose
> type names no swap device or whose offset is past the end of one, and a
> device that swapoff is taking away. The first never becomes valid, the
> second does, and callers cannot tell them apart.
>
> Return ERR_PTR(-EIO) for the two malformed cases and keep NULL for
> swapoff. copy_nonpresent_pte() already reports -EIO for the same
> corruption on the fork path.
>
> Callers bail out on failure either way, so switch them to
> IS_ERR_OR_NULL() and clear si where the cleanup path would otherwise
> put an ERR_PTR. No functional change.
>
> Signed-off-by: Breno Leitao <[email protected]>
> ---
[...]

> @@ -1859,7 +1859,10 @@ void folio_put_swap(struct folio *folio, struct page *page)
>   * Check whether swap entry is valid in the swap device.  If so,
>   * return pointer to swap_info_struct, and keep the swap entry valid
>   * via preventing the swap device from being swapoff, until
> - * put_swap_device() is called.  Otherwise return NULL.
> + * put_swap_device() is called.  Return NULL for an empty entry or a
> + * device that is going away, and ERR_PTR(-EIO) if the entry's type
> + * names no swap device or its offset is past the end of one. These EIOs
> + * are preceded by pr_err().
>   *
>   * Notice that swapoff or swapoff+swapon can still happen before the
>   * percpu_ref_tryget_live() in get_swap_device() or after the
> @@ -1900,12 +1903,13 @@ struct swap_info_struct *get_swap_device(swp_entry_t entry)
>         return si;
>  bad_nofile:
>         pr_err_ratelimited("%s: %s%08lx\n", __func__, Bad_file, entry.val);
> +       return ERR_PTR(-EIO);
>  out:
>         return NULL;
>  put_out:
>         pr_err_ratelimited("%s: %s%08lx\n", __func__, Bad_offset, entry.val);
>         percpu_ref_put(&si->users);
> -       return NULL;
> +       return ERR_PTR(-EIO);
>  }

Hi Breno,

Do you know why we’re seeing corrupted PTEs with `bad_nofile`?
Does this issue still exist in mainline?

Thanks
Barry