From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AF4AC4828F for ; Wed, 7 Feb 2024 23:43:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5ED766B0071; Wed, 7 Feb 2024 18:43:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59DFF6B0074; Wed, 7 Feb 2024 18:43:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48C6C6B0075; Wed, 7 Feb 2024 18:43:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 36D116B0071 for ; Wed, 7 Feb 2024 18:43:16 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 049F1A0DE7 for ; Wed, 7 Feb 2024 23:43:15 +0000 (UTC) X-FDA: 81766636392.14.0281360 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf22.hostedemail.com (Postfix) with ESMTP id BC95AC0019 for ; Wed, 7 Feb 2024 23:43:13 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=oHUa2w9M; dmarc=none; spf=pass (imf22.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707349394; h=from:from:sender: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:dkim-signature; bh=0iM23qnBpv+lSUgdocRnmVdN+EkF2H3efvBc64mLjhc=; b=xbLPif1KsphQvUeSB6+2DaHYEpmOIPWhQdODljdLHpdlYla+2lt8i1oNsS8FgpQUL5KUlP Lcjnhx63ztr/0xf2wdYJp+otcLTW55Ahg/J1ZIkv0ukflyHKkJ2f1qe+m/3oWr/dLhxUQz 9yZuX9rsfRS6YirK70tP1MYi81WRXPI= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=oHUa2w9M; dmarc=none; spf=pass (imf22.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707349394; a=rsa-sha256; cv=none; b=6bAnJb1pgMKgvJpTb1DooGbembbBmOw211GJ3dbxv5vB9rSOmISRb8jd+K98oQrlkJvrYG PrtHdccfw0Ry/UBlmOZhcvQzbxiylpCsOpdDb0tpYAjDLW++eAyoabODHF+0n4jrt3Iiu4 snU3PDEt3MLmVZ8Zy7buG4f2XgPKJsk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 21341CE17D8; Wed, 7 Feb 2024 23:43:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EF0EC433C7; Wed, 7 Feb 2024 23:43:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1707349389; bh=MSFIzvdxYtXmQVrYnhwiJReGuZF/2JziUGpHlCPhyaw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oHUa2w9MenXTtmVIymyF4c5sKPZHCruv1r9X4zN9BxrNK/80ZmTF2ddMarPHIJVAY 0SiUeiabq6KSm+T3IJtbVXgdFxwgARuxz0vN7UK7gp6ym2mr0TD/Fk/k3sy0Lfvbxj YkyjE9akdJHBxBwa0bTmyvsbjOVR3RZ7cfHfpcPs= Date: Wed, 7 Feb 2024 15:43:08 -0800 From: Andrew Morton To: chengming.zhou@linux.dev Cc: hannes@cmpxchg.org, yosryahmed@google.com, nphamcs@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chengming Zhou , stable@vger.kernel.org, Chris Li Subject: Re: [PATCH v4] mm/zswap: invalidate old entry when store fail or !zswap_enabled Message-Id: <20240207154308.bc275f3e72ec1c1fd06cf5a2@linux-foundation.org> In-Reply-To: <20240207115406.3865746-1-chengming.zhou@linux.dev> References: <20240207115406.3865746-1-chengming.zhou@linux.dev> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: BC95AC0019 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: jmczjf1jzkdzy1d5g5mo38egct89mdzi X-HE-Tag: 1707349393-315872 X-HE-Meta: U2FsdGVkX18dMpm4nFINP9tUac33K7WR2BA1Yjcs9vV+zuNt4Frbbdh8GKvsbN1TCxuvkjPQ0/EFroLE/cJx1q+dGXP/UrF4TTILd0Xuav9LtTOjNvBkkLJVGUtmcIRILJ3LyqxcWfHvKXmWiglsKv88YnbSraMoxCxaSUtx1rKB84FFy80j+LAexAvjx9UbC/9q7lZPWQNfALING9aGDfpCWtLZuyq/w/g0f84SEnAfQEuWR0cIh/0JfcHm56TwA6TdF/OIV+8eUI3PelPSYWG7eheJJSS23dX7Vf8g3J86sqcBC7mnMWmyUEyATB1dSK4vWYi0ZBBo+WBxsttzDHmBeCQKadZ2q0m5ljAYLXO0mgmUkmp+FNOccJwgDJ7jD4248CQvYpZ/XU9iGkVznY+ruEPIZ9Q2mSPGhSXyVBdTP4h6Y8iXJLQymma39aMu+MF0lS87HeMBT9SfYbo3HTRYYgs6GLGtdBcYDNI4ixR55v5AoqNQIow9FydLwxGaAGb4dSw64Wmp9OVPuljrhoHqR/VKOxVYwdey1271oeTWQe3ZE3E3C1klgHffU+UW15V/DXRB/hfE1dsFx0qabJnD4WabsjUdeMkgIJwcWKzrhz9wYrggy/uyg8GujIKSf9B9OWV3A25P2ndftiAuYTIpXszYHoMfXZwPtuvkgvbLWtShYE1iLbSNojgYKrrXwBCMhnxA4iuZndY195obDWK7v2t6xJjnoUMVi4sdNKo+FpLwnx+TzUOYMxLMHPp/7KxaDOHrj4Du9+R5EbWH2C96BidNCJhbggrRQMiwkqkG6V+gtyzdyU13RkJKiF8jQt/GjLyztCPeMe5Nv62MhzeCv/bCFQGpa2Hhxz9iSB50BGvnIuOR67ZdEulK2jYsNbzirkb5Tp+SSg8puDtoDh5OMD6zCf3F8EG7i7SE0JCKXc6UeJi3F2OM9KvNGAr98Ipuky7CoyEmgxzQSTf vpRAnY+x StoIpskAWoWaoyiEIzvuXvlw4/ZlkjD7GyRT/JC1IVePSIkWCVgEM/LDTKvE1S9xROT3Kg/eIk1UcRF4/xwrA44eQFBeogQH1nCVerRq/IgreZrVgQze5e9vm7nx+F9Piy3wzrh4ioEf2NsUURSac1jt1JydNWCMeEkv/r/qITo54AYzGckSrscGO31BD9nN10PGcRyfn9vxbW516y0ETwJlFF5uUxHcDfBxsKEP3O+CWbtz9WDfJIUukguSsFz2KZpUbP0nJf5LbIzkMwZLbKKjnG6OimUC0saWOX1+PlqkjhFz4rlHapt/KgH+rhU+j63abMcsDOz3y7obqHsVoJh/z067kEBOBSUvHP+JMdaoUlPzFlbAu10DwHPp2wXCzWN4uGekAa20gi73GxHWnmELh/MPx3PXsuOr1l1F9EFcdJKqynWeBVHGJIg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, 7 Feb 2024 11:54:06 +0000 chengming.zhou@linux.dev wrote: > From: Chengming Zhou > > We may encounter duplicate entry in the zswap_store(): > > 1. swap slot that freed to per-cpu swap cache, doesn't invalidate > the zswap entry, then got reused. This has been fixed. > > 2. !exclusive load mode, swapin folio will leave its zswap entry > on the tree, then swapout again. This has been removed. > > 3. one folio can be dirtied again after zswap_store(), so need to > zswap_store() again. This should be handled correctly. > > So we must invalidate the old duplicate entry before insert the > new one, which actually doesn't have to be done at the beginning > of zswap_store(). And this is a normal situation, we shouldn't > WARN_ON(1) in this case, so delete it. (The WARN_ON(1) seems want > to detect swap entry UAF problem? But not very necessary here.) > > The good point is that we don't need to lock tree twice in the > store success path. > > Note we still need to invalidate the old duplicate entry in the > store failure path, otherwise the new data in swapfile could be > overwrite by the old data in zswap pool when lru writeback. > > We have to do this even when !zswap_enabled since zswap can be > disabled anytime. If the folio store success before, then got > dirtied again but zswap disabled, we won't invalidate the old > duplicate entry in the zswap_store(). So later lru writeback > may overwrite the new data in swapfile. > > Fixes: 42c06a0e8ebe ("mm: kill frontswap") > Cc: We have a patch ordering issue. As a cc:stable hotfix, this should be merged into 6.8-rcX and later backported into -stable trees. So it will go mm-hotfixes-unstable->mm-hotfixes-stable->mainline. So someone has to make this patch merge and work against latest mm-hotfixes-unstable. The patch you sent appears to be based on linux-next, so it has dependencies upon mm-unstable patches which won't be merged into mainline until the next merge window. So can you please redo and retest this against mm.git's mm-hotfixes-unstable branch? Then I'll try to figure out how to merge the gigentic pile of mm-unstable zswap changes on top of that. Thanks.