[PATCH 2/2] aarch64: Accept string values for glibc.cpu.aarch64_gcs tunable

[Yury Khrustalev]

On Mon, Mar 30, 2026 at 03:42:17PM -0300, Adhemerval Zanella Netto wrote:
>
> ...
>
> >> The '__tunable_print_error' function is exposed globally so that invalid
> >> string inputs caught in the newly added 'aarch64_gcs' callback can trigger
> >> standard tunable warnings.
> > 
> > I think that this change is mostly cosmetic and I don't think it's worth
> > doing given the changes it needs and the increased complexity of the code
> > that parse this tunable value. GCS tunable should take as little code as
> > possible to parse it by the nature of it.
> 
> It is usability improvement, so not really only 'comestic'.  Sure it is not
> strictly required, but it makes the usage and script that eventually need
> to setup the GLIBC_TUNABLE more readable to what GCS semantic it wants to
> use.

Users would need to use either 1 or 0 which should be straightforward. I
agree that enum values are easier to use but the amount of code that
needs to run to support them seems to high.

> 
> ...
>
> > 
> >> +    {
> >> +      if (tunable_val_lt (val, AARCH64_GCS_POLICY_DISABLED, true))
> >> +	val = AARCH64_GCS_POLICY_DISABLED;
> >> +      if (tunable_val_gt (val, AARCH64_GCS_POLICY_OVERRIDE, true))
> >> +	val = AARCH64_GCS_POLICY_OVERRIDE;
> >> +      GL(dl_aarch64_gcs) = val;
> >> +    }
> > 
> > If the value provided by the user is less than 0 or more than 3, it's an
> > error, we should not implicitly convert it to one of the supported
> > values.
> 
> Indeed, it is a mistake in my reading of do_tunable_update_val. If the
> value is out of range we should use the default one.

The code in 'dl-gcs.c' treats any out of range value as an error, but it
seems like 'TUNABLE_GET' returns default value in this case. I'm not
sure when this change happened, it seems to add inconsistency between
string and integer tunables. I think that silent change of behaviour is
not ideal, it should be an error.

Thanks,
Yury