Re: [PATCH v7 00/17] mm, dma, arm64: Reduce ARCH_KMALLOC_MINALIGN to 8

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

Hi Amit,

On Wed, Jul 05, 2023 at 07:10:02PM +0530, Amit Pundir wrote:
> On Wed, 5 Jul 2023 at 18:17, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > That's v7 of the series reducing the kmalloc() minimum alignment on
> > arm64 to 8 (from 128). There's no new/different functionality, mostly
> > cosmetic changes and acks/tested-bys.
> >
> > Andrew, if there are no further comments or objections to this version,
> > are you ok to take the series through the mm tree? The arm64 changes are
> > fairly small. Alternatively, I can push it into linux-next now to give
> > it some wider exposure and decide whether to upstream it when the
> > merging window opens. Thanks.
> 
> This patch series broke Dragonboard 845c (SDM845) running AOSP.
> With this series I run into random oops at __kmem_cache_alloc_node().
> Here is one such boot log https://bugs.linaro.org/attachment.cgi?id=1146
> 
> Reverting "arm64: Enable ARCH_WANT_KMALLOC_DMA_BOUNCE for arm64"
> fixes it for the time being.

I'm on holiday until the 24th, away from my computer and I don't have
much time to dig into this. Are the DMA-capable devices on this platform
non-coherent? We'd need to check whether the bouncing logic somehow
overflows and corrupts adjacent memory. If the devices are coherent,
maybe the DMA spills over the kmalloc() boundaries, now that we
allocate buffers smaller than a cacheline even for DMA (no bouncing if
the DMA is coherent). Also, are these devices behind an IOMMU?

Yet another possibility is a not fully transparent system level cache
with a line size larger than what's reported by the CTR_EL0.CWG. If you
boot the platform with "swiotlb=noforce", do you still see issues? Or
there's no swiotlb buffer allocated anyway.

In addition to what Isaac suggests on slab debugging, it may be worth
enabling DMA debugging as well (I don't remember the config name).

-- 
Catalin