Re: [PATCH v4 04/11] mm: zswap: add range lookup for large-folio swapin

[Yosry Ahmed]

On Mon, Jul 13, 2026 at 9:29 AM Usama Arif <usama.arif@xxxxxxxxx> wrote:
>
>
>
> On 13/07/2026 17:02, Yosry Ahmed wrote:
> >>  /**
> >>   * zswap_load() - load a folio from zswap
> >>   * @folio: folio to load
> >> @@ -1571,10 +1588,9 @@ bool zswap_store(struct folio *folio)
> >>   *  NOT marked up-to-date, so that an IO error is emitted (e.g. do_swap_page()
> >>   *  will SIGBUS).
> >>   *
> >> - *  -EINVAL: if the swapped out content was in zswap, but the page belongs
> >> - *  to a large folio, which is not supported by zswap. The folio is unlocked,
> >> - *  but NOT marked up-to-date, so that an IO error is emitted (e.g.
> >> - *  do_swap_page() will SIGBUS).
> >> + *  -EIO: if a slot in a large-folio range is unexpectedly still in zswap.
> >> + *  The folio is unlocked, but NOT marked up-to-date, so that an IO
> >> + *  error is emitted (e.g. do_swap_page() will SIGBUS).
> >
> > Just curious, why the change from -EINVAL to -EIO here? Does it matter
> > in practice or is it just a matter of personal taste? :)
>
> The caller only checks for != -ENOENT so no functional difference here. I viewed
> it as a change in semantic, -EINVAL meant that you passed a large folio, which
> wasn't supported to -EIO meaning the request is valid but zswap cannot safely
> complete a PMD-sized read from per-page compressed state.
>
> I dont want to speak for Alexandre, will let him comment on this properly :)
> But above is what I thought of when I got the patch from Alex.

A mention of the reasoning in the changelog would be nice, even if
it's only semantic.