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 7BD19C54E58 for ; Mon, 25 Mar 2024 07:06:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C3E16B0083; Mon, 25 Mar 2024 03:06:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 873B56B0087; Mon, 25 Mar 2024 03:06:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73BC96B0088; Mon, 25 Mar 2024 03:06:49 -0400 (EDT) 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 64C676B0083 for ; Mon, 25 Mar 2024 03:06:49 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E70051609B0 for ; Mon, 25 Mar 2024 07:06:48 +0000 (UTC) X-FDA: 81934678896.03.55B95CE Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf04.hostedemail.com (Postfix) with ESMTP id 1FE9740014 for ; Mon, 25 Mar 2024 07:06:46 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=XU5vdfil; spf=pass (imf04.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 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=1711350407; a=rsa-sha256; cv=none; b=4hprwnbH0unXcpVDzDYUZyvMuHiWysFnfHyhn7EPGag/DiuLt/cbxjWAiz4zBFOy2gIjIW RaNiAWk1qcTlWDYFH4Z5lgLq7IUIIrfgrc8O06Y0YdTe0RQxRrSvdNbq9BEClYtZ1iHIg0 uxoMKgVsI5kIIAL0Uhw1sK5ytZExXeY= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=XU5vdfil; spf=pass (imf04.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 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=1711350407; 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=bWEJsPySa8D1x2bmugQHj3Wlfs+F7dNk4IRWtijp9Bc=; b=BVciix4snOt0E1u73P9EbiP+FW8oEO86KhG14j9EeBxlPgjKhjVaKDOoATIK5D+iF+/aRN yhDca6t/mDr7g+VUmFdXb1EehhY0QsSH7bUadyHQO5Ssu+E5HmKWkQl5dH0Bz9VaWL9nUk a8MqSwZ4Buqq7Zj/UhsIZTsk6t+Vs8M= Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a46a7208eedso547375866b.0 for ; Mon, 25 Mar 2024 00:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711350405; x=1711955205; 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=bWEJsPySa8D1x2bmugQHj3Wlfs+F7dNk4IRWtijp9Bc=; b=XU5vdfilfEUe82ovpcizQ++ciOUbfIdfxYe8kHbHumHW78wH7vU32d5ZzxnGyww1io DaIiEUWLQmFhP/VEICnm0gq4Mt72nptIwfKsdW/5w8xiM1co8Ygb/y6vD0Asj8TDylv3 zJyaR1j2+mPK3cwA233aNGNdnVS28zJwWK48/wealzJIKoWwehp9SRC2fLRV/ZJ5mGzZ iSyfwIOkA47p2kWo3pLByMhXzSH7vRRU1B/bMVmgKnbQd83Ve7+/tQcXNHKUJeWNTP1u KC2dCXE7RI6nt1hEUVzf39YOmrF5Vk38st+TK3pHuyjEcLHf1fr5rYsKD9nGq/0JbnQ9 Fs4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711350405; x=1711955205; 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=bWEJsPySa8D1x2bmugQHj3Wlfs+F7dNk4IRWtijp9Bc=; b=RzpS7CYQitb8HcA8b4bTqx9UPgQKeFZd6GUwHqDWTWR0uT9HOHzXyTd0R1oQeuC35Y AChQuofthGPdJEZV3AIZxk7ySeONBaOE+7kr6z0x5lxr7TcYMWAyJYWNOlOkmy7Ew7gn HTkrli6CGLN3UFxvYswNy3EAK/cetLz4PyKAXw/7b53hlvzSF+vs59xtFQzPP0Y7sg+T aBxHCsX+puRGC1LL+aEfIZ1e0iE/rB9xp21+K08beTgrhKb6H1jzdX3tbtgjhBbHHu/z ks9VxVIjS1hLNP8EeaN6KGPfZvUXnN8V3Cbjv9+UGyXfFKNohyM8FcarUr6SYkSPgpob POjA== X-Forwarded-Encrypted: i=1; AJvYcCWqZii75sUMs3xvkj4d3pzkL2+fHjuvSv13UbxPX1USNt9ELMeGdHHxSkRsBU6GOcTslPutVCZgCLHvBu7S7AY6c2E= X-Gm-Message-State: AOJu0YzLXH7LED4Dqx98VpWiJ5Zae2tB7vFfiIu2dK5JUmUTw/LidEak 2JB0uTaTaqcsMLj8/fHVoQmhqSME3KRxcuoFVu43O+tN8H8pZQ+RjYKd1LBLEN0IMMPv5jzod1N ToyHZGJU2pIEDuUp43phtwwqoA/qAnqGZy2pz X-Google-Smtp-Source: AGHT+IGeh6p7jRrQ5NLQb+ctZ5obvIhMI8r68jI7hSlB3NPaFsjdKNg4oeq+9aK/HqJcrcULfjZpMJ53P8teGIVWNa4= X-Received: by 2002:a17:907:1002:b0:a47:35d9:2efc with SMTP id ox2-20020a170907100200b00a4735d92efcmr3804422ejb.56.1711350405144; Mon, 25 Mar 2024 00:06:45 -0700 (PDT) MIME-Version: 1.0 References: <20240324210447.956973-1-hannes@cmpxchg.org> In-Reply-To: From: Yosry Ahmed Date: Mon, 25 Mar 2024 00:06:06 -0700 Message-ID: Subject: Re: [PATCH] mm: zswap: fix data loss on SWP_SYNCHRONOUS_IO devices To: Barry Song <21cnbao@gmail.com> Cc: Johannes Weiner , Andrew Morton , Zhongkun He , Chengming Zhou , Chris Li , Nhat Pham , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kairui Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 1FE9740014 X-Stat-Signature: qk6bmuo6pb7p441wx6zmt6qu4xoj8exb X-Rspam-User: X-HE-Tag: 1711350406-842567 X-HE-Meta: U2FsdGVkX1/ivFztYaK/5UY59vwipx0ioj9DgghkjknOfbyp20XO6nS9K+JlIeVEyI3Rokp3qgJXAxS+CLP5c667k/JDjXd0w8mEnN2hcvGzMRKjss2uc6s96ocj381hZHjQp4fLeVwe4Vb9QteFlrUh96swG6m5qFtakE1VpBPzDU8odad9k2F7RLCoyfoO7R4b5KIZNfgLvZHm3NptMBQ5nmA/g+tn2SFKgpcNMOdlRbvEg/o3X1PX/9UoEYAchIFreFmxjGi9vJTPEgVKgt8YFUDpQI6gHFQPwNhcSBhAIT0rkOBtcM2oc2WPxsIgGmfBwizou28o5eaUVtDaXF4kgtQgMwQrCRigAkUvKGhbuAmI680w9gFbWV16kIplbgbGwbAAJBHeRxQnD2gVAR/s1C3sfhJX0uuNVjUPTcZMlk5md5JwwhyqRHR8C2o6XxSZzrUX+bzD27+gl2MkUDUfHmQ0SqbksKBg+4lIx4qKNA1E1BOVUMCcE3ftf65IidP+bPFw78lzr3WMyMjIK33T/0bpbfZIvgWYJPYcQWY6HXuuUfjVFvXCZNfvUHqiOEeXqFBysPgY4YR66kwxtj1J4K8wXEiutZ3nxKbqxuPvkkEabn+5WjAgOU5Yfvz+itBcqFTMnEUO/EJOrCLhK7t2MaE+FApCtuiU+kNHTcZtDw5aEzO3mobjG3nYWa8ExnanzEWFyQv2AvhalNAyXdSjaXzewKx46N79GSIDVhBoF1xANwawdpTUByGMxn/dOA1GOljcwwCF4TgQptn+3TceaUlDm7WfbWPkJsNp1ec70Q48goRQynZaNEDSN65zRSfZZPD5ojPdUsn+I82fmZJ6jJalTmHqPyReOulh1scIbbilxvuuofr2yTlRTzkEc64KIABamEQalt+YYvf/0zfO4XvECiPRVuBMa1tloVC473GCmJ2S1dLCgPmW9pLNfY3at3e5u6aCFSg1j8x rrAD6Q0u 5YZykndQIW+MX+gyjztQPENd97OEFlDMxrHNB7kBmZ5TLMzaPvVNRgIZOLo2dJKy/Q83RCNGX2xrjUEUYvBdaNu7AAfq9PtjHVGySOTSpVSl3Y1erf7N25nmjt4t5WgUWsrUaoPVkYrm22AmQ6KdVUhF06c1NaU7VmlvhDTee4J0IB3dyd/RQywWXLMCeYP/sNAzBZKFNKEeghyJUeTCELd2YskEToSt56LFu6Gg/usq7UlzDcyFTH5HeXQwPGhkpEo5U4xfB76v+jy4fcIfw+rPkh3AXCFXYnPOdJlGBQYvnv4Bc8gh06iU0lYydIJ53fSTfoGbl7AYHyDBFdg5Ys82w86T4eamPyRWoacohPhxvWt0uxvhoQfxgYY/GFdNN3uqwAL6Xg3R/wpqBhPjYAqRKGc85TexUWS2hjUuPOiwyMoIvCOhYH7RlZFvn/obRD7WhuI4QxXql5Sssd3jUHnYDlY8gki3v/pVgcXWf4FfdsA06WMN8CYm2Rw== 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 9:54=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > On Mon, Mar 25, 2024 at 10:23=E2=80=AFAM Yosry Ahmed wrote: > > > > 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 tr= y > > > 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 t= o > > > races. In this case, zswap mustn't drop its authoritative copy. > > > > > > Link: https://lore.kernel.org/all/CACSyD1N+dUvsu8=3DzV9P691B9bVq33erw= OXNTmEaUbi9DrDeJzw@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 > > Acked-by: Barry Song > > > > > 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? > > It seems that Kairui's patch comprehensively addresses the issue at hand. > Johannes's solution, on the other hand, appears to align zswap behavior > more closely with that of a traditional swap device, only releasing an en= try > when the corresponding swap slot is freed, particularly in the sync-io ca= se. It actually worked out quite well that Kairui's fix landed shortly before this bug was reported, as this fix wouldn't have been possible without it as far as I can tell. > > Johannes' patch has inspired me to consider whether zRAM could achieve > a comparable outcome by immediately releasing objects in swap cache > scenarios. When I have the opportunity, I plan to experiment with zRAM. That would be interesting. I am curious if it would be as straightforward in zram to just mark the folio as dirty in this case like zswap does, given its implementation as a block device.