[PATCH] arm64: cpufeature: Replace inline with __always_inline for GCS checks

From: lihaojie <redacted>

Fix error:
aarch64-linux-gnu-ld: arch/arm64/kernel/signal.o: in function `setup_sigframe':
signal.c:(.text+0x16ec): undefined reference to `preserve_gcs_context'
aarch64-linux-gnu-ld: arch/arm64/kernel/signal.o: in function `restore_sigframe':
signal.c:(.text+0x210c): undefined reference to `restore_gcs_context'

When CONFIG_ARM64_GCS is disabled, the compiler reports undefined symbol
errors, that's because of inline hint. __always_inline can resolve this
issue.

When use __always_inline The compiler will almost certainly inline
system_supports_gcs, which allows the compiler to optimize and check
earlier during the compilation phase. If system_supports_gcs() returns
false, then the line of code restore_gcs_context (&user) will not
actually be generated, so the compiler will not report an error.

Signed-off-by: lihaojie <redacted>
---
 arch/arm64/include/asm/cpufeature.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index bf13d676aae2..4eddf6e78d77 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h

@@ -846,7 +846,7 @@ static inline bool system_supports_poe(void)
 	return alternative_has_cap_unlikely(ARM64_HAS_S1POE);
 }
 
-static inline bool system_supports_gcs(void)
+static __always_inline bool system_supports_gcs(void)
 {
 	return alternative_has_cap_unlikely(ARM64_HAS_GCS);
 }

-- 
2.25.1

On Fri, Aug 15, 2025 at 09:19:05AM +0800, 15074444048@163.com wrote:

When use __always_inline The compiler will almost certainly inline
system_supports_gcs, which allows the compiler to optimize and check
earlier during the compilation phase. If system_supports_gcs() returns
false, then the line of code restore_gcs_context (&user) will not
actually be generated, so the compiler will not report an error.

-static inline bool system_supports_gcs(void)
+static __always_inline bool system_supports_gcs(void)
 {
 	return alternative_has_cap_unlikely(ARM64_HAS_GCS);
 }

If we're doing this for one of the system_supports_foo() functions we
should do it for all of them consistently, not just for one random one.

At 2025-08-15 23:38:11, "Mark Brown" [off-list ref] wrote:

On Fri, Aug 15, 2025 at 09:19:05AM +0800, 15074444048@163.com wrote:

quoted

When use __always_inline The compiler will almost certainly inline
system_supports_gcs, which allows the compiler to optimize and check
earlier during the compilation phase. If system_supports_gcs() returns
false, then the line of code restore_gcs_context (&user) will not
actually be generated, so the compiler will not report an error.

quoted

-static inline bool system_supports_gcs(void)
+static __always_inline bool system_supports_gcs(void)
 {
 	return alternative_has_cap_unlikely(ARM64_HAS_GCS);
 }

If we're doing this for one of the system_supports_foo() functions we
should do it for all of them consistently, not just for one random one.

Thanks for your advs!

The key point of this issue is that calling preserve_gcs_context and restore_gcs_context illegal,

quoted

quoted

@@ -1136,6 +1239,12 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
                __put_user_error(current->thread.fault_code, &esr_ctx->esr, err);
        }
 
+       if (system_supports_gcs() && err == 0 && user->gcs_offset) {
+               struct gcs_context __user *gcs_ctx =
+                       apply_user_offset(user, user->gcs_offset);
+               err |= preserve_gcs_context(gcs_ctx);
+       }

<<<
__always_inline just help optimize undefined func，Of course, this could also be circumvented 
by adding CONFIG_ARM64_GCS checks. I'don't think other system_support_foo() functions
 should modify, they don't exhibit similar problems.

On Sat, Aug 16, 2025 at 02:49:21PM +0800, 李豪杰 wrote:

At 2025-08-15 23:38:11, "Mark Brown" [off-list ref] wrote:

quoted

On Fri, Aug 15, 2025 at 09:19:05AM +0800, 15074444048@163.com wrote:

quoted

quoted

earlier during the compilation phase. If system_supports_gcs() returns
false, then the line of code restore_gcs_context (&user) will not
actually be generated, so the compiler will not report an error.

quoted

quoted

-static inline bool system_supports_gcs(void)
+static __always_inline bool system_supports_gcs(void)

quoted

If we're doing this for one of the system_supports_foo() functions we
should do it for all of them consistently, not just for one random one.

The key point of this issue is that calling preserve_gcs_context and restore_gcs_context illegal,

It is, but it's also a deliberate choice we're making for this and all
the other feature specific context save/restore functions based on the
belief that the optimiser will do the right thing for us (see the
comments next to the stubs).

+       if (system_supports_gcs() && err == 0 && user->gcs_offset) {
+               struct gcs_context __user *gcs_ctx =
+                       apply_user_offset(user, user->gcs_offset);
+               err |= preserve_gcs_context(gcs_ctx);
+       }

__always_inline just help optimize undefined func，Of course, this could also be circumvented 
by adding CONFIG_ARM64_GCS checks. I'don't think other system_support_foo() functions
 should modify, they don't exhibit similar problems.

Two things here.  One is that this is pure good fortune, we're using
exactly the same pattern with other configurable features like SVE and
SME so there's no reason a compiler can't decide to make the same
unfortunate decision there.  The other is that this is that adding an
__always_inline to just one of the system_supports_() functions without
explanation makes that part of the code confusing, it's not obvious to
someone reading the code what the difference is.  Having a consistent
style for those functions is a lot clearer.

Perhaps we just shouldn't be trying to be clever like this in the signal
code...