Message ID | 20230523004312.1807357-2-pcc@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1819052vqo; Mon, 22 May 2023 18:08:48 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5E/+RV1Hq9hYdQj+uOCw+adSDPWisaLJAlWRoewqGIA+8DJGznwgFgicgKB8PAShY170s/ X-Received: by 2002:a17:903:41c5:b0:1ad:f7d9:1ae2 with SMTP id u5-20020a17090341c500b001adf7d91ae2mr17136748ple.55.1684804128191; Mon, 22 May 2023 18:08:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684804128; cv=none; d=google.com; s=arc-20160816; b=Cgd8+Oectb4XLEsolt88c3HbU4ozxI8HewKLgcSmAknT2S5Jvzlzk5FWh1sPzRRaSN nGMbPKfB8eidHX0pQ4N6n20M0YHbfw38zRZuRvetBjwnysHVy9g7rmbPEfIuwCP+G/4m +IqwI2aKXuickPpH822IJheSUvcEV14g8ZT2lXXNTNus7Ji8LfqRVqnSR0iIPGs82Xok tyIm0iqFLT+MfehskU88udyrFE6D5TU4X1W4/gY+p0F/NX5NlJHiD6mVvL7qEN9FXo4K bhgQK2yc3JRaC+Y/wSgvm7HJG94pgs5W1ehiSyaYKWhDOxvA1h4R5ZueRggD404UtJPF m9VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:from:subject :references:mime-version:message-id:in-reply-to:date:dkim-signature; bh=msTm3oYdeXIT0hSlyDwQQkvc5wY+Q8yhko13bmJatr8=; b=Mmr9pQSmdPV/SwnrUSe/rrAa5iOU/lJcymsz0BN9B/GN4yzuDJRxP8G2y7kSu/liJk XX/O9MetUiE8E20p+lZKep6Z+mzI0zX3CYYmuR/NFGBlHheuHSSL6vwfyb/2tXoPL4bv wN3IFpXjNRKD1kJMPSOjJjXrQbAm2UBAlMCIrFMXOTp/cHBbAxmlN7mzOeodQkGAEHYY jEipHcuHTovGnrxlcg+svS3JSYNabPs0R9M2XQjIK5FXOSz2ghcj106ultiUPfJMfFvB 5tiinVi9kFNfHmRsJLmkw5d5YYBaipDrTEmN7ZJ5M3XJfZJesLcradboS21LqogMfiaE Fvow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=GVCKc+6r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l5-20020a170902f68500b001afada38c64si864774plg.302.2023.05.22.18.08.36; Mon, 22 May 2023 18:08:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=GVCKc+6r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235214AbjEWAv5 (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Mon, 22 May 2023 20:51:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232331AbjEWAvm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 22 May 2023 20:51:42 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71B6E4C3F for <linux-kernel@vger.kernel.org>; Mon, 22 May 2023 17:44:59 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-babb7aaa605so5322208276.3 for <linux-kernel@vger.kernel.org>; Mon, 22 May 2023 17:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684802597; x=1687394597; h=content-transfer-encoding:cc:to:from:subject:references :mime-version:message-id:in-reply-to:date:from:to:cc:subject:date :message-id:reply-to; bh=msTm3oYdeXIT0hSlyDwQQkvc5wY+Q8yhko13bmJatr8=; b=GVCKc+6rFVLitBZRgjiG8Xp6MHuRDVhZtsHNX/VKvhjNUXI2g+oF9FkWUEYw2KzSxD jp4IhTdFiglLXHuJvOecRUNblTjQqoij5ls5a85sMq/WccA2cWXYiEuTGZE2QPc25z1P I8fzTiWeaDqvG0LuwqBGkTuunNP3dF5yHaQZQWU03AGRfLddIWVSlV0GDW2IfHKUwGIa kJWuZ1I6IkldXrYkOwPS0n6CmraBvOXwhnVIajQXxhcVGPXShTLQ3KiXtaS4Kg9Pbdet qc17JRlFojhHHmnUA1aiDUv9PQDzUO/0c5Sa9DD8d5/h5mOmX7eaqslAsS0IaFcRV2+j ohtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684802597; x=1687394597; h=content-transfer-encoding:cc:to:from:subject:references :mime-version:message-id:in-reply-to:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=msTm3oYdeXIT0hSlyDwQQkvc5wY+Q8yhko13bmJatr8=; b=QIb8BqVmpvSIr7HnVXogYInd6JS3on4Oeoi0x3fMuBOJNG6pWo3xmj0xcuTy4TBlKT pLoohja6XEYuVcHzL5CGysbgqm6iy0vKZ7jeUFfUC3/u+M0szgwhVTJM47rP4MckNlbh MI+IYM1SsgsXlMt4HuDA3La0dh33hr0iBr3ofdwKpkm8u/+O9Kb2fKO1Gw4daBhP2i2F VPKpgbDFkVpWR9oByWM0FQi3oTWtYtBDjeyehSYqG32OqxZmcYKhlBmaNylngrMaPkHp nlqx4OhbeFqOWnk26YNBCWNka73mOxPqErCo1gKP7gxrfyXRfFw3HwWtRwryxA5L8Q2T aQvg== X-Gm-Message-State: AC+VfDyYU1+IIGipQf+kyhS2/1ayvuNknJrxZw6afo6kNs4lzWlyPRwE 6E+xfJQmj61VVMcFvCmbPvesywY= X-Received: from pcc-desktop.svl.corp.google.com ([2620:15c:2d3:205:3d33:90fe:6f02:afdd]) (user=pcc job=sendgmr) by 2002:a25:10d4:0:b0:ba8:181b:2558 with SMTP id 203-20020a2510d4000000b00ba8181b2558mr7332911ybq.4.1684802597761; Mon, 22 May 2023 17:43:17 -0700 (PDT) Date: Mon, 22 May 2023 17:43:08 -0700 In-Reply-To: <20230523004312.1807357-1-pcc@google.com> Message-Id: <20230523004312.1807357-2-pcc@google.com> Mime-Version: 1.0 References: <20230523004312.1807357-1-pcc@google.com> X-Mailer: git-send-email 2.40.1.698.g37aff9b760-goog Subject: [PATCH v4 1/3] mm: Call arch_swap_restore() from do_swap_page() From: Peter Collingbourne <pcc@google.com> To: Catalin Marinas <catalin.marinas@arm.com> Cc: Peter Collingbourne <pcc@google.com>, " =?utf-8?b?UXVuLXdlaSBMaW4gKA==?= =?utf-8?b?5p6X576k5bS0KQ==?= " <Qun-wei.Lin@mediatek.com>, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "surenb@google.com" <surenb@google.com>, "david@redhat.com" <david@redhat.com>, " =?utf-8?b?Q2hpbndlbiBDaGFuZyAo5by1?= =?utf-8?b?6Yym5paHKQ==?= " <chinwen.chang@mediatek.com>, "kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>, " =?utf-8?b?S3Vh?= =?utf-8?b?bi1ZaW5nIExlZSAo5p2O5Yag56mOKQ==?= " <Kuan-Ying.Lee@mediatek.com>, " =?utf-8?b?Q2FzcGVyIExpICjmnY7kuK3mpq4p?= " <casper.li@mediatek.com>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, vincenzo.frascino@arm.com, Alexandru Elisei <alexandru.elisei@arm.com>, will@kernel.org, eugenis@google.com, Steven Price <steven.price@arm.com>, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766645173076292830?= X-GMAIL-MSGID: =?utf-8?q?1766645173076292830?= |
Series |
mm: Fix bug affecting swapping in MTE tagged pages
|
|
Commit Message
Peter Collingbourne
May 23, 2023, 12:43 a.m. UTC
Commit c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") moved the call to swap_free() before the call to set_pte_at(), which meant that the MTE tags could end up being freed before set_pte_at() had a chance to restore them. Fix it by adding a call to the arch_swap_restore() hook before the call to swap_free(). Signed-off-by: Peter Collingbourne <pcc@google.com> Link: https://linux-review.googlesource.com/id/I6470efa669e8bd2f841049b8c61020c510678965 Cc: <stable@vger.kernel.org> # 6.1 Fixes: c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") Reported-by: Qun-wei Lin (林群崴) <Qun-wei.Lin@mediatek.com> Closes: https://lore.kernel.org/all/5050805753ac469e8d727c797c2218a9d780d434.camel@mediatek.com/ Acked-by: David Hildenbrand <david@redhat.com> Acked-by: "Huang, Ying" <ying.huang@intel.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> --- v2: - Call arch_swap_restore() directly instead of via arch_do_swap_page() mm/memory.c | 7 +++++++ 1 file changed, 7 insertions(+)
Comments
Hi Peter, On Mon, May 22, 2023 at 05:43:08PM -0700, Peter Collingbourne wrote: > Commit c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") moved > the call to swap_free() before the call to set_pte_at(), which meant that > the MTE tags could end up being freed before set_pte_at() had a chance > to restore them. Fix it by adding a call to the arch_swap_restore() hook > before the call to swap_free(). > > Signed-off-by: Peter Collingbourne <pcc@google.com> > Link: https://linux-review.googlesource.com/id/I6470efa669e8bd2f841049b8c61020c510678965 > Cc: <stable@vger.kernel.org> # 6.1 > Fixes: c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") > Reported-by: Qun-wei Lin (林群崴) <Qun-wei.Lin@mediatek.com> > Closes: https://lore.kernel.org/all/5050805753ac469e8d727c797c2218a9d780d434.camel@mediatek.com/ > Acked-by: David Hildenbrand <david@redhat.com> > Acked-by: "Huang, Ying" <ying.huang@intel.com> > Reviewed-by: Steven Price <steven.price@arm.com> > Acked-by: Catalin Marinas <catalin.marinas@arm.com> > --- > v2: > - Call arch_swap_restore() directly instead of via arch_do_swap_page() > > mm/memory.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/mm/memory.c b/mm/memory.c > index f69fbc251198..fc25764016b3 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -3932,6 +3932,13 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > } > } > > + /* > + * Some architectures may have to restore extra metadata to the page > + * when reading from swap. This metadata may be indexed by swap entry > + * so this must be called before swap_free(). > + */ > + arch_swap_restore(entry, folio); > + > /* > * Remove the swap entry and conditionally try to free up the swapcache. > * We're already holding a reference on the page but haven't mapped it It looks like the intention is for this patch to land in 6.4, whereas the other two in the series could go in later, right? If so, I was expecting Andrew to pick this one up but he's not actually on CC. I've added him now, but you may want to send this as a separate fix so it's obvious what needs picking up for this cycle. Cheers, Will
On Mon, Jun 5, 2023 at 7:06 AM Will Deacon <will@kernel.org> wrote: > > Hi Peter, > > On Mon, May 22, 2023 at 05:43:08PM -0700, Peter Collingbourne wrote: > > Commit c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") moved > > the call to swap_free() before the call to set_pte_at(), which meant that > > the MTE tags could end up being freed before set_pte_at() had a chance > > to restore them. Fix it by adding a call to the arch_swap_restore() hook > > before the call to swap_free(). > > > > Signed-off-by: Peter Collingbourne <pcc@google.com> > > Link: https://linux-review.googlesource.com/id/I6470efa669e8bd2f841049b8c61020c510678965 > > Cc: <stable@vger.kernel.org> # 6.1 > > Fixes: c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") > > Reported-by: Qun-wei Lin (林群崴) <Qun-wei.Lin@mediatek.com> > > Closes: https://lore.kernel.org/all/5050805753ac469e8d727c797c2218a9d780d434.camel@mediatek.com/ > > Acked-by: David Hildenbrand <david@redhat.com> > > Acked-by: "Huang, Ying" <ying.huang@intel.com> > > Reviewed-by: Steven Price <steven.price@arm.com> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com> > > --- > > v2: > > - Call arch_swap_restore() directly instead of via arch_do_swap_page() > > > > mm/memory.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index f69fbc251198..fc25764016b3 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -3932,6 +3932,13 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > } > > } > > > > + /* > > + * Some architectures may have to restore extra metadata to the page > > + * when reading from swap. This metadata may be indexed by swap entry > > + * so this must be called before swap_free(). > > + */ > > + arch_swap_restore(entry, folio); > > + > > /* > > * Remove the swap entry and conditionally try to free up the swapcache. > > * We're already holding a reference on the page but haven't mapped it > > It looks like the intention is for this patch to land in 6.4, whereas the > other two in the series could go in later, right? If so, I was expecting > Andrew to pick this one up but he's not actually on CC. I've added him now, > but you may want to send this as a separate fix so it's obvious what needs > picking up for this cycle. I was expecting that this whole series could be picked up in mm. There was a previous attempt to apply v3 of this series to mm, but that failed because a dependent patch (commit c4c597f1b367 ("arm64: mte: Do not set PG_mte_tagged if tags were not initialized")) hadn't been merged into Linus's master branch yet. The series should be good to go in now that that patch has been merged. Peter
On Mon, Jun 05, 2023 at 10:41:12AM -0700, Peter Collingbourne wrote: > On Mon, Jun 5, 2023 at 7:06 AM Will Deacon <will@kernel.org> wrote: > > On Mon, May 22, 2023 at 05:43:08PM -0700, Peter Collingbourne wrote: > > > Commit c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") moved > > > the call to swap_free() before the call to set_pte_at(), which meant that > > > the MTE tags could end up being freed before set_pte_at() had a chance > > > to restore them. Fix it by adding a call to the arch_swap_restore() hook > > > before the call to swap_free(). > > > > > > Signed-off-by: Peter Collingbourne <pcc@google.com> > > > Link: https://linux-review.googlesource.com/id/I6470efa669e8bd2f841049b8c61020c510678965 > > > Cc: <stable@vger.kernel.org> # 6.1 > > > Fixes: c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") > > > Reported-by: Qun-wei Lin (林群崴) <Qun-wei.Lin@mediatek.com> > > > Closes: https://lore.kernel.org/all/5050805753ac469e8d727c797c2218a9d780d434.camel@mediatek.com/ > > > Acked-by: David Hildenbrand <david@redhat.com> > > > Acked-by: "Huang, Ying" <ying.huang@intel.com> > > > Reviewed-by: Steven Price <steven.price@arm.com> > > > Acked-by: Catalin Marinas <catalin.marinas@arm.com> > > > --- > > > v2: > > > - Call arch_swap_restore() directly instead of via arch_do_swap_page() > > > > > > mm/memory.c | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/mm/memory.c b/mm/memory.c > > > index f69fbc251198..fc25764016b3 100644 > > > --- a/mm/memory.c > > > +++ b/mm/memory.c > > > @@ -3932,6 +3932,13 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > > } > > > } > > > > > > + /* > > > + * Some architectures may have to restore extra metadata to the page > > > + * when reading from swap. This metadata may be indexed by swap entry > > > + * so this must be called before swap_free(). > > > + */ > > > + arch_swap_restore(entry, folio); > > > + > > > /* > > > * Remove the swap entry and conditionally try to free up the swapcache. > > > * We're already holding a reference on the page but haven't mapped it > > > > It looks like the intention is for this patch to land in 6.4, whereas the > > other two in the series could go in later, right? If so, I was expecting > > Andrew to pick this one up but he's not actually on CC. I've added him now, > > but you may want to send this as a separate fix so it's obvious what needs > > picking up for this cycle. > > I was expecting that this whole series could be picked up in mm. There > was a previous attempt to apply v3 of this series to mm, but that > failed because a dependent patch (commit c4c597f1b367 ("arm64: mte: Do > not set PG_mte_tagged if tags were not initialized")) hadn't been > merged into Linus's master branch yet. The series should be good to go > in now that that patch has been merged. Did this series fall through the cracks? I can't see it in linux-next (or maybe my grep'ing failed). The commit mentioned above is in 6.4-rc3 AFAICT. Unfortunately Andrew was not cc'ed on the initial post, Will added him later, so he likely missed it. For reference, the series is here: https://lore.kernel.org/r/20230523004312.1807357-1-pcc@google.com/ Andrew, what's your preference for this series? I'd like at least the first patch to go into 6.5 as a fix. The second patch seems to be fairly low risk and I'm happy for the third arm64 patch/cleanup to go in 6.5-rc1 (but it depends on the second patch). If you prefer, I can pick them up and send a pull request to Linus next week before -rc1. Otherwise you (or I) can queue the first patch and leave the other two for 6.6. Thanks.
On Thu, 29 Jun 2023 10:57:14 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote: > Andrew, what's your preference for this series? I'd like at least the > first patch to go into 6.5 as a fix. The second patch seems to be fairly > low risk and I'm happy for the third arm64 patch/cleanup to go in > 6.5-rc1 (but it depends on the second patch). If you prefer, I can pick > them up and send a pull request to Linus next week before -rc1. > Otherwise you (or I) can queue the first patch and leave the other two > for 6.6. Thanks. I queued [1/3] for 6.5-rcX with a cc:stable. And I queued [2/3] and [3/3] for 6.6-rc1. If you wish to grab any/all of these then please do so - Stephen will tell us of the duplicate and I'll drop the mm-git copy.
On Sun, Jul 02, 2023 at 12:38:21PM -0700, Andrew Morton wrote: > On Thu, 29 Jun 2023 10:57:14 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote: > > Andrew, what's your preference for this series? I'd like at least the > > first patch to go into 6.5 as a fix. The second patch seems to be fairly > > low risk and I'm happy for the third arm64 patch/cleanup to go in > > 6.5-rc1 (but it depends on the second patch). If you prefer, I can pick > > them up and send a pull request to Linus next week before -rc1. > > Otherwise you (or I) can queue the first patch and leave the other two > > for 6.6. > > Thanks. I queued [1/3] for 6.5-rcX with a cc:stable. And I queued > [2/3] and [3/3] for 6.6-rc1. > > If you wish to grab any/all of these then please do so - Stephen > will tell us of the duplicate and I'll drop the mm-git copy. That's great, thanks. We'll let you know if there are any conflicts during the 6.6 preparation.
diff --git a/mm/memory.c b/mm/memory.c index f69fbc251198..fc25764016b3 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3932,6 +3932,13 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) } } + /* + * Some architectures may have to restore extra metadata to the page + * when reading from swap. This metadata may be indexed by swap entry + * so this must be called before swap_free(). + */ + arch_swap_restore(entry, folio); + /* * Remove the swap entry and conditionally try to free up the swapcache. * We're already holding a reference on the page but haven't mapped it