From: Harry Yoo <harry@kernel.org>
To: Karl Mehltretter <kmehltretter@gmail.com>,
Vlastimil Babka <vbabka@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Hao Li <hao.li@linux.dev>, Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [RFC PATCH] slab: don't assume alignment on allocators that may return ZERO_SIZE_PTR
Date: Mon, 13 Jul 2026 14:18:19 +0900 [thread overview]
Message-ID: <f2def8bd-4eb8-4e5f-a22f-4061297ddb03@kernel.org> (raw)
In-Reply-To: <20260712120728.96628-1-kmehltretter@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6520 bytes --]
[+Cc Catalin for ARCH_KMALLOC_MINALIGN bits]
On 7/12/26 9:07 PM, Karl Mehltretter wrote:
> __kmalloc_noprof(), __kmalloc_node_noprof(), and __kmalloc_flags_noprof()
> are annotated with __assume_kmalloc_alignment, which expands to
> __assume_aligned(ARCH_KMALLOC_MINALIGN). All three can return
> ZERO_SIZE_PTR, currently (void *)16, for zero-sized requests. When
> ARCH_KMALLOC_MINALIGN exceeds 16, this contradicts the annotation.
Ouch.
> Compilers may use this false assumption to reduce ZERO_OR_NULL_PTR() to a
> NULL check, losing recognition of ZERO_SIZE_PTR. Current GCC and Clang
> retain the existing range check through kmalloc's inline wrapper, so no
> functional miscompile was reproduced with the current source form. However,
> both eliminate an exact ZERO_SIZE_PTR comparison on the same return value.
> With Clang, UBSAN also reports the invalid alignment assumption at boot.
>
> Changing ZERO_SIZE_PTR to satisfy the annotation would make its value and
> the range accepted by ZERO_OR_NULL_PTR() architecture-dependent. Avoid that
> semantic change by dropping the annotation from the general kmalloc entry
> points. Retain it on the cache helpers, which cannot return the sentinel.
> Allocation behavior is unchanged.
>
> Kernels before v7.2 do not have __kmalloc_flags_noprof().
> Backports to those kernels only need the include/linux/slab.h change.
>
> Fixes: 94a58c360a45 ("slab.h: sprinkle __assume_aligned attributes")
> Fixes: f6d50ab29afd ("mm/slab: introduce kmalloc_flags()")
> Cc: <stable@vger.kernel.org> # needs adjustment before v7.2
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
>
> Notes:
> This is RFC because the alignment contract can be corrected in three ways:
I think it's still worth having at least a weaker alignment guarantee
and would like to vote for option 3 (or option 2, if 3 turns out to be
infeasible) unless there's something unexpected that prevents us from
doing that.
> 1. Remove the annotation from entry points that can return ZERO_SIZE_PTR
> (this patch). On armv5 this increases .text by 1120 bytes (0.02%);
> no measurable change was seen on arm64.
>
> 2. Cap the assumed alignment at 16. This preserves some alignment
> information but couples the annotation to the current sentinel value.
>
> 3. Change ZERO_SIZE_PTR to satisfy ARCH_KMALLOC_MINALIGN. This makes the
> long-standing sentinel architecture-dependent and either expands the
> range accepted by ZERO_OR_NULL_PTR() or requires changing that macro.
Some code (e.g., kmem_dump_obj()) performs (addr < PAGE_SIZE) check
either NULL or ZERO_SIZE_PTR) to see if the address is valid.
Bumping ZERO_SIZE_PTR to something smaller than PAGE_SIZE should still
work: (addr < PAGE_SIZE) check still works, and accessing it still
causes a fault. No arch should have ARCH_KMALLOC_MINALIGN >= PAGE_SIZE?
--
Cheers,
Harry / Hyeonggon
> On armv5, Clang UBSAN reports the invalid alignment assumption during boot;
> the report disappears with this patch.
>
> Clang 22 and GCC 13 retain ZERO_OR_NULL_PTR()'s existing range check through
> _kmalloc_noprof(), so no functional miscompile was reproduced in current
> code. This is an optimizer limitation, not a guarantee. For a kmalloc return
> value, writing the check as "!p || p == ZERO_SIZE_PTR" causes both compilers
> to remove the ZERO_SIZE_PTR comparison. Built into an armv5 kernel with that
> form, a zero-size allocation is then no longer recognised and is dereferenced:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000010
> Internal error: Oops: 805 [#1] ARM
> PC is at __fc_init+0x3c/0x60
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> Without the annotation the comparison is retained and the kernel boots.
>
> Would the slab maintainers prefer removing the annotation or retaining a
> weaker, valid alignment guarantee?
>
> include/linux/slab.h | 12 ++++++++----
> mm/slab.h | 3 ++-
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 51f03f18c9a7..1c63048f6467 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -632,8 +632,12 @@ static inline unsigned int arch_slab_minalign(void)
>
> /*
> * kmem_cache_alloc and friends return pointers aligned to ARCH_SLAB_MINALIGN.
> - * kmalloc and friends return pointers aligned to both ARCH_KMALLOC_MINALIGN
> - * and ARCH_SLAB_MINALIGN, but here we only assume the former alignment.
> + * Objects allocated by kmalloc and friends are aligned to both
> + * ARCH_KMALLOC_MINALIGN and ARCH_SLAB_MINALIGN, but here we only assume the
> + * former alignment.
> + *
> + * This guarantee does not apply to ZERO_SIZE_PTR, which is not an allocated
> + * object.
> */
> #define __assume_kmalloc_alignment __assume_aligned(ARCH_KMALLOC_MINALIGN)
> #define __assume_slab_alignment __assume_aligned(ARCH_SLAB_MINALIGN)
> @@ -939,10 +943,10 @@ unsigned int kmem_cache_sheaf_size(struct slab_sheaf *sheaf);
> */
>
> void *__kmalloc_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t flags)
> - __assume_kmalloc_alignment __alloc_size(1);
> + __alloc_size(1);
>
> void *__kmalloc_node_noprof(DECL_KMALLOC_PARAMS(size, b, token), gfp_t flags, int node)
> - __assume_kmalloc_alignment __alloc_size(1);
> + __alloc_size(1);
>
> void *__kmalloc_cache_noprof(struct kmem_cache *s, gfp_t flags, size_t size)
> __assume_kmalloc_alignment __alloc_size(3);
> diff --git a/mm/slab.h b/mm/slab.h
> index 281a65233795..aea1373c7f83 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -28,9 +28,10 @@ static inline bool alloc_flags_allow_spinning(const unsigned int alloc_flags)
> return !(alloc_flags & SLAB_ALLOC_NOLOCK);
> }
>
> +/* Can return ZERO_SIZE_PTR, so not tagged __assume_kmalloc_alignment. */
> void *__kmalloc_flags_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t flags,
> unsigned int alloc_flags, int node)
> - __assume_kmalloc_alignment __alloc_size(1);
> + __alloc_size(1);
>
> static __always_inline __alloc_size(1) void *_kmalloc_flags_noprof(size_t size,
> gfp_t flags, unsigned int alloc_flags, int node, kmalloc_token_t token)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-07-13 5:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-12 12:07 [RFC PATCH] slab: don't assume alignment on allocators that may return ZERO_SIZE_PTR Karl Mehltretter
2026-07-13 5:18 ` Harry Yoo [this message]
2026-07-13 16:53 ` Vlastimil Babka (SUSE)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2def8bd-4eb8-4e5f-a22f-4061297ddb03@kernel.org \
--to=harry@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=hao.li@linux.dev \
--cc=kmehltretter@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=llvm@lists.linux.dev \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.