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.