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 2A95AC8302D for ; Mon, 30 Jun 2025 09:18:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 998666B00A2; Mon, 30 Jun 2025 05:18:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96FFE6B00A3; Mon, 30 Jun 2025 05:18:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 886116B00A4; Mon, 30 Jun 2025 05:18:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 734416B00A2 for ; Mon, 30 Jun 2025 05:18:17 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 10C6280424 for ; Mon, 30 Jun 2025 09:18:17 +0000 (UTC) X-FDA: 83611515834.04.08CE883 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf13.hostedemail.com (Postfix) with ESMTP id F2A672001D for ; Mon, 30 Jun 2025 09:18:14 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=O69c0sef; spf=pass (imf13.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ryncsn@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=1751275095; 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=PnIpIZ4G/sjmfy7xy3QJFu6/ZAKk6jCpqqTswmPwA1U=; b=Fe4MfgOzw/e66Yc7f+vxkrEjqtqfPZyuQr5wFZFThozk0JO3hwgB7bZIuiBWJbVJ7qas5P Xhy7LMPCO/7Toov0hXPzndobO/qh+R7Wdo6T7ukj/DWUeJHMZ1CpQ5nY/KBYtBLhkTPl9l ideFc+jbrnptd1zd74OPv6Jyw1qLm3A= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=O69c0sef; spf=pass (imf13.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751275095; a=rsa-sha256; cv=none; b=dZnEEtD8Pcc65Gd4pppaQfGRIZUqdmOzoxIkIXWKJIiNXZWmazWlI+gi/zbfKGwYmtwo6Q A0VAlM2V/kInFrUed7jSjI2Ju5OcswU4ku/aRcgJckNTOQ7ivqh6pDNIIHzBiiKH9LvsyE Tob88XsxNasmZr4oMk73T8DB5601pXI= Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-32b8134ef6aso39320981fa.0 for ; Mon, 30 Jun 2025 02:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751275093; x=1751879893; 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=PnIpIZ4G/sjmfy7xy3QJFu6/ZAKk6jCpqqTswmPwA1U=; b=O69c0seflQRE4k5DFAJsGYXsWCyf6RneLjavUXXgVPqTMwGTHJxzLjW5ofq0+GL40b usvAHxJG0v5i3HIJI8vQM1MC4ucFgsUwJbHB35rbv14gnTzdiRkUpvVEKXojcayjePxU Y0tlx5HYKHAyn9kF/XOWMDBGtQRUYxxIpqhNIP899wkJLTmoqgLHoT0wBYvQiEAL1gKD 4UzD9NZ8CkvGXxxQmsheGNEXORf/5leEP3hZUP0eWbWKUVA0qmW2CFQTM+R+hvHuS1ap GeZmaPQcvJ3h3O1wfd5suGMZoR0FR24IuXc9aMcxQdllLQNlgBIQy/G6+4WBuGg2tpcV Kp8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751275093; x=1751879893; 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=PnIpIZ4G/sjmfy7xy3QJFu6/ZAKk6jCpqqTswmPwA1U=; b=Abo0lgJGxZMjvekXPIEG3EkZH3soLg4PkgpyB7qXEy88g7zQo68hJzENmba9+fSM5m iKROsYCYOlhV+0zrfPj4cmGFeCtpa/8wd3bTkaR87gUdknn/qkPpNecQIHOsnr9hT6jt JDINQ9NodejNgMiEyvj8bmeN1pGc9zjQEaJHcPUh87d8Lf55DGKJiMzEDzlWF4N/qZ+F 1lMZndN45MICl2OXMcacjsqTnGqykQxayQo5yEKZAaFAA8diH2oQ1IgxcvfY7V5zqrVn YTnkR59sLlA/T+vbRLkuq1uVZ50IxUdLx1wI3xC7sjKbGmT7NJnHcZZOqaBCpsNXmxTB pIPg== X-Gm-Message-State: AOJu0YxjvVvbNbRLb/zrfyXk9WiD/cR6FxRcOBmdr5/mDvxzgah3/WDt yBUxwdWhvtGPreRKvV/boqe6c0ZXWO0OL0XBcDik2T+L/lS5bUXq9iP6jy+Ol/fiM2NtQWH6DaU AbiNSP1Jifyk+xVTLADfgd5CAEsmoTjc= X-Gm-Gg: ASbGncvuHtBItIXGKJpW3C5xfW/gHo7db0aFmRQZqZuFfUe6s3U3bWvggFvt1e4xw+U ygQfLPL2ZOdUW+aY3jKGlZPgGHhKxHeM0F31thxVK38jqMAXoilsgUptzfEdzU8v7o2Ax8GJk0W CreEpwqPWaUcRaVmBBGR1vJ/1NA0LlGQxzHvHH2TCu76gUE+phokmluw== X-Google-Smtp-Source: AGHT+IFF/YGWB1m+/umcq4JF8HLg71XTKn3p5xOQXnTmPiyyTIZBLllvvDEBczQmzRQoYw9alJGKFXpRKO02gWJS9gU= X-Received: by 2002:a2e:b5b7:0:b0:32c:e253:20c9 with SMTP id 38308e7fff4ca-32ce25338e1mr24420101fa.41.1751275093088; Mon, 30 Jun 2025 02:18:13 -0700 (PDT) MIME-Version: 1.0 References: <20250627062020.534-1-ryncsn@gmail.com> <20250627062020.534-8-ryncsn@gmail.com> In-Reply-To: From: Kairui Song Date: Mon, 30 Jun 2025 17:17:35 +0800 X-Gm-Features: Ac12FXwa2GU5SI346WrZEhyPtXXGdN3bhoV6BISvp1n5zG8SR88LtSe5C1Wrgic Message-ID: Subject: Re: [PATCH v3 7/7] mm/shmem, swap: avoid false positive swap cache lookup To: Baolin Wang Cc: linux-mm@kvack.org, Andrew Morton , Hugh Dickins , Matthew Wilcox , Kemeng Shi , Chris Li , Nhat Pham , Baoquan He , Barry Song , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: F2A672001D X-Stat-Signature: x4ecgozd6fa3kyt8gb15d6trcumqy3ry X-HE-Tag: 1751275094-817120 X-HE-Meta: U2FsdGVkX1/t7mH4dry67JWWfkVtrwmWsP03Uq83TmfDuc9IvFucKjJL7K0xRbpOu1g4Q6wM3h4aOoKJdzUGMcDVbYicGgCUwRZdtnBm1d+mK0w6hBh00oLlsGpg3EVPgcUMbjOWm69K2nQMQ9tJC6beIAHPYO4sJj2MzSWApKXgi5OfHwcPWr7Xn3iBurW92ASdnrYdxmbacOSKJd/4eDlOe2/oMikDEefUQIhrtqNXW+TO1h26VbXwJF1x21eEXWG5tIFyoF0zAXs9TVA21pIFdK3FAuDtWYm0p8sX/59inil/v6CdW1QWgu1eUzFp/F+RQ1iy5SrDOK595O7k/ofo7xP70q5aB68aDASuRjxeFsccEFiH7cRiUpQKiIpwqitmD50QTc0Zq4KhDuDdhW2uJpCfSTrjrngrgMNvfFYLKz/qgYBuKeWA07orepQ4KIC6lzVScYEIIHmU33DP6zoS9eGMYlKvqGSIt056RFGLlbVarqx4MHfg+IgBFofUMIGts6w2fdDkSRPh4YubTQAKmQkcu2Ap9rYwbzsqYBIGJfImrOgJq2FpFRVgVsWFBX4n3q4wD92V/6QouVdlNk7vgUCLjjjvWv0KBlnbUOm/xqP298fWXqCuC1uGDZZ1mEYiJHHvP2LsiVIEfcRpy/A96/qg2ATU5hB/SPPBgWWB3f1C0tfW97XWG2RAbGvTJvnXlKykJKfb6+kRtO0Nslog9zGFzbuUWjcPm1vaUb04cvmj9kMYRC7nsjOEjK4McdXrkrxxFO79tnvHPwwY82uAnDprWcvoWD5m+876py61TLR8lzEKbLq9w7zz44lnaWjUpfP5jr4CjZkBs47zgsQRFglRoUjcfj+/hpTBtLY5E5VQ6R/gt18ufr/w0YyLNz8KxqlGBS0OA889folK396mQ73J+73xTBB36Ih9l5pCpYgnWD4PH0i37t7soAYbcJAK4hZThjYtj4MP4oN ERmmiSkN JfWO5fapCxKMjeWBufuM8jI7Jdo81amJAn6iQMGa7DCiKc9znlj6sG9nJ0v84PrJb5EB3jkIHKj+CFwxl42m3t1A2sDYPPuGeNS8SrWScL+sHT30vW6DNJ6VGWbHkLcqPX4AOej7wUkheXimimGElPkGCPUdml4ar1xS6woPkNZZj8K9UPFZ+YbwOJNF3O0l29hyeBdDbM0qeYTa5n1ZvEetVjuH6nG7UD7NUM4KlclCyGOlhZEr72NEK1qHKEK4lfZmKM9cvbHYyQRHr7txAm4iSkFeteRdXvUzYNiXTEsiANfy/kX8oGWWimUVt8fJmucPBgPAose2XA+OQYyKQv1qrjjMmW45XyIpAACGlan+vx17aSKDwXTL42pl3duRzzuaUOYgp+a2DhiU1HVyxEmeOLw== 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 Mon, Jun 30, 2025 at 3:22=E2=80=AFPM Baolin Wang wrote: > On 2025/6/27 14:20, Kairui Song wrote: > > From: Kairui Song > > > > If the shmem read request's index points to the middle of a large swap > > entry, shmem swap in does the swap cache lookup use the large swap entr= y's > > starting value (the first sub swap entry of this large entry). > > Right. > > This will > > lead to false positive lookup result if only the first few swap entries > > are cached, but the requested swap entry pointed by index is uncached. > > > > Currently shmem will do a large entry split then retry the swapin from > > beginning, which is a waste of CPU and fragile. Handle this correctly. > > Sorry, I did not get you here. Only when the 'order' (get from > shmem_confirm_swap()) is not equal to folio_order(), will it trigger the > large swap entry split. Could you describe the issue in more detail? Right, for example we have a `order =3D 4` swap entry covering `index 0 - 16`, `swap.val =3D 0x4000`. A swapin request starts with `index =3D 3`. The swap_cache_get_folio will be called with `swap.val =3D 0x4000`. It may return an order 0 folio with `swap.val =3D 0x4000` (especially readaheads read order 0 folios easily). It doesn't satisfy the swapin requests. A split is issued and swapin will fall, then the fault is triggered again. After this patch, swap_cache_get_folio will return either NULL or the right folio. > I also found a false positive swap-in in your patch 4, seems they are > related? It's unrelated, I should added this code in this patch for !SWP_SYNCHRONOUS_IO path in that patch: offset =3D index - round_down(index, 1 << order); swap.val =3D index_entry.val + offset; > > > Also add some sanity checks to help understand the code and ensure thin= gs > > won't go wrong. > > > > Signed-off-by: Kairui Song > > --- > > mm/shmem.c | 60 +++++++++++++++++++++++++++++------------------------= - > > 1 file changed, 32 insertions(+), 28 deletions(-) > > > > diff --git a/mm/shmem.c b/mm/shmem.c > > index ea9a105ded5d..9341c51c3d10 100644 > > --- a/mm/shmem.c > > +++ b/mm/shmem.c > > @@ -1977,14 +1977,19 @@ static struct folio *shmem_alloc_and_add_folio(= struct vm_fault *vmf, > > > > static struct folio *shmem_swapin_direct(struct inode *inode, > > struct vm_area_struct *vma, pgoff_t index, > > - swp_entry_t entry, int order, gfp_t gfp) > > + swp_entry_t index_entry, swp_entry_t swap, > > + int order, gfp_t gfp) > > { > > struct shmem_inode_info *info =3D SHMEM_I(inode); > > - int nr_pages =3D 1 << order; > > struct folio *new; > > - pgoff_t offset; > > + swp_entry_t entry; > > gfp_t swap_gfp; > > void *shadow; > > + int nr_pages; > > + > > + /* Prefer aligned THP swapin */ > > + entry.val =3D index_entry.val; > > + nr_pages =3D 1 << order; > > > > /* > > * We have arrived here because our zones are constrained, so don= 't > > @@ -2011,6 +2016,7 @@ static struct folio *shmem_swapin_direct(struct i= node *inode, > > swap_gfp =3D limit_gfp_mask(vma_thp_gfp_mask(vma)= , gfp); > > } > > } > > + > > retry: > > new =3D shmem_alloc_folio(swap_gfp, order, info, index); > > if (!new) { > > @@ -2056,11 +2062,10 @@ static struct folio *shmem_swapin_direct(struct= inode *inode, > > if (!order) > > return new; > > /* High order swapin failed, fallback to order 0 and retry */ > > - order =3D 0; > > - nr_pages =3D 1; > > + entry.val =3D swap.val; > > swap_gfp =3D gfp; > > - offset =3D index - round_down(index, nr_pages); > > - entry =3D swp_entry(swp_type(entry), swp_offset(entry) + offset); > > + nr_pages =3D 1; > > + order =3D 0; > > goto retry; > > } > > > > @@ -2288,20 +2293,21 @@ static int shmem_swapin_folio(struct inode *ino= de, pgoff_t index, > > struct mm_struct *fault_mm =3D vma ? vma->vm_mm : NULL; > > struct shmem_inode_info *info =3D SHMEM_I(inode); > > int error, nr_pages, order, swap_order; > > + swp_entry_t swap, index_entry; > > struct swap_info_struct *si; > > struct folio *folio =3D NULL; > > bool skip_swapcache =3D false; > > - swp_entry_t swap; > > + pgoff_t offset; > > > > VM_BUG_ON(!*foliop || !xa_is_value(*foliop)); > > - swap =3D radix_to_swp_entry(*foliop); > > + index_entry =3D radix_to_swp_entry(*foliop); > > *foliop =3D NULL; > > > > - if (is_poisoned_swp_entry(swap)) > > + if (is_poisoned_swp_entry(index_entry)) > > return -EIO; > > > > - si =3D get_swap_device(swap); > > - order =3D shmem_confirm_swap(mapping, index, swap); > > + si =3D get_swap_device(index_entry); > > + order =3D shmem_confirm_swap(mapping, index, index_entry); > > if (unlikely(!si)) { > > if (order < 0) > > return -EEXIST; > > @@ -2313,13 +2319,15 @@ static int shmem_swapin_folio(struct inode *ino= de, pgoff_t index, > > return -EEXIST; > > } > > > > - /* Look it up and read it in.. */ > > + /* @index may points to the middle of a large entry, get the real= swap value first */ > > + offset =3D index - round_down(index, 1 << order); > > + swap.val =3D index_entry.val + offset; > > folio =3D swap_cache_get_folio(swap, NULL, 0); > > if (!folio) { > > if (data_race(si->flags & SWP_SYNCHRONOUS_IO)) { > > /* Direct mTHP swapin without swap cache or reada= head */ > > folio =3D shmem_swapin_direct(inode, vma, index, > > - swap, order, gfp); > > + index_entry, swap, or= der, gfp); > > if (IS_ERR(folio)) { > > error =3D PTR_ERR(folio); > > folio =3D NULL; > > @@ -2341,28 +2349,25 @@ static int shmem_swapin_folio(struct inode *ino= de, pgoff_t index, > > count_memcg_event_mm(fault_mm, PGMAJFAULT); > > } > > } > > + > > + swap_order =3D folio_order(folio); > > + nr_pages =3D folio_nr_pages(folio); > > + /* The swap-in should cover both @swap and @index */ > > + swap.val =3D round_down(swap.val, nr_pages); > > + VM_WARN_ON_ONCE(swap.val > index_entry.val + offset); > > + VM_WARN_ON_ONCE(swap.val + nr_pages <=3D index_entry.val + offset= ); > > + > > /* > > * We need to split an existing large entry if swapin brought in = a > > * smaller folio due to various of reasons. > > - * > > - * And worth noting there is a special case: if there is a smalle= r > > - * cached folio that covers @swap, but not @index (it only covers > > - * first few sub entries of the large entry, but @index points to > > - * later parts), the swap cache lookup will still see this folio, > > - * And we need to split the large entry here. Later checks will f= ail, > > - * as it can't satisfy the swap requirement, and we will retry > > - * the swapin from beginning. > > */ > > - swap_order =3D folio_order(folio); > > + index =3D round_down(index, nr_pages); > > if (order > swap_order) { > > - error =3D shmem_split_swap_entry(inode, index, swap, gfp)= ; > > + error =3D shmem_split_swap_entry(inode, index, index_entr= y, gfp); > > if (error) > > goto failed_nolock; > > } > > > > - index =3D round_down(index, 1 << swap_order); > > - swap.val =3D round_down(swap.val, 1 << swap_order); > > - > > /* We have to do this with folio locked to prevent races */ > > folio_lock(folio); > > if ((!skip_swapcache && !folio_test_swapcache(folio)) || > > @@ -2375,7 +2380,6 @@ static int shmem_swapin_folio(struct inode *inode= , pgoff_t index, > > goto failed; > > } > > folio_wait_writeback(folio); > > - nr_pages =3D folio_nr_pages(folio); > > > > /* > > * Some architectures may have to restore extra metadata to the > >