[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <991d84b4-e184-4fd6-900f-601f8c31d518@sirena.org.uk>
Date: Tue, 23 Jan 2024 17:31:58 +0000
From: Mark Brown <broonie@...nel.org>
To: Dave Martin <Dave.Martin@....com>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Jonathan Corbet <corbet@....net>,
linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
Edmund Grimley-Evans <edmund.grimley-evans@....com>
Subject: Re: [PATCH 1/4] arm64/sve: Remove bitrotted comment about syscall
behaviour
On Tue, Jan 23, 2024 at 03:44:23PM +0000, Dave Martin wrote:
> On Mon, Jan 22, 2024 at 08:41:51PM +0000, Mark Brown wrote:
> > When we documented that we always clear state not shared with FPSIMD we
> Where / when?
In the document that is being modified when it was written.
> > -* In practice the affected registers/bits will be preserved or will be replaced
> > - with zeros on return from a syscall, but userspace should not make
> > - assumptions about this. The kernel behaviour may vary on a case-by-case
> > - basis.
> This was originally an intentionally conservative statement, to allow
> the kernel the flexibility to relax the register zeroing behaviour in
> the future. It would have permitted not always disabling a task's SVE
> across a syscall, for example. There were some concerns about security
> and testability that meant that we didn't use this flexibility to begin
> with.
> If we are making an irrevocable commitment not to use this flexibility
> ever, then this comment can go, but if we're not totally sure then I
> think it would be harmless to keep it (?)
I think everyone except for Catalin had felt that the original
discussion had concluded that there was a commitment to always clear the
non-shared bits and was disappointed to learn that the documentation
said otherwise. When I tried to take advantage of this as part of
optimising the system call overhead for SVE there were eventually
complaints.
> (Feel free to point me to the relevant past discussion that I may have
> missed.)
See the discussion on my syscall optimisation series:
https://lore.kernel.org/all/20220620124158.482039-8-broonie@kernel.org/
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists