Re: slub - extended kmalloc redzone and dma alignment

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Apr 09, 2025 at 10:51:43AM +0200, Vlastimil Babka wrote:
> On 4/8/25 5:07 PM, Catalin Marinas wrote:
> > Assuming I got kmalloc redzoning right, I think there's still a
> > potential issue. Let's say we have a system with 128-byte DMA alignment
> > required (the largest cache line size). We do a kmalloc(104) and
> > kmalloc_size_roundup() returns 128, so all seems good to the DMA code.
> > However, kmalloc() redzones from 104 to 128 as it tracks the original
> > size. The DMA bouncing doesn't spot it since the
> > kmalloc_size_roundup(104) is aligned to 128.
> 
> Note that kmalloc_size_roundup() is supposed to be used *before*
> kmalloc(), such as dma_resv_list_alloc() does. Then there's no issue as
> no redzoning would not be done between 104 and 128, there would be only
> the additional redzone at 128+.

Yes, if people use it this way. devm_kmalloc() via alloc_dr() also seems
to be handling this. However, given the original report, I assume there
are drivers that have a problem with redzoning at the end of the buffer.

I did a quick test with kmem_cache_create() of 104 bytes with
SLAB_HWCACHE_ALIGN (64 bytes) and it has a similar problem with the
redzone from byte 104 onwards. Here we don't have the equivalent of
kmalloc_size_roundup() that a driver can use.

-- 
Catalin