Re: [PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[Maciej Wieczor-Retman]

On 2026-02-12 at 16:28:10 -0800, Sohil Mehta wrote:
>On 2/12/2026 7:35 AM, Maciej Wieczor-Retman wrote:
>
>>
>> +const char *x86_cap_name(unsigned int bit)
>> +{
>> +	unsigned int word = bit >> 5;
>> +	static char undef_buf[16];
>> +	const char *name = NULL;
>> +
>> +	if (likely(word < NCAPINTS))
>> +		name = x86_cap_flags[bit];
>> +	else if (likely(word < NCAPINTS + NBUGINTS))
>> +		name = x86_bug_flags[bit - 32 * NCAPINTS];
>> +
>> +	if (name)
>> +		return name;
>> +
>> +	snprintf(undef_buf, sizeof(undef_buf), "%u:%u", word, bit & 31);
>> +	return undef_buf;
>> +}
>> +
>
>Isn't it unsafe to return undef_buf because the pointer is local to this
>function even though it is marked static?
>
>For example, the consecutive calls below would overwrite the value
>stored at that address.

I just rechecked and after I caused that pr_warn_once() to be executed the
strings are printed correctly.

Looking a bit further down, the pointers of the returned const char* are two
distinct values. So I assume because there are two calls to x86_cap_name() in
the pr_warn_once() the two static undef_buf char arrays are statically allocated
and there is no overwriting, but please correct me if that assumption is wrong.

>>  			pr_warn_once("x86 CPU feature dependency check failure: CPU%d has '%s' enabled but '%s' disabled. Kernel might be fine, but no guarantees.\n",
>>  				     smp_processor_id(),
>> -				     x86_feature_name(d->feature, feature_buf),
>> -				     x86_feature_name(d->depends, depends_buf));
>> +				     x86_cap_name(d->feature),
>> +				     x86_cap_name(d->depends));
>>  		}
>>  	}
>>  }

-- 
Kind regards
Maciej Wieczór-Retman