The kmalloc_nolock() infrastructure relies on slab caches with double-word atomic cmpxchg capabilities (__CMPXCHG_DOUBLE). The current inline comment in __kmalloc_nolock_noprof() uses 'cmpxchg16b' as the prerequisite hardware capability. However, "cmpxchg16b" is an x86-specific instruction mnemonic (CX16). On modern architectures supported by the Linux kernel, this 128-bit atomic primitive is satisfied by different hardware implementations: - arm64: satisfies it via LSE atomics ('casp' instruction) - s390: satisfies it via native 'cdsg' instruction - riscv: satisfies it via ZACAS extension ('amocas.q' instruction) - loongarch: satisfies it via SCQ extension (using an 'll.d'/'sc.q' loop) Update the comment to refer to "128-bit atomic cmpxchg" to accurately describe the cross-platform hardware invariant needed by the lockless allocator, and to avoid misleading developers of non-x86 archs. Signed-off-by: Tiezhu Yang --- mm/slub.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 45e077c7526c..216bc6b5d776 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -5589,8 +5589,8 @@ static void *__kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_f if (!(s->flags & __CMPXCHG_DOUBLE) && !kmem_cache_debug(s)) /* * kmalloc_nolock() is not supported on architectures that - * don't implement cmpxchg16b and thus need slab_lock() - * which could be preempted by a nmi. + * don't implement 128-bit atomic cmpxchg and thus need + * slab_lock() which could be preempted by a nmi. * But debug caches don't use that and only rely on * kmem_cache_node->list_lock, so kmalloc_nolock() can attempt * to allocate from debug caches by -- 2.42.0