Re: [PATCH v5 6/8] string: introduce memcpy_nt() helpers

"David Hildenbrand (Arm)" <[email protected]>
Newsgroups org.kernel.vger.linux-arch,org.kernel.vger.linux-hardening,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <[email protected]>
On 7/6/26 13:53, Li Zhe wrote:
> On Mon, Jul 6, 2026 at 11:18:48AM +0200, [email protected] wrote:
> 
>>> +
>>> +#define __HAVE_ARCH_MEMCPY_NT 1
>>> +/*
>>> + * Reuse the existing x86 flushcache backend as the nt copy primitive.
>>> + * Callers pair it with memcpy_nt_drain() when later stores must be
>>> + * ordered after the copy.
>>> + */
>>> +static __always_inline void memcpy_nt(void *dst, const void *src, size_t cnt)
>>> +{
>>> +	memcpy_flushcache(dst, src, cnt);
>>> +}
>>
>> In particular if you end up with a single function (that jsut requires a write
>> memory barrier afterwards), please make this
>>
>> #define memcpy_nt memcpy_nt
>>
>> instead.
> 
> Thanks for the review.
> 
> Just to make sure I understood this correctly: do you mean that, rather
> than using a separate __HAVE_ARCH_MEMCPY_NT feature macro, you would
> prefer the usual self-macro override pattern, with
> 
>     #define memcpy_nt memcpy_nt
> 
> in arch/x86/include/asm/string_64.h and the generic fallback kept under
> #ifndef memcpy_nt in include/linux/string.h?

Yes, that's what Linus suggested as the preferred way for single functions when
it came up in different context recently.

-- 
Cheers,

David
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.