Re: slub - extended kmalloc redzone and dma alignment

[Petr Tesarik <ptesarik@suse.com>]

On Fri, 4 Apr 2025 19:30:09 +0900
Harry Yoo <harry.yoo@oracle.com> wrote:

> On Fri, Apr 04, 2025 at 11:30:49AM +0200, Vlastimil Babka wrote:
> > Hi,
> > 
> > due to some off-list inquiry I have realized that since 946fa0dbf2d8
> > ("mm/slub: extend redzone check to extra allocated kmalloc space than
> > requested")
> > we might be reporting false positives due to dma writing into the redzone.
> > 
> > It wasn't confirmed (yet) during the conversation but AFAICS it can be
> > happening. We have this ARCH_DMA_MINALIGN and kmalloc() will guarantee it,
> > but the redzone check doesn't take it into account.  
> 
> Sounds valid to me.

I'm not sure I understand your concerns.

Are you afraid that another device on the bus caches a copy of the
redzone before it was poisoned, so it overwrites the redzone with stale
data on a memory write operation? IMO that's buggy, because if a
bus-mastering device implements such cache, it is the device driver's
responsibility to flush it before starting a DMA transfer. FTR I'm not
aware of any such devices, except GPUs, but there's a whole lot to do
about CPU<->GPU coherency management, including device-specific ioctl's
to expose some gory details all the way down to userspace.

Or are you concerned about bus data word size? I would again argue that
allocating a DMA buffer with a size that is not a multiple of the
transfer size is a bug. IOW the driver must make sure the buffer size
is a multiple of 4 if it is used for 32-bit DMA transfers, or a
multiple of 8 if it is used for 64-bit DMA transfers.

Confused.

Petr T