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 AF924C47DD9 for ; Sun, 24 Mar 2024 21:23:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E395E6B007B; Sun, 24 Mar 2024 17:23:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC2446B0082; Sun, 24 Mar 2024 17:23:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C62F96B0083; Sun, 24 Mar 2024 17:23:28 -0400 (EDT) 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 B3CD06B007B for ; Sun, 24 Mar 2024 17:23:28 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2B5EC1604B3 for ; Sun, 24 Mar 2024 21:23:28 +0000 (UTC) X-FDA: 81933208896.27.5D50DDB Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf24.hostedemail.com (Postfix) with ESMTP id 4D87618000C for ; Sun, 24 Mar 2024 21:23:26 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZLDXCdxb; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711315406; 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=rpDW9MNFOfxjG6sVJlDI3bV93UG5A+19Bb8AJvL6hmg=; b=ghVhFOM2u6pPvq/ZA10jRWD2b1RpBbtxBKTvjmYfoAv4tq6XQWAWFf0ZWJxJGb5RcpT0QT Qi/IsgYsMaIMouRvGee/3L77L+HfwGn36DIKp7kzlo0P1GU/EiJ60r39eu70TZpkJSeM5Q CaCon3apXnhoDoYAZmQT0j86CFHklVY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZLDXCdxb; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711315406; a=rsa-sha256; cv=none; b=AavlPJfBmZDceLUvYySp323qUmmT7NstRsn68JD/EkYuaJGtM9NPHcNzEUP/TmAMyDwj3M JeMqZw857zHM7UvxRiWBN01oGETJ4vDa801lH1Hh5tHHxSrWLmgjoUZFPLsJwSEBsSBiOb GKGkCUVwqnIQgnSJT85qXXZa0N0w8vk= Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-56be32b9775so2907779a12.1 for ; Sun, 24 Mar 2024 14:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711315404; x=1711920204; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rpDW9MNFOfxjG6sVJlDI3bV93UG5A+19Bb8AJvL6hmg=; b=ZLDXCdxbSRxpyUo9xaONKs+R5faqGMRjSawAZMKZrlIK70IusWKC/1Gwb5cBA8S0Ur ruuzLIhR6ysTuIKH/U2Lu17PHlYNedO37lQVlv4Cq6FAOH7mMtvqOgFwoKD3wTBPVIde DAlupupuam2E7J5U4pHTv/AB62/m6V++WUC61+bjO/OHue/JClQJNUu89d7BpJcSS2AM a0b0K21Tc5h5b0n7sAhTqaGbbmX0kCUTvTFed1h9OZyMDDb+Di4jbBkx+xluv/fcu4Nk 6BT/ZtD9dqvU4Xh9KqBQkOYNRzqhNSsKNgStxSb7xgsIVeXH3t8FoX/3bptIMd0QhWWI wsjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711315404; x=1711920204; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rpDW9MNFOfxjG6sVJlDI3bV93UG5A+19Bb8AJvL6hmg=; b=E3y7aMr/4UvC4ONhF+E6ZfdXbVBIJ1Uvw9pibc5pRfiemcUD2N8U0AIupiaE4jIspA wchyhnC8NGsuERC7Gzchd71KWIMK7lL11zU0cPEEbq5+YXBuawLiHiuWbVSjoKDk4+Am i7HdD4H/PJJpNm63CBB/Xym86gIPorI6iSxCKnNG4tULgseTsMXjwK+FO4upgVkFVObL 8KLmflZMcVl9iqMLIn9uMhek3r0ad7dgf6vUkwwF/YxRP4tY++qn4JPxi7rmgNAkkQ2Z imOZwCcRy0iAzXdaH9F1VRGrMrizi4q1O9+SlqWY662pixaw/v8RN7g0nxhK+pQXZcJf 7AcQ== X-Forwarded-Encrypted: i=1; AJvYcCWVp8fORpxcvHOFkCMU3EyY92bEDW2d/kmzwqqCAeEek9iaFogf0uUnjtk3z1BVn7jXFsgb1AY2MYSOpyy53FDKypw= X-Gm-Message-State: AOJu0YyFeX+YEhuh91q04wZsoUbDnOv77f4/2Lnvags15oQYnhKXyi8k /BimajVNpv31yGRJSLf999e8vJi6TOLeIIFq813cfmD0W+nk4GvDTRy2azUq/u0Ff8vnx5I8jSg VP2OQw2rSZXtlp33DaeUKIJSC5FIIm+teBypN X-Google-Smtp-Source: AGHT+IE2PLpZpD/SdVJ+zLXfepUJR3PSNmH6dMnK9nObvIVnE2sC0l7+uK+5o7TdJyrWuvLbMDmhzclSRq9qCgEwHDc= X-Received: by 2002:a17:906:2688:b0:a46:8c40:7a3a with SMTP id t8-20020a170906268800b00a468c407a3amr3560145ejc.26.1711315404261; Sun, 24 Mar 2024 14:23:24 -0700 (PDT) MIME-Version: 1.0 References: <20240324210447.956973-1-hannes@cmpxchg.org> In-Reply-To: <20240324210447.956973-1-hannes@cmpxchg.org> From: Yosry Ahmed Date: Sun, 24 Mar 2024 14:22:46 -0700 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 , Barry Song <21cnbao@gmail.com>, Chris Li , 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: 4D87618000C X-Rspam-User: X-Stat-Signature: u8hemb31crgjg364td9ggwdjubz9uns4 X-Rspamd-Server: rspam01 X-HE-Tag: 1711315406-791272 X-HE-Meta: U2FsdGVkX1+eoThjSe4Su7PcRajk6U2Y4f9gWMgswWUUeBCiK6Vqbs4dlsHBQnKmZoD3XerhRbbcUblRcSlsP9MTGKRECQ11RYq0lAAHJCMki+GTwAWMI8OYJ2lR+qk84M50slM4nklPzaKwVzXXbNxZl4nSU+hucJDhVaPzf/fBs/Wcox6cbLoz+mKewVn/Sg3m0jC9H4nPGUharZAj+1/NR66BKsH5j3a7vLbTHOp6u0MBOGtSHlm1rcsjUoNzkQ37awYvzcOWBYMAVvGO0qwKDNy17iTqo2NNfTdTJAwNUplNgLZiWeJVX7swVAm5ABu23c0Lr48sqJPLiCaxZgWXgWQTYBxTaVECvpQ9dt9tVmyio6S4/2PbuAtku9oChS4SJ3i4wbpl/tfBt6yKQGeWyHx3zWVaHBBNM0oZv3Ucm/BOuLRSVWJbiyk7G9M0S2qe3I2StlMaSber2D6fO1cWvnwdMqcfXsEygs6cyYeb0YleSD+3vkwCxg6609RBw+7e0FvPtoEE82sq1jxB9HB7PSxC5JBhs34nY8ZmICQYXowEfCIcRHI6kVl3JyGO7WBs0YBzhRkBZ+9ZjXUujW5MTIU+u8c52Ar13OGrXxcEpgDqOI9T41LvYqjZ+RpaMU+QV7NVDb9t/aUTyhqJvzf8+oDw+k89GCwnAEpMUrTZdWnGE9eKkOXTRX/KtXPfy7UUsTCqpqr2UNpTY6oVAqfX66PNujHoOVZT+MLRluP8BZx9b0YkuCPrfChYQk1bkS2qYR2DG5E6fX5lNE6pO5y2jbrI/bQDGas9zf0Nbi1zjAGSVGn3ECqHyZEbCey1XzEXsU+FEOJaZE/kcPg2aXT2f2HQS/3lgqjvg8AQNAlH9oNmnacDBKunhKaJxwUVDe2tMMrcYjKSMGWnyH3Awx6nwHzOMZW9Gozul18MCY0DBoQQvkKdqWfGE9xrVdraIjLyvyTkdTisDTuK4WV 72Y9J5D5 nBp5M5m1D26MmvX8ZedtTAfZ2bl2o99SElE8pu+V9n0sKfXQIX/kcEQFWqvcYFgfipU6ZU7ZwdADhmdljziOwOS1eLo2AhhHZqTEjPwSDCDwPI6115mb+nmV+Vm+qn4BkvNcse9ffjewlxFAr79PRlXBnAUqCeP7G0UCvgKB5bpfqGaukIgphkoEUa2IuFJRklBrjSvzyv4lm9u2Mfu7I9LyyB/DAeZrKWdNnBbD8SrM43W+5BRAMMwbQiTnx3086IPabNfnpw4AAgSWB8QDhkXrjyENdP/3KKT5QSZ8l2ztXI1UMUpgSWyDalrzUISqR/EQEW1IBiHXL9ToJTPJtdA5DNFR/TLcT6zqQ90Vo/vsLhJ/jLZdPHL88pmUg87TfVMF9vEIkMzJblq2+NN9PmzOy/noas/OwJvpbIqqNw31621J205mB9aZEtLmpq7xyIzowqNkutl8NU1EQwEfruLzxgKvdXFRPXhHQfhfcMV9hW0rE69anS3f8QQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Do we also want to mention somewhere (commit log or comment) that keeping the entry in the tree is fine because we are still protected from concurrent loads/invalidations/writeback by swapcache_prepare() setting SWAP_HAS_CACHE or so? Anyway, this LGTM. Acked-by: Yosry Ahmed > --- > 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 >