From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) (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 14DEC48EBFC for ; Wed, 29 Jul 2026 13:52:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785333175; cv=none; b=bOSXFiqvtzOFdHZlMjHfulpqX7BPHYQvyv5JdPfJRPIwJE/QG3KulH2GqJSbMKtWlnw5IyCf1JIzBwn0tNKIdEM71Yyr3aL6LOFpewLQ+RAi23P+jfShNe71OmsC72ZXEJFbDRj7xOkOwwb5qlLh+B2WyZpQew1Tc7EtYuWFgaE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785333175; c=relaxed/simple; bh=n5h6ffldt/nxRVfmpTRcGE7pQP18K4zrqPa4cldODpk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uX94TddciBRSxSDl3nGw8429gFWelpj5xkNvJ0YXjo93LjdjCDK2pW0XaRXRLCLRj9OhDkWWRJewamDP3fsqcYVXOL5vx0jf1GGHmE/GGbZQ74EFOYGHHUQV7uMJLfkhGTz4rwG6GJBBLO/FPIszEFN/PrtjQzM1K5jWksGkQzc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=VXmy9sA0; arc=none smtp.client-ip=95.215.58.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="VXmy9sA0" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785333167; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ysgBHq5s5Hm/YI8tEORg2R1/XNH+Q68qloOBkdqdGRk=; b=VXmy9sA0jy4gxbhbmal08rZHjBw98uF//VsEcCLNmFVasgABbKxuixXLaWtCFY/fcYZ7y5 168iF14uvrsvzSj69TSV1qpCrIxYB9Qu9z5O2HADLheq9E1uKifq5w5lDUShq9BYsevfq1 iC3vJk4Qd3S4bB6gkI4sGMP7XQBHcks= Date: Wed, 29 Jul 2026 14:52:34 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v5 04/11] mm: zswap: add range lookup for large-folio swapin To: Nhat Pham Cc: Yosry Ahmed , Alexandre Ghiti , 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, 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, shikemeng@huaweicloud.com, kernel-team@meta.com, Alexandre Ghiti References: <20260722152043.2273289-1-usama.arif@linux.dev> <20260722152043.2273289-5-usama.arif@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 27/07/2026 17:24, Nhat Pham wrote: > On Fri, Jul 24, 2026 at 2:59 AM Usama Arif wrote: >> >> >> >> On 23/07/2026 17:42, Yosry Ahmed wrote: >>>>>> @@ -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)? >>>>> >>>> >>>> >>>> Yes, so we can end up in a race, which should be handled gracefully. >>>> >>>> For example, lets say we have zswap writeback enabled, which means we >>>> can end up in a state where we have a PMD swap entry and 511 of the 512 >>>> slots have been written to disk, but 1 slot (slot X) is still in zswap. >>>> >>>> We can then have the following race: >>>> >>>> >>>> CPU A: PMD swap-in CPU B: split-PTE swap-in >>>> ------------------ ------------------------ >>>> >>>> Checks swap cache: empty >>>> >>>> Faults slot X >>>> Adds order-0 folio F >>>> zswap_load(F): >>>> removes X from zswap >>>> marks F dirty >>>> >>>> Checks zswap range: empty >>>> A is preempted >>>> >>>> Unmaps/reclaims F >>>> zswap_store(F): >>>> puts X back in zswap >>>> Removes F from swap cache >>>> >>>> A resumes >>>> Allocates large swap-cache folio G >>>> zswap_load(G) finds X in zswap >>> >>> Why don't we check the zswap range after allocating a folio in the >>> swap cache? I am assuming at this point we have the folio locked and >>> the result should be stable? >>> >> >> Yes that makes sense. The folio is locked and the result will be stable. >> How about something like below? >> >> diff --git a/mm/swap_state.c b/mm/swap_state.c >> index 1f08fb522036..41f168377cb1 100644 >> --- a/mm/swap_state.c >> +++ b/mm/swap_state.c >> @@ -12,6 +12,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -500,6 +501,17 @@ static struct folio *__swap_cache_alloc(struct swap_cluster_info *ci, >> __folio_set_locked(folio); >> __folio_set_swapbacked(folio); >> __swap_cache_do_add_folio(ci, folio, entry); >> + /* >> + * Reject mixed zswap/disk backing before starting the read. >> + */ >> + if (order && zswap_is_present(entry, nr_pages)) { >> + __swap_cache_do_del_folio(ci, folio, entry, shadow); >> + spin_unlock(&ci->lock); >> + folio_unlock(folio); >> + /* nr_pages refs from swap cache, 1 from allocation */ >> + folio_put_refs(folio, nr_pages + 1); >> + return ERR_PTR(-EBUSY); >> + } > > If you move it to __swap_cache_add_check(), you can potentially > backoff even before the folio allocation? :) Thanks Nhat! Yes, this looks much much better as well: @@ -190,6 +191,15 @@ static int __swap_cache_add_check(struct swap_cluster_info *ci, if (nr == 1) return 0; + /* + * The cluster lock serializes swap-cache insertion with zswap + * writeback. Reject mixed zswap/disk backing before allocating a + * large folio and recheck it before adding the folio to swap cache. + */ + if (zswap_is_present(swp_entry(swp_type(targ_entry), + round_down(swp_offset(targ_entry), nr)), nr)) + return -EBUSY;