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

[Maciej Wieczor-Retman]

On 2026-02-13 at 12:15:24 -0800, H. Peter Anvin wrote:
>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
>

Sure, I'll change it to pass a pointer.

-- 
Kind regards
Maciej Wieczór-Retman