Re: [PATCH 0/2] arm64: gcs: Return -EPERM when changes are prevented by locking
From: Bill Roberts
Date: Tue Oct 06 2026 - 11:58:04 EST
On 10/6/26 10:15 AM, Mark Brown wrote:
On Tue, Oct 06, 2026 at 03:40:26PM +0100, Catalin Marinas wrote:Bear in mind that I do have patches out there, for x86 that enable prctl
On Thu, Sep 10, 2026 at 08:00:39PM +0100, Mark Brown wrote:Yes, it's using -EINVAL though it differs in that it's interface for
When we refuse to change the GCS configuraiton due to locking weIIUC, riscv is returning -EINVAL. Should we get an overall consistent
currently return -EBUSY which is an odd choice. The only userspace I
found that relies on this value at present is the kselftest and other
architectures are using the more obvious -EPERM here let's switch.
value? Personally I find -EBUSY quite descriptive but I don't mind
aligning the architectures (before user space starts making use of the
return value).
locking only allows locking a single enable bit in the enabled state
rather than letting you lock unknown bits, or locking things off, so we
need some changes there too. I guess we could also go with -EPERM which
would also distinguish the "I don't understand" from "This is blocked",
but nobody uses that yet.
I was intending to do something soon to pull more of this code out into
some shared place since especially for RISC-V and arm64 where they're
using the prctl() rather than arch_prctl() interface so there's less
reason for things to be duplicated.
for them as well. I looked into doing the lock check in the prctl call path before
it gets dispatched to the arch specific backend, it does require a common interface
into the threads feature bits that each arch would need to, trivially, implement.