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

[Usama Arif]

On 13/07/2026 17:55, Yosry Ahmed wrote:
> 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.

Ack, Will add in next revision. Alexandre, let me know if there is something
specific you prefer to add in the commit message, otherwise will add something
similar to above.