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.