Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp()

[Mauricio Faria de Oliveira]

On 2026-09-06 15:15, H. Peter Anvin wrote:
> On September 6, 2026 10:01:16 AM PDT, Borislav Petkov <bp@xxxxxxxxx> wrote:
>>On Sat, Aug 22, 2026 at 03:33:18PM -0300, Mauricio Faria de Oliveira wrote:
>>> Move the inline memcmp function currently only available in 'boot/string.c'
>>> into the shared string function header <asm/shared/string.h> to be reused.
>>> 
>>> This is not done through <asm/string.h> to avoid pulling unnecessary code
>>> in 'boot/string.c' that causes build errors in 'boot/compressed/string.c'
>>> and 'purgatory/purgatory.ro'.
>>
>>Please drop those '' quotes - it is perfectly clear that those are .c files.
>>
>>> No functional changes.
>>> 
>>> Signed-off-by: Mauricio Faria de Oliveira <mfo@xxxxxxxxxx>
>>> 
>>> ---
>>> 
>>> Thanks to David Laight for noticing the return value difference between
>>> inline and regular memcmp().
>>> ---
>>>  arch/x86/boot/string.c               | 13 ++-----------
>>>  arch/x86/include/asm/shared/string.h | 26 ++++++++++++++++++++++++++
>>>  2 files changed, 28 insertions(+), 11 deletions(-)
>>
>>...
>>
>>> diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..06c1d5e5013e4d59cfb49866d10e164362d2c4cc
>>> --- /dev/null
>>> +++ b/arch/x86/include/asm/shared/string.h
>>> @@ -0,0 +1,26 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +#ifndef _ASM_X86_SHARED_STRING_H
>>> +#define _ASM_X86_SHARED_STRING_H
>>> +
>>> +/*
>>> + * This inline memcmp() returns 0 (equal) or 1 (not equal).
>>> + * The regular memcmp() returns <0 (less than), 0 (equal), or >0 (greater than)
>>> + * to indicate ordering as well.
>>
>>No need to overdo it:
>>
>>	Returns:	0 (equal)
>>			1 (not equal)
>>
>>In contrast, the regular memcmp() follows glibc return value semantics.
>>
>>
> 
> Worth noting that memeq() and streq() are becoming used in other contexts, e.g. glibc.

Thanks for mentioning.

Boris, perhaps the approach here could be changed to add an actual
memcmp()-like inline implementation (e.g., as provided in a previous
revision, without return value differences), or continue with the
memeq()-like memcmp() from arch/x86/boot/ but rename it to memeq() ?

-- 
Mauricio