From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) (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 5173B33DED5 for ; Mon, 13 Jul 2026 16:29:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.185 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783960187; cv=none; b=BgSvqoEyK97oW8jCxrhPPUJ+NfLdmQpSIVey7LOErPbCnRqXvm7jdp3epf8xF0q7WPQ4121Ki3gRMqJyaEys2ONgaFjx4rXGM5F5/sKww0hgqTkClBRqaiEHcPdODS1KGXoVZu4WOXFHcSYuaZ8+b18VvyD2N+1mBFyozJs6bzQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783960187; c=relaxed/simple; bh=VZTgvCyz6ZaeDRY6AD086sMbI2Bf3/u9EjRqG1g50KI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WUhIVpb6VuqiQQ40Xl+MBN/Pk9uqasFsP9wJt/jSiWsGdfY/FfHXcNojK0j1pqLa6b5HfpNLzKD2BE6/Yz6suIW/Ee3scQG61kZAwi4VHHzulXgLoOid2egUhmmZd1oXulVJsTqIMb/TBfRG7j7wYKX4CAe2CAQTPigWz7gyoMo= 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=KcUhILSb; arc=none smtp.client-ip=91.218.175.185 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="KcUhILSb" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1783960181; 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=nIFCVDCks2Nl8QDC7s+Gse3mXfhj0M04OqJMclW1HMA=; b=KcUhILSbXhnltRbBUyt6mFW8wzTQFpnuIrLLrSbBc8yijyOJmwSXHR1AHSdCVmkZUhzmBo OlgsRuZF+Z7n2ktmf9P4k5Qvcy1YHRXjCI8ld47VLus38w/oR8a14Xpc7vfoks7Pf/BrBB EjMLWhX7MGumc0j/aJ6zH5H++O0YpAE= Date: Mon, 13 Jul 2026 17:29:36 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v4 04/11] mm: zswap: add range lookup for large-folio swapin To: Yosry Ahmed 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, npache@redhat.com, "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 References: <20260713133613.2707815-1-usama.arif@linux.dev> <20260713133613.2707815-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: 7bit X-Migadu-Flow: FLOW_OUT 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. > >> * >> * -ENOENT: if the swapped out content was not in zswap. The folio remains >> * locked on return. >> @@ -1593,13 +1609,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))) { >> + folio_unlock(folio); >> + return -EIO; >> + } >> + return -ENOENT; >> } >> >> entry = xa_load(tree, offset); >> -- >> 2.53.0-Meta >>