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 5B98DC54E64 for ; Mon, 25 Mar 2024 17:09:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDB246B0088; Mon, 25 Mar 2024 13:09:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8A216B008A; Mon, 25 Mar 2024 13:09:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C52D96B0092; Mon, 25 Mar 2024 13:09:52 -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 B1C696B0088 for ; Mon, 25 Mar 2024 13:09:52 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7F02A120753 for ; Mon, 25 Mar 2024 17:09:52 +0000 (UTC) X-FDA: 81936198624.08.68FEA16 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by imf14.hostedemail.com (Postfix) with ESMTP id A05AF100007 for ; Mon, 25 Mar 2024 17:09:49 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RKMW4wAD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.171 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711386589; 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=VYjqm/1NdDhDA4E1plMxFxGv/E29PMV9umo4qLhPFZY=; b=Z2/lxQnUDAVbDig79SY1crXNzsPK9VNGv09XtubNkAyejE90pjwbNA4SIpVd34w80w/zvV vFlvdc8+n0dMpnZiCy0mfhbghkhKJ2AONFgqu6VaJFX6LU6Vos5+F3rsXTWiI34x88FVb2 jNspxlxnyKsvZBo3CRCWHXczbyOUbQ0= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RKMW4wAD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.171 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711386589; a=rsa-sha256; cv=none; b=G/l/nNQzS5vof57/7Nv6spZpo53pe6DasloR5Za1E7dhhlWYltzFswez219BWtGYaAvvTj 4JELvdd1KNcxlvs3u6CPM7gnID3NWF9RDs6b3yFJvp6jNdz9BYxzxFVl569vZ5Zb3S+fQ9 EstlOjSqaKBnqMofjcyIG5YCelZFLVg= Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-788598094c4so223119485a.0 for ; Mon, 25 Mar 2024 10:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711386589; x=1711991389; 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=VYjqm/1NdDhDA4E1plMxFxGv/E29PMV9umo4qLhPFZY=; b=RKMW4wADV8+iRtOphGodF4yGRULVXkMXysvIbe/H95SO+ZQIPZV3+jMTGb14ENLxYb cy2x/EbROlu6KWj0eVne6qpdeMGYKvIq9VwL6HrKuq+5SUOdJIHxvgMX93ScUo9QPLY7 l4uzj5F6MXI2240X9NQ+V8UaBzhYGkHNE4sVdoLuXw83B2uF6VeT6Vnd7H1vf+SwQOzt gOcRssdfdz5HkAiy3qrhozmmrwHTce/mC/FDyRyq2oCh9Jk2Momx6dPBVpSDazTKmQ4t lL79ufpsHKsErGYMF6MSix/GMOu0tv7eF0e/p35XLH2RihuzuKyEqbflZVduHQ8AV9sd WcjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711386589; x=1711991389; 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=VYjqm/1NdDhDA4E1plMxFxGv/E29PMV9umo4qLhPFZY=; b=u8Eviprwwb1mW6HNkLrUHd8BC863okZ+5tYVUX3Fkmb+IIQbv8ylLSgk6atCPHTHfI kDUkv5k9T1Fj4Vpc9MUu79GIVMbFmt7izrIvkGzsdlOs1yHjNB7350Yu4HRvIB8jhfck VlrOFmK3eOZQC9xvsKHSUEJPyQ13wx1X9c3G0cZdLEkE7oOXVz1CncGj3+TFYiRydJvO J7xnD+UwmyNrnvyjhM6tr6e3PcX3zGP/CsPb4HEcqdlWqKaAqQpr7APG0wN/JW+xaT15 XFy6ffWlXHqEdPtXi246/lU6J8cgkxzPT5ZEByn8VlJ5C5hZxCU7zOyv5NtC7ZMqN2vE BA5A== X-Forwarded-Encrypted: i=1; AJvYcCXIa7Aax8SvXWvuPgkmeBVvHKR1AFYMp02K/66mTVA+r6gd5hpa1h9w8R8cLmREVna4egx+mg+fs+ws6HDovvcx4PM= X-Gm-Message-State: AOJu0YxW4OwswtUy58T22ixN5wxdSrlMsLf/ou6bOT75DgfrIi1Ks3Nu CCCyFUo3g9OOxWjDhIg7JpHF7GEUzAgfjR/rj91kHJaL8Pj3DwfUyHY1UJd5o8dktkXAW3EYVEA Pgc9HMPW04JkRTS0bJVGeogarGdDoUu6jcUA= X-Google-Smtp-Source: AGHT+IGfq12zKT1PPjPcEbfjPvQzo3NpeJjnbT1HJh4i4YahabfVLlS4mvDswjzBry9WP/zm4+Ht56Pq9U7sfG8SNw4= X-Received: by 2002:a05:6214:f23:b0:696:45c1:4c7c with SMTP id iw3-20020a0562140f2300b0069645c14c7cmr442408qvb.35.1711386588678; Mon, 25 Mar 2024 10:09:48 -0700 (PDT) MIME-Version: 1.0 References: <20240324210447.956973-1-hannes@cmpxchg.org> In-Reply-To: <20240324210447.956973-1-hannes@cmpxchg.org> From: Nhat Pham Date: Mon, 25 Mar 2024 10:09:37 -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 , Yosry Ahmed , Barry Song <21cnbao@gmail.com>, Chris Li , 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: A05AF100007 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: q8swtkwjx1w8rzu8hyyuo4f31k7cx51i X-HE-Tag: 1711386589-925065 X-HE-Meta: U2FsdGVkX1/C+Gx7N9h22NUr+i34p6qgpQJsafr9uEdan1B23sYcDKEWCjDsHzSKO1fA4FFyWIrluJUgJg1hFT1e4LoGruauJoZ6PEW2UM1NGIeY2Oodpy5PRh/iZ+Ayv96lDAp3YUyzODbgI7d9eGjOavqym307+dmQ5qcWyLPP9ZMmGHu8hiueDt0SoXuVH+VPbyl7ocDAe+kx1qFtTqVpoybFkLJAQEXJfMGNic5eZ7Ilft9799TZZ9jOkeR2IaWiRqT6Z7W/PoT91HtqWuUDVWviiYf8OzXht5s7+fXOsCyGAyIoCSeIcdIk3wX/Hba+cI57wf8gyFwCvljv40GRScye7kLvUxcklok2T+kpumUxkDinVPM7nwpDCjIpD5TD466prNVtphBhQ51s0NcHP0GivgEFtn/TRDRhIdsMBbP3rgskI6NDs8aaA1vpmGqdN8zbQFGxb+xO4Kvy+9+jkLDv51sM+HV8qu9DBKbLvuRzPg0LrJWzIx61YPnsEOaz11Q4eR8f+Kx69gEwT3R19gRUMbQaGnmWGHPTJW6rgQP5f5xqjFIaehRt6slQt+DzgyWtGMMPBPooXD5XAhG6OcK/C7AJlCMu04vQzfCJm46kl25b09EidwYDqNhsk9OjJZloLFww2oytuDyHp6+6goEjzOZVTBsIgUhlxkmnClkKFW/qoPeEHbH8F4519g09poyFaVp5LZ83s9+EQ8BsAxJsxB90anlXswwRHTzgOBO7sx9KuRZOsQhsC9FjWm3xyyqloj28MrXQ+lF4PGSYc6JHodi6VCzYYbcbNNnzbQhWR8wumsVYBHubR7o+G/Os8aTtEL9y/JApK12ijCSkrEDnoBvAVnFjYHT2k6WzHE1wMNh34YE7pNsUjko1MHSkFtiQGszWIYZBSPVGZPqlit1mQohBUn5+q1W7Rn6tTNgRjc5JF+/uqM7AV7ALrHcZ0WZ4QM20zYcG2Yb LDDUdH0C Xzpg+5a7jnunZsOjpfiAY0mc8Qb0MlyLGwxXdj17f2NQtDr8aTKVazQvECNJCmEVcWsoKjrSSsHhFYIki8PY8be9+tKUHSdEyiv55JAdPp41MNmXesq5wWejHbtuTnuad4nfirpcvqrRXc7c4mPTd1pnikUh9A6k9J/jmJ/Ne5IKQ55doUO3fSSGGTmUU1Z0NNN/FSPPWjEyxcwW6B1TFodrj6sjy/rsmpw03s3Be0Ov/t6RHNreK4R0kZB/sgYal/itJWqYegp54TXFHPxmf3LjSDWN3dP+riDhxg6Y5Rz1bsjgmtLG/BpmlUPVDq/iodpK2cgCsgLTW8hjYlgtR7VhpyvWYdyTmeLU1GiofIdK8WHssK0X/H04TrAXpIgulwW+Oz2CQwFtlnD5tM+/DXJ5U+ddboLhtRJ3Po1u/hjrre1grfeunLSbMGSIf6mZVQgKbiwB9FrO2RcMCjtDUtzJfFUz61CEmpJ7mF1Fmim6XBiqMajVi4Zhji/Z7mEwB5H3M5iGlqleho8q2LfGEFS36QkotbXaBzdE6lsiqHbTocCwNk+GX25C5EGiR5EX93aJy0wL/K/EHbQyxgzVbOPjl8g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000409, 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 > --- > 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); > + } This LGTM! Reviewed-by: Nhat Pham