Re: [PATCH] slab: align ZERO_SIZE_PTR to ARCH_KMALLOC_MINALIGN

Karl Mehltretter <[email protected]>
Newsgroups dev.linux.lists.llvm,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <[email protected]>
On Mon, Aug 10, 2026 at 03:26:37PM +0100, Catalin Marinas wrote:
> On Sat, Aug 08, 2026 at 12:56:22PM +0200, Karl Mehltretter wrote:
> > diff --git a/include/linux/slab.h b/include/linux/slab.h
> > index 32c9f8ed7ae20..0798a714da87f 100644
> > --- a/include/linux/slab.h
> > +++ b/include/linux/slab.h
> > @@ -259,13 +259,16 @@ enum _slab_flag_bits {
> >  
> >  /*
> >   * ZERO_SIZE_PTR will be returned for zero sized kmalloc requests.
> > + * It satisfies the alignment promised by __assume_kmalloc_alignment
> > + * and keeps the historic value 16 where that is already aligned.
> >   *
> >   * Dereferencing ZERO_SIZE_PTR will lead to a distinct access fault.
> >   *
> >   * ZERO_SIZE_PTR can be passed to kfree though in the same way that NULL can.
> >   * Both make kfree a no-op.
> >   */
> > -#define ZERO_SIZE_PTR ((void *)16)
> > +#define ZERO_SIZE_PTR ((void *)(ARCH_KMALLOC_MINALIGN > 16 ? \
> > +				ARCH_KMALLOC_MINALIGN : 16))
> >  
> >  #define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
> >  				(unsigned long)ZERO_SIZE_PTR)
> > @@ -622,6 +625,12 @@ static inline bool kmem_dump_obj(void *object) { return false; }
> >  #define KMALLOC_SHIFT_LOW ilog2(KMALLOC_MIN_SIZE)
> >  #endif
> >  
> > +/*
> > + * Keep ZERO_SIZE_PTR below PAGE_SIZE and the low pointer poison values.
> > + * 128 is the largest in-tree ARCH_KMALLOC_MINALIGN.
> > + */
> > +static_assert(ARCH_KMALLOC_MINALIGN <= 128);
> 
> I'm not sure we should bother with this, or at least make it strictly
> less than PAGE_SIZE since 128 doesn't have any meaning for the slab
> allocator.
> 

Thanks for the review!

The case I had in mind when choosing 128 was POISON_POINTER_DELTA == 0,
where LIST_POISON1 is 256 (0x100). With the current range check, an
architecture with non-coherent DMA and 256-byte cache lines would make
kfree(LIST_POISON1) a silent no-op.

Looking at this again, I think ZERO_OR_NULL_PTR() should match only NULL
and ZERO_SIZE_PTR, rather than the whole range below the sentinel. This
would also stop unrelated low pointer values from being silently
accepted. I'll include that change in v2.

Thanks,
Karl
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.