[PATCH 0/2] arm64: gcs: Return -EPERM when changes are prevented by locking

[Bill Roberts]

On 10/6/26 10:15 AM, Mark Brown wrote:
> On Tue, Oct 06, 2026 at 03:40:26PM +0100, Catalin Marinas wrote:
>> On Thu, Sep 10, 2026 at 08:00:39PM +0100, Mark Brown wrote:
>>> When we refuse to change the GCS configuraiton due to locking we
>>> 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.
>> IIUC, riscv is returning -EINVAL. Should we get an overall consistent
>> 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).
> Yes, it's using -EINVAL though it differs in that it's interface for
> 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.
Bear in mind that I do have patches out there, for x86 that enable prctl
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.