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 A82FEC54E58 for ; Mon, 25 Mar 2024 21:27:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C09456B0082; Mon, 25 Mar 2024 17:27:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB9E86B0083; Mon, 25 Mar 2024 17:27:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5A0E6B0085; Mon, 25 Mar 2024 17:27:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 913DA6B0082 for ; Mon, 25 Mar 2024 17:27:22 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5FCDA1A0841 for ; Mon, 25 Mar 2024 21:27:22 +0000 (UTC) X-FDA: 81936847524.27.BE9F0CE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 8F357140012 for ; Mon, 25 Mar 2024 21:27:19 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eY7Ucymb; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711402039; 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=witdqkQ/GEl+j/qhaC7pOwiAAxJGrgD+G1tnHerMP40=; b=La4+X6R0QbZkNHGbUO+jjwJAv4Ho9nkrn6OvGjc885mJCOc6XI/oXJaHnLPox/b5fDuISM twQ8Cw/Idq9XXxyrTbS4Dok2fYoWaCEP7xRdn8E8iTbBSR1uhV13hftwA/9xlJb/FowSeB +8zYy8egA0KNNLR5VrtbqlcLfI07Wiw= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eY7Ucymb; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711402039; a=rsa-sha256; cv=none; b=UDMWkIFtNnCU6L9oOlrrEQu/ev3nB8lN/IzH0N1Y9q+mSeheNB+sdaKyQ6BqDTqpC3TX57 q07d4Su+QDbNMF+FTAcMg5ujbn4EPaA29gSLPQ6QSrq7berMnqnMrC9U6d8ZsXav/YjoCK ql4Tu3bWEB8RAekZEWgRB/nQzciVSr4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9756160CA3 for ; Mon, 25 Mar 2024 21:27:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 452B0C433F1 for ; Mon, 25 Mar 2024 21:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711402038; bh=5ctn4tCGtOBPpLyO5cQkET48bTFsSSdnlO7Caok7PN0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=eY7Ucymbw8xyt+iJMtV2V6oP4lW1Wb5kBCNA89Gx0Ucv9LpZc/EyX84c5PUXgEGvz rjDYiPuysewZn/PwunU0g3a7Pivmd4TGljiLnJLZ4matF+gxuKDdAIFmO4ijvHRRaj S/2iEbziKH6EnIcm9TNmGW8dTLJYEXqlQ8xalsHdR4dW03NMQhUIYpuOYUPIPmI7ls CAsHWGvejqkiX4QNiLvy+RceJlwAxRuL2UseRoocjOGTQypjgyScMyxgsAkGZR5n7m 7SK1MVrVEvK7knkwg8UqI/Dsd7/TyspEW4z/ewJIKus8UR02T8UBQtdxTJfmQBhRqI 7k/plhlh146TA== Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2d094bc2244so64338101fa.1 for ; Mon, 25 Mar 2024 14:27:18 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXGDIRg7qVsUXRV2wbIlLenTvfDjvN58umOSayUfMjYNNbG9V/b8jdQ/cb+2RnhRpNnmeuwxQMrrWpXCy1zdkNL8/Y= X-Gm-Message-State: AOJu0YzS8hkkpEXqLAkRfoLjeSwd+04iDn2Dght6ozdLAxNQc5MN10yY yfQVZKWyxwHIkvmD0nuKjS5Z6ikipxD165KFA7sgAzfHWXJ4E6YQ/RSLNtsgM/LRnGoKXmCd5JV U3HM7gnH50jklpdufTy/+KRCoaA== X-Google-Smtp-Source: AGHT+IF7pI04jgEaSWWd2GtNnmxq3xX2vtnRzH2ivXclPvBPUwEX33O7CxGqZ8AjFD6vSqZc2OuXWrHCfqJL+WVzUS8= X-Received: by 2002:a2e:3111:0:b0:2d6:c0eb:41cb with SMTP id x17-20020a2e3111000000b002d6c0eb41cbmr4397935ljx.3.1711402036973; Mon, 25 Mar 2024 14:27:16 -0700 (PDT) MIME-Version: 1.0 References: <20240324210447.956973-1-hannes@cmpxchg.org> In-Reply-To: <20240324210447.956973-1-hannes@cmpxchg.org> From: Chris Li Date: Mon, 25 Mar 2024 14:27:05 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: zswap: fix data loss on SWP_SYNCHRONOUS_IO devices To: Johannes Weiner Cc: Andrew Morton , Zhongkun He , Chengming Zhou , Yosry Ahmed , Barry Song <21cnbao@gmail.com>, Nhat Pham , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 8F357140012 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: oer5xk6y6fccphu4155e894o87cur6og X-HE-Tag: 1711402039-32407 X-HE-Meta: U2FsdGVkX1/AbGcWLBVFTPKsJT5OPDIPlWuEivJGgEyzav1rqTgdqi4EAM+9Qmc5joDQZToP0c3F0k+EicsuUpF3RZh8jcEuWz4kgIIiyGjerrYj5ttelL12loh92xgLkmokKu/ZKJ0iEwBPhkxkLGnraktjDhEXAxa07g/s2egYrjaxbizGvX0hib3S1zzfwF13a53pG1Is03ZyaVpnUBQ/h+z++S8TMqaaYPsMOvUTdrJx2FBIV55yVIuqHs9f60wIUfzoTb5jTBEuPv/thqXHdngGy00Bx3C8WrAuXXKtrJuS3U0y7ioM06+OFnOkWhGgojHI+wQldw7sYURvCnKMEYLE0jCF1HuZWrprr1Kc3Yh4IKPHOjDYyMdBCak7PBYS7/zc6qszIFPaJ56eNOKuuis94Kwmo8Uvj5Dh2wGBYDYXV8TWPsShLTwXCrZKf1AhKPECIjQMovk733fTAYeFovLLkP4OZMQFy6Nbe5Y7aN/dq+E/7Dyw6tKxu4Gna79JXp+e/IxgtRI+PLdMwlDwGuy9m4RnB+sdaTxYxQRQDZkb8bLW6piWUpKbzbfM7iLI8Et77VEDbwwyZQOjGVyyd5Wv3/e/kwlr15rnQh00IJpuxVl4HMsrMVfdPzjGBqanSjfCNbGLlwLj0Dc6mwwjk2R91WEaWGqQGzED8EtYG8/0pTUGfskctvnAwgKZ1rNaSKFpZD5Qhx/8/mu2S6gT3OFxr/Y2LeLTEs3dANaBKBfongYiKa5kAipiCTp+Zqc6/AcB9AUO3+uB4hk0Z0V5jFqcmcXiDlO274reEL4bS6cJ6JY9Z2+frWUz3g9clDAq9qEUER77HQ8Ag8hs0Se76zSLTrXYuaSYE69KaW6RTiV+z4zQ/zBf78g6ZFwKBrASOebi1874ZUGD+3cWiKbkz47qEcXY/P3qJrhripvCWnEbG5XnDLVA/CpM1+XvvTgAUaSC21IGRPhXE6x kQQ== 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 Sun, Mar 24, 2024 at 2:04=E2=80=AFPM Johannes Weiner wrote: > > Zhongkun He reports data corruption when combining zswap with zram. > > The issue is the exclusive loads we're doing in zswap. They assume > that all reads are going into the swapcache, which can assume > authoritative ownership of the data and so the zswap copy can go. > > However, zram files are marked SWP_SYNCHRONOUS_IO, and faults will try > to bypass the swapcache. This results in an optimistic read of the > swap data into a page that will be dismissed if the fault fails due to > races. In this case, zswap mustn't drop its authoritative copy. > > Link: https://lore.kernel.org/all/CACSyD1N+dUvsu8=3DzV9P691B9bVq33erwOXNT= mEaUbi9DrDeJzw@mail.gmail.com/ > Reported-by: Zhongkun He > Fixes: b9c91c43412f ("mm: zswap: support exclusive loads") > Cc: stable@vger.kernel.org [6.5+] > Signed-off-by: Johannes Weiner > Tested-by: Zhongkun He The change looks good to me. Thanks for the cleaner solution. It has conflict with the zswap rb-tree to xarray patch though. I will resolve the conflict and resubmit the zswap xarray patch. Acked-by: Chris Li Chris > --- > mm/zswap.c | 23 +++++++++++++++++++---- > 1 file changed, 19 insertions(+), 4 deletions(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index 535c907345e0..41a1170f7cfe 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -1622,6 +1622,7 @@ bool zswap_load(struct folio *folio) > swp_entry_t swp =3D folio->swap; > pgoff_t offset =3D swp_offset(swp); > struct page *page =3D &folio->page; > + bool swapcache =3D folio_test_swapcache(folio); > struct zswap_tree *tree =3D swap_zswap_tree(swp); > struct zswap_entry *entry; > u8 *dst; > @@ -1634,7 +1635,20 @@ bool zswap_load(struct folio *folio) > spin_unlock(&tree->lock); > return false; > } > - zswap_rb_erase(&tree->rbroot, entry); > + /* > + * When reading into the swapcache, invalidate our entry. The > + * swapcache can be the authoritative owner of the page and > + * its mappings, and the pressure that results from having two > + * in-memory copies outweighs any benefits of caching the > + * compression work. > + * > + * (Most swapins go through the swapcache. The notable > + * exception is the singleton fault on SWP_SYNCHRONOUS_IO > + * files, which reads into a private page and may free it if > + * the fault fails. We remain the primary owner of the entry.) > + */ > + if (swapcache) > + zswap_rb_erase(&tree->rbroot, entry); > spin_unlock(&tree->lock); > > if (entry->length) > @@ -1649,9 +1663,10 @@ bool zswap_load(struct folio *folio) > if (entry->objcg) > count_objcg_event(entry->objcg, ZSWPIN); > > - zswap_entry_free(entry); > - > - folio_mark_dirty(folio); > + if (swapcache) { > + zswap_entry_free(entry); > + folio_mark_dirty(folio); > + } > > return true; > } > -- > 2.44.0 >