Re: [PATCH v6 06/37] kselftest/arm64: Add a test program to exercise the syscall ABI

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3319 bytes --]

On Fri, Dec 10, 2021 at 10:18:44AM +0000, Catalin Marinas wrote:
> On Thu, Dec 09, 2021 at 07:13:00PM +0000, Mark Brown wrote:
> > On Thu, Dec 09, 2021 at 05:05:41PM +0000, Catalin Marinas wrote:

> > > Nitpick: I think GPL-2.0 is sufficient (i.e. no '-only' suffix), though
> > > about a quarter seem to use the -only variant.

> > Yeah, it's that because it's the default for kernel stuff.  Easier to
> > make it restrictive and then relax later?

> My point was that IIUC GPL-2.0 is equivalent to GPL-2.0-only (not to be
> confused with GPL-2.0+). Anyway, it's fine by me to keep the -only if
> you want. It seems that we have nearly the same amount of both
> throughout the kernel.

Ah, I see - I think the thing with -only is to avoid any ambiguity and
confusion about what's meant.  I'll leave it as is.

> > > A downside with forcing zero is that it may prevent us from some
> > > optimisations in the future. Currently we do an sve_user_discard() on
> > > the syscall entry path and disable SVE but we could instead do this only
> > > on context switch or when the kernel used Neon.

> > Yes, this is limiting our options for performance work since we need to
> > at least take the cost of zeroing the non-shared state on every syscall,
> > though there's still options for choosing not to disable SVE all the
> > time (I've got a patch already I need to do a bit more work on). 

> Some people seem to be pretty sensitive to the syscall latency, so I'd
> like to keep the option to optimise this path if it bites us.

If that's what we decide then we should probably just go ahead and start
taking advantage of it, we do have hardware rolling out imminently so
people will benefit and the sooner we start doing this the less chance
there is that it'll end up an ABI implicitly.

> > The
> > currently documented behaviour is in line with AAPCS here so you do have
> > to wonder how likely it is that someone will rely on the zeroing.  On
> > the other hand anything like only zeroing the state on context switch
> > would mean that it's more likely that userspace bugs with something
> > forgetting that the state might be cleared will be intermittent and most
> > likely hard to reproduce which will make people miserable.  There's a
> > good chance that bugs will be wrong answers rather than something more
> > immediate like a fault which really doesn't help there.

> If we eventually optimise this path, we could add an option to
> force-zero the SVE regs on syscall for debugging purposes. But even
> without this, such software may run into problems. By AAPCS, if the
> callee doesn't take any SVE arguments, it doesn't need to preserve any
> of the registers, though it may choose to. Let's take a gettimeofday
> libc call, it may or may not end up in the kernel. When it's handled by
> the vDSO, all the SVE regs are preserved but not when doing the syscall.
> Something like a futex call would be even less predictable.

Not just that but also the fact that most syscalls go through a library
of some kind which could quite happily use some floating point register
for something before or after performing the actual syscall.  Like I
said above I'm not personally convinced that risks are practical ones
and there's fairly clear benefits.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]