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 C8742C47DD9 for ; Sat, 23 Mar 2024 02:50:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 296C46B0085; Fri, 22 Mar 2024 22:50:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2474B6B0087; Fri, 22 Mar 2024 22:50:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 136386B0088; Fri, 22 Mar 2024 22:50:23 -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 044A26B0085 for ; Fri, 22 Mar 2024 22:50:23 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9B429161659 for ; Sat, 23 Mar 2024 02:50:22 +0000 (UTC) X-FDA: 81926775084.16.E8B5F3F Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) by imf25.hostedemail.com (Postfix) with ESMTP id AA297A0011 for ; Sat, 23 Mar 2024 02:50:20 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=SHczEdYL; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.171 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711162221; 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=jo1kf1K5kDD2UFW1uYSmrg6RxPS+DXRGfZXC9+hP/j4=; b=AZLToYlFWSG1DDS64lXRkjX1R0s6s6RYQfayf8p1sqa2erwCjEgTYWwmUAhpq9vE5t+xyz fmZ5GBVS9b/0KG1OXC4p5jS9Y+0aWQXSZhYhi7VAeCgQ1oD6UtCGKnvTJZqxu8nz5RKB5/ 2A2NGGLC3PQpxM8T/RUnVCjEiHlhWFo= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=SHczEdYL; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.171 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711162221; a=rsa-sha256; cv=none; b=7DyL2rGNHIEI70SRyYZ4Jbn2prbxVmw3L7ZSNmqMQshxe4uFbz44n4xgds0GIYVCMsoWO7 kyWtwaGELHswjBh2r0B+j7pqDJ+3pQbclwypedCueeTAvW1zjAoae+fsAB7kfMtEoNAI+f 5S4YN0n04zELf2f9hw5JTho3BdqjPwk= Message-ID: <91c0a5aa-86b0-4dd3-884f-39a47c1ed6b8@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1711162216; 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=jo1kf1K5kDD2UFW1uYSmrg6RxPS+DXRGfZXC9+hP/j4=; b=SHczEdYLYtVOHZSUtcy3mvfO7UD2g8kqTObI6e6o3mJOuRo5jP9fmQYj1fcUIl/8eFW/cf vGlg8CqVNN69TSQySUWuBGFbNB7XwiWXBU8BL5+Q/AhaFlERQK5RoLJCUQFRVX+yb2FWsf ETWOZbxsCeRle5PYTI/hmf4KLx4jsQI= Date: Sat, 23 Mar 2024 10:49:47 +0800 MIME-Version: 1.0 Subject: Re: [RFC PATCH] mm: add folio in swapcache if swapin from zswap To: Yosry Ahmed Cc: hannes@cmpxchg.org, nphamcs@gmail.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhongkun He References: <20240322163939.17846-1-chengming.zhou@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: AA297A0011 X-Stat-Signature: xyk5kir56qc8rfggf3qe9n3upgd61i37 X-Rspam-User: X-HE-Tag: 1711162220-317520 X-HE-Meta: U2FsdGVkX1+J/p7Qq4v/KdtXvE00aChDGXlDdj4rtdvp/FmLWZ7H6CCLsANxik/Wr1LIKXSd3dMnUH1xbCj0P+pNrHzlVlCf+H8m4NtP939eVsMVbuEYBjXCqZ/3jyKm/EcwefW2+rF1Xriy9Pke2ygfFmA+fKx0hM8C1vsOyEQmYM9bAR0WN00GlqXZNqaRDwHwIEKPTHL0xCmWODZBnQ7YSopaIRLnIkkl6TjSU4Nb+92xL1528uWeY5JBFAKifn0ZP6AkeG7qdp+IyCaU5Em/WGX56c4bTBqphT1LZfKmf8XRZUoEIPmKiGJqQIvKChOaun6Ax/De+ZNf6D/LNDk3Dqt+Ewxt0ToJ+NxXfgzEExxc09M/9rAuOJIrutpd0+3ZVRrMGRqk8OdCQK1YtekZirWIkt3QwdF2DTTWG7ukPwohWfbP10rcWxBH3W0BsDzT7AWlR4py8vA6oiXFE0LcNwFkn/DD3xZTGZ1vTh1Otlptk7Rrn4SVi1ngTECUevnd/x18RWXyurlAQMAe5tbggB67R27uB0IorYIGn0QR0YAVEDnvmNJGW2pHJbnpOz+XpahPyQj+c074f9GcOV2GnGw044+WCK3gOH4X7SdrvS5sNaQJZpcfRoGnC5qBqcxyn/QLXDgAbIF4Ako+ZoW+KCFGdnu4EXUpVuC/wmCTzhJbrcKkdIxLYFCyCsb/Sxz5Khrv56jhMAXT4jQ7qEN7jKzoSWEj4//jwt4QkMLKnMtcMY0Ox9U8YpJfqfxLRdzNhKNfCc8cf8RczjKAAkLWDdDqjN6WjycYUXyj+844PG7iilms86YEgqKeE0tKTUAzBIb9Rovr8YVnjS1wcuuzZgpOyYaKsBwH3HcWHK/2Nj6p9VbgEkzDU2HOiUAbI0AH7IR0LXcDse6pVEDkJRahhKNTHbWJPZ688DbAR/f2a44EWIQk+8J1SxMHFqAEvZhJYSVLFe79BEpQtOB WRb94eO8 4E7HIu2NSYqFPbAIahtKxjSj7TIEU+nbA97TOTK1AwtfKEr938v685cDPH+L7T6Z4sMUMOfJ8AOqKOH2F+qicGJeIUFCvMxubaWK1VToD2+HISq9cM3TM2ckZNg== 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/3/23 03:37, Yosry Ahmed wrote: > On Fri, Mar 22, 2024 at 9:40 AM wrote: >> >> From: Chengming Zhou >> >> There is a report of data corruption caused by double swapin, which is >> only possible in the skip swapcache path on SWP_SYNCHRONOUS_IO backends. >> >> The root cause is that zswap is not like other "normal" swap backends, >> it won't keep the copy of data after the first time of swapin. So if >> the folio in the first time of swapin can't be installed in the pagetable >> successfully and we just free it directly. Then in the second time of >> swapin, we can't find anything in zswap and read wrong data from swapfile, >> so this data corruption problem happened. >> >> We can fix it by always adding the folio into swapcache if we know the >> pinned swap entry can be found in zswap, so it won't get freed even though >> it can't be installed successfully in the first time of swapin. > > A concurrent faulting thread could have already checked the swapcache > before we add the folio to it, right? In this case, that thread will > go ahead and call swap_read_folio() anyway. Right, but it has to lock the folio to proceed. > > Also, I suspect the zswap lookup might hurt performance. Would it be > better to add the folio back to zswap upon failure? This should be > detectable by checking if the folio is dirty as I mentioned in the bug > report thread. Yes, may hurt performance. As for adding back upon failure, the problem is that adding may fail too... and I don't know how to handle that. Anyway, I think the fix of Johannes is much better, we should take that way. Thanks.