Re: [PATCH 1/2] mm: zswap: free synchronous-IO writeback folios directly

[Johannes Weiner <hannes@cmpxchg.org>]

On Sat, Jul 18, 2026 at 11:36:39AM +0200, Alexandre Ghiti wrote:
> @@ -972,6 +972,30 @@ static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)
>  /*********************************
>  * writeback code
>  **********************************/
> +static void zswap_writeback_free_folio(struct folio *folio)
> +{
> +	folio_lock(folio);
> +
> +	/* The folio was allocated off the LRU and nothing re-adds it here. */
> +	VM_WARN_ON_ONCE_FOLIO(folio_test_lru(folio), folio);
> +
> +	/*
> +	 * Gate remove_mapping() on folio_test_swapcache(): a racing swapin may
> +	 * have freed the swap slot (folio_free_swap()) and dropped the folio from
> +	 * the cache, and remove_mapping() must not run on a non-swapcache folio
> +	 * (it would trip __remove_mapping()'s mapping == folio_mapping() check).
> +	 */
> +	if (folio_test_swapcache(folio) &&
> +	    remove_mapping(swap_address_space(folio->swap), folio))
> +		goto out;
> +
> +	/* Raced: the folio is now owned by the swapin; put it back on the LRU. */
> +	folio_add_lru(folio);
> +out:
> +	folio_unlock(folio);
> +	folio_put(folio);
> +}

Is this actually zswap-specific or should it be just swap code?

Both this function and the dropbehind queue in the next patch seem
like they could be reused if we wanted to make the generic swapout
path do dropbehind as well.

It looks odd in the next patch to have a generic swapcache &&
dropbehind check and then call zswap code.