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 AC672C48BC3 for ; Tue, 20 Feb 2024 04:01:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B55F6B0081; Mon, 19 Feb 2024 23:01:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 465C46B0082; Mon, 19 Feb 2024 23:01:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32E9A6B0083; Mon, 19 Feb 2024 23:01:25 -0500 (EST) 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 234746B0081 for ; Mon, 19 Feb 2024 23:01:25 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BCEA1C056D for ; Tue, 20 Feb 2024 04:01:24 +0000 (UTC) X-FDA: 81810832488.23.06F81CD Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) by imf01.hostedemail.com (Postfix) with ESMTP id 02B5040006 for ; Tue, 20 Feb 2024 04:01:22 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=a343LL9H; spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708401683; 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=f+7pW6Td4IjBVEl/B0SbCdXWjl+KiOYugwOPe6kZqWU=; b=KwcLgIiIWe+VWsThiN0ZKf2mkps0TZ4pA7o4gAs0uK6t1X85hfbikdLoX6Sw5dhGsd+rEp ylaQKBmozACziUf/erwxH4LlVT5ir8LsUcZ/NPGre8km1JxVmkQFlRyxxfFBRdj102wmbo Ax+4lPqYC8+3JXO6idHegOpPoDSNViY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708401683; a=rsa-sha256; cv=none; b=S4QTyUL9gPE61Rjj2yuJKGBGKZU9QkTRtlwZs+D04sv9BpG/7DDGgmPj1+MtsaVJXFzhOm BdCwihnOkYMFv7gdmtHU9sqoRloixcgCPgnYlbaTVflgFptJ++YytUbKymZMZtAA/XHhg2 rIsrqfSl7CBGFj13RH0JuefAB8SaQeA= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=a343LL9H; spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-f181.google.com with SMTP id 71dfb90a1353d-4cfa1b3c3a2so18790e0c.0 for ; Mon, 19 Feb 2024 20:01:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708401682; x=1709006482; 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=f+7pW6Td4IjBVEl/B0SbCdXWjl+KiOYugwOPe6kZqWU=; b=a343LL9H5RGPUnN3TSEfXnd2fOOEWbKgvk4dz9aT/RekdPcKQf/r3NhYSfb0Q0P9pn KMxlu/t7u63LhkoLP3kNIp6LG4LWtG8+fnFJiQWFp9XlaeaTx8vwPt/yP5tPxZ38l+Vz eVn4qUiJk01bhCyycXjS45OwGaUNKMc94KxsOaor0nhP31fCbkQfXZ/mMn6LRftTET16 ZZSqncHDUP2VHj2KEi4uKLEy+JA0+eq5LtxVZ2qmFPEfK1XY8IJ5CdIgRAlGCfHcXFzU y7UeE5EEVgEiMjAIdxsrVn4u0g24iYL6PiePrDdof2Obd2NjPoaFUf8Ho/dzpK+RyhYI 1oGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708401682; x=1709006482; 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=f+7pW6Td4IjBVEl/B0SbCdXWjl+KiOYugwOPe6kZqWU=; b=opiQz8Zr3ok1wHl5enspqaDB32tmJV55D2rf/z5S5x8aAFi+POd8CCdN+tWXk5wcwP 4ljjee2hXN3UOoomH3PYvfwGJeTEQ9jYmPCzNKuqEJ00VpZIkXg6wXisOTKogFvPsfEK /sQHdzri53NOLPCIONdYa9Oi8RkDpGJieTZpGPBQZFK40JhG7subDjBn0nbEQyoCRSOX GaUxgZnTBXz0HfjQPLhBD6W69Xi64mwDq9p1eH/q3nsVvbm6BRHNicrWRGuSLTqzPLNl V210SkLTU6vLqBocnjlDBs1a62aY4/U+4JXDPmLaTUxDj0cp6IC0zosecER11Gj1k2w6 bOKw== X-Forwarded-Encrypted: i=1; AJvYcCUR1+Yta7GWzp3MdfvkWTZPP9oJc2sMgX2NbfeqZb8bo7VZmqAO0NcvWB8TBZPwl4jc6ucKN5dCZDwfW1HdsllyUzo= X-Gm-Message-State: AOJu0YyxVd6NgO5RH8t+4+ECnzbsWUJZW+YVMzbVvZHw6dj9OLGlFaG/ NA/DE5AdLUWq7TGqiYXlDBFuO4USK147hoAoCuS9V6uywiF6lwBPHvVK2nyVqQJMoVI6HixTZHP aI9tNJ1z8qP2mTswZ4v1ne/yIpS4= X-Google-Smtp-Source: AGHT+IFUkxASTfr6kUI9b9huZmglHUE9T952Z7XdRzsNguJ3X2T+ZQSSBykmkMWcO8VrT434z3zuJVKd57OPjBZO0jM= X-Received: by 2002:a05:6122:4d0f:b0:4c8:df97:139d with SMTP id fi15-20020a0561224d0f00b004c8df97139dmr4748249vkb.2.1708401681914; Mon, 19 Feb 2024 20:01:21 -0800 (PST) MIME-Version: 1.0 References: <20240219082040.7495-1-ryncsn@gmail.com> <20240219173147.3f4b50b7c9ae554008f50b66@linux-foundation.org> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 20 Feb 2024 17:01:10 +1300 Message-ID: Subject: Re: [PATCH v4] mm/swap: fix race when skipping swapcache To: Kairui Song Cc: Andrew Morton , linux-mm@kvack.org, "Huang, Ying" , Chris Li , Minchan Kim , Barry Song , Yu Zhao , SeongJae Park , David Hildenbrand , Hugh Dickins , Johannes Weiner , Matthew Wilcox , Michal Hocko , Yosry Ahmed , Aaron Lu , stable@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: jq1f48fr7soa39r8qgeohp3i3e4n13ye X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 02B5040006 X-Rspam-User: X-HE-Tag: 1708401682-256866 X-HE-Meta: U2FsdGVkX1+X+mzRJbTqUj3uS9iWZjkGBMCRXFFCx7ZYh7h1la84uBtnRvcQ1lGAciVi18W4HuW/TqC8hpT4EMnO/zn2Dw4bO3BIp4MUxng0BWlWYe1VuNvIKXOVW9ObVbBaJ3Rtnc1U/hcjY+1Um1KPoibi7g9xGxpr+Dg77XMJsscD3dDZb6tINhwmJft2erBfGa4ewMp/HS6YU/55UuZfpo4is2dG+epAjtcv+0GWKYEVTHtMpM60IJXFkY+BBoFzwon68Iw3AuWvO7wojdel5ER+LhxZwLNdbnlIDFYXhOGHymQCiWF/0bCv90VUXSmF8hEDjvxAHyN/NunODuuyOwKnTdpxbMqfdiCTfZk01wXPC8uahzS5D9P7EKIKjtRmhom9dM95fY2BI/8JCl39rtBrCBAAuDXGlh2D+xpSGCqtHvxs/FzgyJvJyY1N1n3Cvx5lJ5HjtOq2HK0quoZSbZVMVpOd8DAcIQwaZpg7+NaBXNA4noQ1F/X2UaJYhuzIsqWtk/iptfvVa08TKCC311028V18/CEkWBMFMo5wwZIRzC3LpnDGmbEFWjhwjnJ4oRAdvML9RE4WIrL73KdZNS4aIrn4hW+RtMSot7vCbhaJ+Mdq19BMCjBd8jiZB5qWdQLFwGwi0kWvEW+9iliEyLj4RzWE9b7nUAGhbmKGOFMz3TazxRhP85c3dZUFj58sLknH6m+c8SmMX2VchVrgZI29u8MxGR0ixD69KH1OHDIjbV5+GRD1TPMmchaeNaJv7GTgR9GNXN3XVfht9yILbFBoNyjG1+hLVlBuyIwpMCdGEWQys4AEIi17AzOdpZiu7a3P5hjm7JJB53+1QxqsOR0PZKY4fBW1j6qNrrB1g4xfSKXRTqjCwOjIpkYSin25ttq8HMwJKW4p1OqJP1fi7dwV+xabmxmAUlhpw3xGO9RQyAwjQszouMvVwmYgrQcv5k0U/OipACru4cI orqIa2Wq xBWoBGbTGfZoke9/9vtOMjjyRkPg151Jb1OV4NTUUxgQLdEGHCI/N35Ctf0SudDR1C19oa2cfNPgMEmhO/0v7udhys62oRi2Z+u75PPtlijxey4EGs/tuxIW7Gxx9lUKAVrYe7DiN8VJH5yrtp+9n+pYef2hsY8jqSTJdHRGS9IQWvu7QQ2F77P17CHqYUQkOazfj83gEVaw/Fmc5DcBKCJPJF5G2LfAifMRebpz28uBpvMw2ZVG6QzthzUjGeE/2tHee+NFGiImntr17Fy1fEAZ/4tVEaEJyDESM7AdO1vDnJpjTQKNMjs9ScTUF/5FxSHvOW99I9zx+IRfYb3YeIgGDRbsSwLuR2rwRMaTbbEM0v15ioxvufEvyqhliBiAHi2/YwtQRykUHNn/M8d2bQbdm4zMSOo3++V8eJ9cqkcB98zF5UV/OljkpSAD18YmjpMRjt2vz4RPJsCniLPmUr7JAhfyZOrHmzGPtRMCAPA8oA6j/QJZQR8MyPQ== 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 Tue, Feb 20, 2024 at 4:42=E2=80=AFPM Kairui Song wrot= e: > > On Tue, Feb 20, 2024 at 9:31=E2=80=AFAM Andrew Morton wrote: > > > > On Mon, 19 Feb 2024 16:20:40 +0800 Kairui Song wrote= : > > > > > From: Kairui Song > > > > > > When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more thread= s > > > swapin the same entry at the same time, they get different pages (A, = B). > > > Before one thread (T0) finishes the swapin and installs page (A) > > > to the PTE, another thread (T1) could finish swapin of page (B), > > > swap_free the entry, then swap out the possibly modified page > > > reusing the same entry. It breaks the pte_same check in (T0) because > > > PTE value is unchanged, causing ABA problem. Thread (T0) will > > > install a stalled page (A) into the PTE and cause data corruption. > > > > > > @@ -3867,6 +3868,20 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > > if (!folio) { > > > if (data_race(si->flags & SWP_SYNCHRONOUS_IO) && > > > __swap_count(entry) =3D=3D 1) { > > > + /* > > > + * Prevent parallel swapin from proceeding with > > > + * the cache flag. Otherwise, another thread ma= y > > > + * finish swapin first, free the entry, and swa= pout > > > + * reusing the same entry. It's undetectable as > > > + * pte_same() returns true due to entry reuse. > > > + */ > > > + if (swapcache_prepare(entry)) { > > > + /* Relax a bit to prevent rapid repeate= d page faults */ > > > + schedule_timeout_uninterruptible(1); > > > > Well this is unpleasant. How often can we expect this to occur? > > > > The chance is very low, using the current mainline kernel and ZRAM, > even with threads set to race on purpose using the reproducer I > provides, for 647132 page faults it occured 1528 times (~0.2%). > > If I run MySQL and sysbench with 128 threads and 16G buffer pool, with > 6G cgroup limit and 32G ZRAM, it occured 1372 times for 40 min, > 109930201 page faults in total (~0.001%). it might not be a problem for throughput. but for real-time and tail latenc= y, this hurts. For example, this might increase dropping frames of UI which is an important parameter to evaluate performance :-) BTW, I wonder if ying's previous proposal - moving swapcache_prepare() after swap_read_folio() will further help decrease the number? Thanks Barry