From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D9B52139C9 for ; Thu, 23 Jul 2026 00:01:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784764865; cv=none; b=q90YNZcPUzA+WbzGxM2W2IcQM7bj3dpa4eUWF9Zgy7d4ciitQQHUM3ER2VChM46kf+yiLEVzl0gv0xxKdb0RZc2JfxfEhUJP8qh7MWyGxIQosCkHFo6oSaWw/IY9bvfROuwwY7ikBkA3WiJaDNPV7HAL+6YNkZSACN3AHTBCrGw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784764865; c=relaxed/simple; bh=+mksK6lJ6bo1FNDRUWrMJ7569pOQqK6M0ezcPg4r3NA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JYotSBvsuoae0zKAzKXnr2YDwPIUYTTnxNBaecIDlruvwUcmaFB1a7G6x1fZpE7cuYxqaLHvjjESmUbzPFccNZSR4/QgT+noOdbFlWdhqkcKRd0x32fseojSJUyYfMuzgejaUilmp9vbDqKzjbne5yr3IZuQgu2CgApffpaYFVQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lr/5uR27; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lr/5uR27" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B13B21F000E9; Thu, 23 Jul 2026 00:01:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784764863; bh=PMQvkJ7Cw2WB0bsUlcObjuqLrm1lLE+w/ZmTmCjIdEY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=lr/5uR27ht26s8Jpqr56y/74PfFqe4o1UKOsd02ekr1ZVfC5beh6kF6OLxvLMWBFV Uc9i86xblf09mZnvGP00qRTqG3OyQsgpfs0ufBVcooFXYJcwNTWQs6CAWz2rH/SrkH IdPOlYi0+efumds4q60vb57feZp77zJ2L/80eYw17y0lY784TY5/F+AyUlrnAjQjhI opaZUiLkblNmOL7vwsWYVCu0Y1XRaDsVwVP3vnyqsusvAB/DUut6LbMZk6v5TxOZuc UhTGfvigzP4x5cudrcuaTilJWoQ8QH9A8KxY0fcKFD7JhAKj0p1GTos3pep6dggPcU lSwk7AO8Sdd9Q== Date: Thu, 23 Jul 2026 00:01:01 +0000 From: Yosry Ahmed To: Usama Arif Cc: Andrew Morton , david@kernel.org, chrisl@kernel.org, kasong@tencent.com, ljs@kernel.org, ziy@nvidia.com, linux-mm@kvack.org, ying.huang@linux.alibaba.com, Baoquan He , willy@infradead.org, youngjun.park@lge.com, hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev, alex@ghiti.fr, kas@kernel.org, baohua@kernel.org, dev.jain@arm.com, baolin.wang@linux.alibaba.com, Nico Pache , "Liam R. Howlett" , ryan.roberts@arm.com, Vlastimil Babka , lance.yang@linux.dev, linux-kernel@vger.kernel.org, nphamcs@gmail.com, shikemeng@huaweicloud.com, kernel-team@meta.com, Alexandre Ghiti Subject: Re: [PATCH v5 04/11] mm: zswap: add range lookup for large-folio swapin Message-ID: References: <20260722152043.2273289-1-usama.arif@linux.dev> <20260722152043.2273289-5-usama.arif@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260722152043.2273289-5-usama.arif@linux.dev> On Wed, Jul 22, 2026 at 08:19:35AM -0700, Usama Arif wrote: > From: Alexandre Ghiti > > A large folio reaches zswap_load() only when the caller expects > the whole range to be on disk. Zswap still stores large folios as > independent order-0 entries, so reconstructing a large folio from > zswap entries would risk returning partially initialized data. > > Teach zswap_load() to scan the covered range. If no slot is in zswap, > return -ENOENT so swap_read_folio() reads the backing device. If any > slot is still in zswap, fail the large-folio read so the caller can > fall back to per-page swapin. > > Return -EIO rather than -EINVAL for that conflict. Large-folio loads > are now valid requests; the error means zswap cannot safely satisfy > the request from partial per-page compressed state, not that the > request is unsupported. Existing callers only distinguish -ENOENT, > so this is a semantic clarification rather than a behavioral change. > > Add zswap_is_present() so PMD swap-entry consumers can make the same > range decision before attempting PMD-order swapin. > > Signed-off-by: Alexandre Ghiti > Signed-off-by: Usama Arif > --- > include/linux/zswap.h | 6 ++++++ > mm/zswap.c | 42 ++++++++++++++++++++++++++++++++---------- > 2 files changed, 38 insertions(+), 10 deletions(-) > > diff --git a/include/linux/zswap.h b/include/linux/zswap.h > index 30c193a1207e..cd9efcf9dec9 100644 > --- a/include/linux/zswap.h > +++ b/include/linux/zswap.h > @@ -35,6 +35,7 @@ void zswap_lruvec_state_init(struct lruvec *lruvec); > void zswap_folio_swapin(struct folio *folio); > bool zswap_is_enabled(void); > bool zswap_never_enabled(void); > +bool zswap_is_present(swp_entry_t entry, unsigned int nr); > #else > > struct zswap_lruvec_state {}; > @@ -69,6 +70,11 @@ static inline bool zswap_never_enabled(void) > return true; > } > > +static inline bool zswap_is_present(swp_entry_t entry, unsigned int nr) > +{ > + return false; > +} > + > #endif > > #endif /* _LINUX_ZSWAP_H */ > diff --git a/mm/zswap.c b/mm/zswap.c > index 4e76a4a87cdc..384492f1f696 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -1561,6 +1561,23 @@ bool zswap_store(struct folio *folio) > return ret; > } > > +/** > + * zswap_is_present() - is any slot in [entry, entry + nr) in zswap? > + * @entry: base swap entry of the range > + * @nr: number of contiguous slots to check (pass 1 for a single-slot query) > + */ > +bool zswap_is_present(swp_entry_t entry, unsigned int nr) > +{ > + pgoff_t offset = swp_offset(entry); > + struct xarray *tree = swap_zswap_tree(entry); > + unsigned long index = offset; > + > + if (!nr || zswap_never_enabled()) > + return false; > + > + return xa_find(tree, &index, offset + nr - 1, XA_PRESENT); > +} > + > /** > * zswap_load() - load a folio from zswap > * @folio: folio to load > @@ -1573,10 +1590,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). > * > * -ENOENT: if the swapped out content was not in zswap. The folio remains > * locked on return. > @@ -1595,13 +1611,19 @@ int zswap_load(struct folio *folio) > return -ENOENT; > > /* > - * Large folios should not be swapped in while zswap is being used, as > - * they are not properly handled. Zswap does not properly load large > - * folios, and a large folio may only be partially in zswap. > + * A large folio reaches zswap_load() only when its whole range is > + * expected to be on disk: PMD swap-entry consumers split before > + * calling into PMD-order swapin whenever any slot is still in zswap. > + * Confirm the range is entirely absent from zswap and return -ENOENT > + * so the caller reads it from disk; if a slot is unexpectedly still in > + * zswap, fail the read rather than return partially-initialized data. > */ > - if (WARN_ON_ONCE(folio_test_large(folio))) { > - folio_unlock(folio); > - return -EINVAL; > + if (folio_test_large(folio)) { > + if (zswap_is_present(swp, folio_nr_pages(folio))) { Is dropping the warning here intentional (for the folio_test_large() && zswap_is_present() case)? > + folio_unlock(folio); > + return -EIO; > + } > + return -ENOENT; > } > > entry = xa_load(tree, offset); > -- > 2.53.0-Meta >