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

[H. Peter Anvin]

On 2026-02-13 02:02, Maciej Wieczor-Retman wrote:
> 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.
> 

At the very least the buffer would need to be percpu for it to be safe. On the
other hand, there aren't a whole lot of places that uses this and the buffer
needed isn't that big, so the best way is probably to have the caller pass in
a buffer pointer on the stack. The callers are typically going to be large
functions which require a stack frame anyway.

	-hpa