From: Will Deacon <will@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Shuah Khan <shuah@kernel.org>,
David Spickett <David.Spickett@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 1/3] arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes
Date: Thu, 20 Jul 2023 11:52:36 +0100 [thread overview]
Message-ID: <20230720105235.GD11034@willie-the-truck> (raw)
In-Reply-To: <20230713-arm64-fix-sve-sme-vl-change-v1-1-129dd8611413@kernel.org>
On Thu, Jul 13, 2023 at 09:06:04PM +0100, Mark Brown wrote:
> When we reconfigure the SVE vector length we discard the backing storage
> for the SVE vectors and then reallocate on next SVE use, leaving the SME
> specific state alone. This means that we do not enable SME traps if they
> were already disabled. That means that userspace code can enter streaming
> mode without trapping, putting the task in a state where if we try to save
> the state of the task we will fault.
>
> Since the ABI does not specify that changing the SVE vector length disturbs
> SME state, and since SVE code may not be aware of SME code in the process,
> we shouldn't simply discard any ZA state. Instead immediately reallocate
> the storage for SVE if SME is active, and disable SME if we change the SVE
> vector length while there is no SME state active.
What is the advantage of keep the old behaviour in this case? In other
words, if it's acceptable to reallocate the state when SME is active, why
not just reallocate in all cases?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-07-20 10:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 20:06 [PATCH 0/3] arm64/fpsimd: Fix use after free in SME when changing SVE VL Mark Brown
2023-07-13 20:06 ` [PATCH 1/3] arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes Mark Brown
2023-07-17 11:19 ` David Spickett
2023-07-20 10:52 ` Will Deacon [this message]
2023-07-20 12:27 ` Mark Brown
2023-07-13 20:06 ` [PATCH 2/3] kselftest/arm64: Add a test case for SVE VL changes with SME active Mark Brown
2023-07-13 20:06 ` [PATCH 3/3] kselftest/arm64: Validate that changing one VL type does not affect another Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230720105235.GD11034@willie-the-truck \
--to=will@kernel.org \
--cc=David.Spickett@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox