Message ID | 20230607-arm64-flush-svcr-v1-1-7821a6199e0a@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp492518vqr; Wed, 7 Jun 2023 14:28:55 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ68qsJ27aaebYdVG1DvqegrxXp5d7MJcxmhKbFedxvYimlwRQcgpsHQfM8CoVXkqQZuUuKX X-Received: by 2002:a17:902:ecc2:b0:1b0:42d1:ecd0 with SMTP id a2-20020a170902ecc200b001b042d1ecd0mr8181628plh.66.1686173334867; Wed, 07 Jun 2023 14:28:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686173334; cv=none; d=google.com; s=arc-20160816; b=VUySRUWzJ/JhYQ6f35Sm8VMhTp1MSMY1jGrn1ZY1ouhH9GNU0abjD8OhjOhyjtgs8A eshxC7MdLIzd8UNhLp8ODMCYb16WzvDo/uxbTXUmGjzKPe7Xhrg2wrVLWyGn0Vt2qshX limaQMO82fgqC4KT2WDBrnTwUd8DOPAiV1CFYZgp9GG8bikoZFxV2pl2fFEWBe8+3ps/ moEgAp4Cu7wsrKSt7o6sefjGBd06Aa2iiwpzbPZFZGG6fgJR/GQbHi2vFKM91u5RgN4X loQ6K0t7YddVKg4h3ZQtm9e+ez9Rs4cV2Di1ygc3Go9yXGJXqHsTQFn5MrdUDpakU+dT rsQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=ncX0DwVT21OoXBwzqQtziAJ7gKpxWwo8IK3YlNuKakY=; b=K/ssJq7RYRlV+aPL3AmWfK1DFomxXhxdpOA2jyoScdyboITZh8g+wpO2/7YN+Nital 4d4QecywEEKqqXx20GCfNlPkDQQdehPjPJ8ZmfhrAH5YI4jRGnLCpDjXuCzJMAj3u9f2 FdlF2bViF9eE16L2U0d77r5P22zPJIVHMlI49e5yz5Zr4rxEAv/h4B9UZN91ZyJMJrYg Tirlzg4EAi6UYFDb+QIdthsNAjJd6huWP+1hFRQSN88bsVmCdkBFTAnJCMaM92fVOvvc ngrkaWh4nsef1mZV02790c1KMangoQjnrXqLYU3q3tHAu9ek/iNm1STQWltxrCnD0VFA 7Pmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NOTgZAD9; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n18-20020a170902d2d200b0019f33cb669asi9749296plc.615.2023.06.07.14.28.36; Wed, 07 Jun 2023 14:28:54 -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=@kernel.org header.s=k20201202 header.b=NOTgZAD9; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234536AbjFGUnE (ORCPT <rfc822;literming00@gmail.com> + 99 others); Wed, 7 Jun 2023 16:43:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234475AbjFGUm6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 7 Jun 2023 16:42:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5BB9D2113 for <linux-kernel@vger.kernel.org>; Wed, 7 Jun 2023 13:42:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 284816463E for <linux-kernel@vger.kernel.org>; Wed, 7 Jun 2023 20:42:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D39AC433EF; Wed, 7 Jun 2023 20:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686170550; bh=5aQZkv7b76uNRIEEdQU8uQNP36af9VapveubHqYUaFQ=; h=From:Date:Subject:To:Cc:From; b=NOTgZAD9znY+E34eMdNxRrYZ9WFsjp1bDtbNZVPoEftzkVH/LzVi1T42kRaawir7c NKA/2AjGOyWhxbmJzrbHGjdA7pSvm7+lfpg16pLt9bsfH4AZkHLwo5+8JqlFNyuJRh 7HAjjVnt3E4qFM034doh6Aq/Qy6uqlO20o3YNdW2Q4qpoQj1twc3ZaivgDDRxB8WMW +JguAl1+rO+7mT7HLUowSatyk5ow8CegDMLYVnOnQNRGZZK8Fay5SM+68iaSYZhQHf MywLNQWEq6NYWrVPwT0VW65dcA5Z7zjIACREG6zVEGXlqw1NGRSoE2aaou8xtKX+tr AKotEd4N2Mqvg== From: Mark Brown <broonie@kernel.org> Date: Wed, 07 Jun 2023 21:30:51 +0100 Subject: [PATCH] arm64/fpsimd: Exit streaming mode when flushing tasks MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230607-arm64-flush-svcr-v1-1-7821a6199e0a@kernel.org> X-B4-Tracking: v=1; b=H4sIAPvogGQC/x2N0QrCMAwAf2Xk2UCdoxV/RXxIY2aD2kmCUxj7d zsf7+C4BVxMxeHULWAyq+tUG+x3HXChehPUa2PoQ38IMSQke8YBx8fbC/rMhkNiTpGOnDNDyzK 5YDaqXLbwM9l90y+TUb//0/myrj82jPm5eQAAAA== To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Anders Roxell <anders.roxell@linaro.org>, Naresh Kamboju <naresh.kamboju@linaro.org>, Mark Brown <broonie@kernel.org> X-Mailer: b4 0.13-dev-bfdf5 X-Developer-Signature: v=1; a=openpgp-sha256; l=1038; i=broonie@kernel.org; h=from:subject:message-id; bh=5aQZkv7b76uNRIEEdQU8uQNP36af9VapveubHqYUaFQ=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBkgOu0OWZtXqQLnmaga8qWcEKH43zY/MuFSc6R2FTB QHARcI6JATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZIDrtAAKCRAk1otyXVSH0F81B/ 0RF7RycQjSNI9WUnqO2R7nmzQwDLgtpGzQr5kXvGiRcOELDrerPK8ajLa+QDvaqgla82fv5d5Khccm b9iZhy0q9RE35vZlqXELzI1IQ1PVvL60gNaE42C3AXZndnQdoWxUN9PNoilPLdDP+W6tmE2tlxFgfy SW5+K61o5rJr8RlwuuOBIRGZb4BKWr0h0WEDOgml9yRh+q/jUaBQrW8iUa+e9OFqJKFdsQG6+GuUGi DFygUmJwPf08bJpxFYhKhMAAhEJHyeoK2+K8o+OOUpX1NjwbLBs/lU3QVZbpCxm7TmyOjIMh7JKUkX nvYQXSb30SRsVSaphjQPmpBN0BcDch X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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?1768080890707424497?= X-GMAIL-MSGID: =?utf-8?q?1768080890707424497?= |
Series |
arm64/fpsimd: Exit streaming mode when flushing tasks
|
|
Commit Message
Mark Brown
June 7, 2023, 8:30 p.m. UTC
Ensure there is no path where we might attempt to save SME state after we
flush a task by updating the SVCR register state as well as updating our
in memory state. I haven't seen a specific case where this is happening or
seen a path where it might happen but for the cost of a single low overhead
instruction it seems sensible to close the potential gap.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/kernel/fpsimd.c | 1 +
1 file changed, 1 insertion(+)
---
base-commit: 44c026a73be8038f03dbdeef028b642880cf1511
change-id: 20230607-arm64-flush-svcr-47cc76a8cbbc
Best regards,
Comments
On Wed, 7 Jun 2023 at 22:42, Mark Brown <broonie@kernel.org> wrote: > > Ensure there is no path where we might attempt to save SME state after we > flush a task by updating the SVCR register state as well as updating our > in memory state. I haven't seen a specific case where this is happening or > seen a path where it might happen but for the cost of a single low overhead > instruction it seems sensible to close the potential gap. > > Signed-off-by: Mark Brown <broonie@kernel.org> Applied this onto todays next tag next-20230608 and ran kselftest-arm64 on a FVP model. I still see the "BUG: KFENCE: memory corruption in fpsimd_release_task+0x1c/0x3c". I'm trying to use the latest kselftest from today with older next tags trying to find when this issue started to happen. Cheers, Anders > --- > arch/arm64/kernel/fpsimd.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index 2fbafa5cc7ac..1627e0efe39a 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -1649,6 +1649,7 @@ void fpsimd_flush_thread(void) > > fpsimd_flush_thread_vl(ARM64_VEC_SME); > current->thread.svcr = 0; > + sme_smstop_sm(); > } > > current->thread.fp_type = FP_STATE_FPSIMD; > > --- > base-commit: 44c026a73be8038f03dbdeef028b642880cf1511 > change-id: 20230607-arm64-flush-svcr-47cc76a8cbbc > > Best regards, > -- > Mark Brown <broonie@kernel.org> >
On Wed, Jun 07, 2023 at 09:30:51PM +0100, Mark Brown wrote: > Ensure there is no path where we might attempt to save SME state after we > flush a task by updating the SVCR register state as well as updating our > in memory state. I haven't seen a specific case where this is happening or > seen a path where it might happen but for the cost of a single low overhead > instruction it seems sensible to close the potential gap. > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > arch/arm64/kernel/fpsimd.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index 2fbafa5cc7ac..1627e0efe39a 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -1649,6 +1649,7 @@ void fpsimd_flush_thread(void) > > fpsimd_flush_thread_vl(ARM64_VEC_SME); > current->thread.svcr = 0; > + sme_smstop_sm(); I don't think we should blindly do this if we never expect to get here in that state; this is just going to mask bugs and make them harder to debug going forwards. If we need this, it'd be better to have something like: if (WARN_ON_ONCE(sme_is_in_streaming_mode())) sme_smstop_sm(); ... so that we can identify this case and fix it. Thanks, Mark.
On Thu, Jun 08, 2023 at 04:51:26PM +0100, Mark Rutland wrote: > On Wed, Jun 07, 2023 at 09:30:51PM +0100, Mark Brown wrote: > > fpsimd_flush_thread_vl(ARM64_VEC_SME); > > current->thread.svcr = 0; > > + sme_smstop_sm(); > I don't think we should blindly do this if we never expect to get here in that > state; this is just going to mask bugs and make them harder to debug going > forwards. > If we need this, it'd be better to have something like: > if (WARN_ON_ONCE(sme_is_in_streaming_mode())) > sme_smstop_sm(); > ... so that we can identify this case and fix it. No, being here in streaming mode is valid so that check would be wrong - if there is an issue the issue would be that we're expecting that any further use of the register state would involve reloading from memory but there would be some path where we end up doing something that uses the in register state again rather than reloading. The change ensures that the saved and register states are in sync so that can't go wrong, meaning we don't need to go confirm if there's such a path. Though now I look again we should do a full SMSTOP since a similar concern applies to ZA.
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 2fbafa5cc7ac..1627e0efe39a 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -1649,6 +1649,7 @@ void fpsimd_flush_thread(void) fpsimd_flush_thread_vl(ARM64_VEC_SME); current->thread.svcr = 0; + sme_smstop_sm(); } current->thread.fp_type = FP_STATE_FPSIMD;