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

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

[Mark Brown]

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.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
Mark Brown (2):
      arm64: gcs: Return -EPERM not -EBUSY for prctl() locking failures
      kselftest/arm64: Check for -EPERM not -EBUSY in the locking test

 arch/arm64/include/asm/gcs.h                    | 2 +-
 tools/testing/selftests/arm64/gcs/gcs-locking.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
---
base-commit: df2908090cda368b01ff43709f51890076c56157
change-id: 20260910-arm64-gcs-lock-eperm-06ce8f8e5250

Best regards,
--  
Mark Brown <broonie@kernel.org>

[PATCH 1/2] arm64: gcs: Return -EPERM not -EBUSY for prctl() locking failures

[Mark Brown]

When we refuse to perform a GCS configuration change due to locking we
currently return -EBUSY which is an odd error code to return.  While the
selftest does currently check for this it is unlikely that we have any
practical users relying on the behaviour at this point so let's change
to return the more descriptive -EPERM instead like other architectures.

Reported-by: Bill Roberts <bill.roberts@foss.arm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/gcs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/gcs.h b/arch/arm64/include/asm/gcs.h
index 8fa0707069e8..bbc22e382cfe 100644
--- a/arch/arm64/include/asm/gcs.h
+++ b/arch/arm64/include/asm/gcs.h
@@ -76,7 +76,7 @@ static inline int gcs_check_locked(struct task_struct *task,
 	new_val &= task->thread.gcs_el0_locked;
 
 	if (cur_val != new_val)
-		return -EBUSY;
+		return -EPERM;
 
 	return 0;
 }

-- 
2.47.3

[PATCH 2/2] kselftest/arm64: Check for -EPERM not -EBUSY in the locking test

[Mark Brown]

The API has been updated to return the more permissive -EPERM rather
than -EBUSY, update the selftest to reflect this.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 tools/testing/selftests/arm64/gcs/gcs-locking.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/arm64/gcs/gcs-locking.c b/tools/testing/selftests/arm64/gcs/gcs-locking.c
index 1e6abb136ffd..f780f0c7b8dd 100644
--- a/tools/testing/selftests/arm64/gcs/gcs-locking.c
+++ b/tools/testing/selftests/arm64/gcs/gcs-locking.c
@@ -115,7 +115,7 @@ TEST_F(valid_modes, enable_lock_disable)
 	ASSERT_EQ(ret, 0);
 
 	ret = my_syscall2(__NR_prctl, PR_SET_SHADOW_STACK_STATUS, 0);
-	ASSERT_EQ(ret, -EBUSY);
+	ASSERT_EQ(ret, -EPERM);
 
 	_exit(0);
 }
@@ -131,7 +131,7 @@ TEST_F(valid_modes, lock_enable)
 
 	ret = my_syscall2(__NR_prctl, PR_SET_SHADOW_STACK_STATUS,
 			  variant->mode);
-	ASSERT_EQ(ret, -EBUSY);
+	ASSERT_EQ(ret, -EPERM);
 
 	ret = prctl(PR_GET_SHADOW_STACK_STATUS, &mode, 0, 0, 0);
 	ASSERT_EQ(ret, 0);

-- 
2.47.3

Re: [PATCH 2/2] kselftest/arm64: Check for -EPERM not -EBUSY in the locking test

[Catalin Marinas]

On Thu, Sep 10, 2026 at 08:00:41PM +0100, Mark Brown wrote:
> The API has been updated to return the more permissive -EPERM rather
					      ^^^^^^^^^^
"descriptive" like in the first patch?

-- 
Catalin

Re: [PATCH 2/2] kselftest/arm64: Check for -EPERM not -EBUSY in the locking test

[Mark Brown]

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

On Tue, Oct 06, 2026 at 03:42:14PM +0100, Catalin Marinas wrote:
> On Thu, Sep 10, 2026 at 08:00:41PM +0100, Mark Brown wrote:
> > The API has been updated to return the more permissive -EPERM rather
> 					      ^^^^^^^^^^
> "descriptive" like in the first patch?

Yes.

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

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

[Catalin Marinas]

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).

-- 
Catalin

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

[Mark Brown]

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

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.

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

Re: [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.

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

[Mark Brown]

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

On Thu, Sep 24, 2026 at 03:49:14PM -0500, Bill Roberts wrote:
> On 10/6/26 10:15 AM, Mark Brown wrote:

> > 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.

Yeah, it'd be great if that could land and we could hopefully eventually
end up with a shared interface for userspace.  We'd still need some arch
hooks no matter what, but the userspace experience would be much more
pleasant.

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

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

[Bill Roberts]

On 10/6/26 11:31 AM, Mark Brown wrote:
> On Thu, Sep 24, 2026 at 03:49:14PM -0500, Bill Roberts wrote:
>> On 10/6/26 10:15 AM, Mark Brown wrote:
>>> 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.
> Yeah, it'd be great if that could land and we could hopefully eventually
> end up with a shared interface for userspace.  We'd still need some arch
> hooks no matter what, but the userspace experience would be much more
> pleasant.
OK let me clean the patches up, and ill send em when I can. Does anyone
know how can I test the risc-v path?