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 4FFBDC4828D for ; Thu, 8 Feb 2024 02:42:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF78D6B0085; Wed, 7 Feb 2024 21:42:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D80396B0087; Wed, 7 Feb 2024 21:42:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C21516B0088; Wed, 7 Feb 2024 21:42:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id ABCDA6B0085 for ; Wed, 7 Feb 2024 21:42:27 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4FB09A230C for ; Thu, 8 Feb 2024 02:42:27 +0000 (UTC) X-FDA: 81767087934.04.65D87D9 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) by imf26.hostedemail.com (Postfix) with ESMTP id 7456C140003 for ; Thu, 8 Feb 2024 02:42:25 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="drC4G/dn"; spf=pass (imf26.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707360145; a=rsa-sha256; cv=none; b=6QLzfaLByhvGtkp1WTJkJ/NLvz98hGTJWBq5L9Sm0GZd/nDVvBoYTYpBrVant0jqtny5Et Rzqvc/ClZWmqLVxxDqFuiLbqXIoU8glderh96UUsnLby1JD60btm3YGZPiCuul6XpAQ33G ytKGs3wRRnOoQiN6//msyeD4umyBn+s= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="drC4G/dn"; spf=pass (imf26.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707360145; 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=sxbB6xl70fcGsF0IjYGB+vnomK4N76RXXTy+fmO65MY=; b=HXQOZQE7SRWEGOAlZip6MaNurFumiI2q2HPiNJ1MHaJWmhxNGfHIpoqdRMaGd51oEzbZZ0 MGcpmAVDKw8QhyKJpPkXbc6lC6eHKRR0Yix0VKWiANVB70uksyYc6EHE58ley4nNj4j3ng P9KmvAxUBxaznmcJ2CZPdjqR695gsvo= Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707360143; 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=sxbB6xl70fcGsF0IjYGB+vnomK4N76RXXTy+fmO65MY=; b=drC4G/dntuy7hyCZhZ/TYhQlm483ShTPi8iqV0f3Hhe2yE6Idq0qPeIJ61wnyG1xlGW7T3 SaHbz8HMLWS/eJcIxevdBDs+KSoDAEfBZpICD9Egc9mUTgLfY/q4hSfnIqSyQa9Fme5Fp6 Mfdiw2hOgnNbiiVNyvQdoID3TlotNmo= Date: Thu, 8 Feb 2024 10:41:49 +0800 MIME-Version: 1.0 Subject: Re: [PATCH v4] mm/zswap: invalidate old entry when store fail or !zswap_enabled Content-Language: en-US To: Andrew Morton 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 References: <20240207115406.3865746-1-chengming.zhou@linux.dev> <20240207154308.bc275f3e72ec1c1fd06cf5a2@linux-foundation.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: <20240207154308.bc275f3e72ec1c1fd06cf5a2@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7456C140003 X-Stat-Signature: m6td1o394kdepo3spd51m3nwinx8yiib X-Rspam-User: X-HE-Tag: 1707360145-195547 X-HE-Meta: U2FsdGVkX18j2I87n+EqNBcKflpQKH2b5GGbJCFtsYrYyjoHe8U0e5tGddTxDhLei1cSmQAc2k2VoaNBgveJM9c3a4dFROufNK6mNtpQuoAqJ2y+HoiFvQnRbk/+RLyJpUh0xfxruHJeRIjeHdEsYQNGhdwzfrMn2/dXlcKD7OUjl3Y7FbRLQzYZFUsGQ/V4srdSwqyZhjj8yUHLm/hI6Ttg+yZ61vSC8TkPrW5zJZY2SME0CxfiNWZnZUYWZoM2qekgi3D8sZNI2zmRadz0q6QijVhJ+uoxs/YwbrJhqKMP7x47tDa2Czb52mboqOU2AeRHjEWFJEd7i6wzZA57AVpnx5eOYlAyUHKOO+LmzaC7dsWWGkb1z91XbmwBfUomdNGG2HZP6oSQtYlt/eU3cNsk5yqtk2pL41WDA6uD77AYzj8wLxbqXZOqC8KuqqOmh3bjVG5fyKAUhIvCUTurgppe04484wh8iui2ufRU4a3sQBzHYCe/VM6L9R6DKwDL4qebuOzoQ5F5SBh0nbclLp5xrLUW2M5wq0cxBhY8hT0sRwrFEIUzeBFZXsiqVeGpqCrSzFo2wATbUPYgkb7B6nhBxsVh13ZuR6dXjoTL3rZNhPz+DCIWO6EjAWjWY/lHfC+UU/uAoXzKxrWQ05A6uBacBsa7rSosvR5GqUnSiBOb9oFfpAo7x/Gahg7+57MMgvOk89gTTrSq6TUNjStdTfTLtxGoeC/V3xfe6pp7s9+TobuRbm9Z8mMX8Naj8auR7Q86r53chJcUoi3dse3UxdZ9boXwb684X0V6sURPqSAlThck47cOuQOsSj1k1zqiJc7ltlvNohxz7JxiUYa/uYXXMVvgGpYg9QoCNYIYg/Xc1+KR1DLqXxmhMoPAGRUo39QiXyKmhEcMaFQ0fRhp6GbDoQUC2kg4S2weZoRDvm5o6nbhNJdRgfIXmzYMDnbKQd8/t8N24Oicz5TRE0R vuZ6k0Z1 VWZPtFy2FS7XCh1/zzwg3Yp/CxW0q0EM7yBs0usB9TReksku1ciPRb5QeTPh6z4aTtOiDc3cO2aCwLokzLeO0UPByQfILPqAH0OyFOxaZxm9N+IR5V/TN10L392FMwCzQ3yzNchGPB3fSLYoCmj75fAGk25QJZbg85B6F2IikZi0YsrnY9u7oyF8k0zT0AsPccxej5HkCahGbdlRaGB01m4p9hj7kQ0lVtjFzFmb3NPHBxxL0/FjE/7S3jU4PL+0HtZ+bMnjZqF7cvvaKTq4S6L9whJuuJsLP1oAlY4leUewpwYKTvaqNzyHHdNXmL+p4aXKG 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 2024/2/8 07:43, Andrew Morton wrote: > 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. Ah, right. I just sent a fix based on mm-hotfixes-unstable [1], which is split from this patch to only include bugfix, so easy to backport. This patch actually include two parts: bugfix and a little optimization for the zswap_store() normal case. Should I split this patch into two small patches and resend based on mm-unstable? [1] https://lore.kernel.org/all/20240208023254.3873823-1-chengming.zhou@linux.dev/ > > 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.