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

[Mark Brown]

On Sat, Aug 16, 2025 at 02:49:21PM +0800, 李豪杰 wrote:
> At 2025-08-15 23:38:11, "Mark Brown" <broonie at kernel.org> wrote:
> >On Fri, Aug 15, 2025 at 09:19:05AM +0800, 15074444048 at 163.com wrote:

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

> >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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250818/c811acd7/attachment.sig>