On Mon, 10 Jun 2024 at 07:00, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Mon, Jun 10, 2024, at 00:24, Stefan Wahren wrote:
>
> >
> > After that i'm getting the following warning:
> >
> > create_pagelist: block 1, DMA address 0x00000000f5f62800 doesn't
> > align with PAGE_MASK 0xfffffffffffff000
> >
> > Then i bisected the issue to this commit:
> >
> > commit 1c1a429efd4ee8ca244cc2401365c983cda4ed76
> > Author: Catalin Marinas <catalin.marinas@xxxxxxx>
> > Date: Mon Jun 12 16:32:01 2023 +0100
> >
> > arm64: enable ARCH_WANT_KMALLOC_DMA_BOUNCE for arm64
> >
> > With the DMA bouncing of unaligned kmalloc() buffers now in place,
> > enable
> > it for arm64 to allow the kmalloc-{8,16,32,48,96} caches. In addition,
> > always create the swiotlb buffer even when the end of RAM is within the
> > 32-bit physical address range (the swiotlb buffer can still be
> > disabled on
> > the kernel command line).
> >
> > So how can the root cause of these warnings be fixed?
> > Or is the specific WARN_ON() now obsolete?
> >
>
> It appears that the buffer that gets passed to the device
> has a start address and length that both come from user
> space, and in this case crosses a page boundary, and the
> second half is not aligned to ARCH_KMALLOC_MINALIGN.
>
> This means it's not actually a kmalloc buffer that goes
> wrong, but userspace passing something that is problematic,
> see also the comment above create_pagelist().
>
> If that is a correct interpretation of what is going on,
> one way to solve it would be to add the same logic for
> vchiq user buffers that we have for kmalloc buffers:
> if either the start or the size of the user buffer in
> vchiq_irq_queue_bulk_tx_rx() are unaligned, just
> allocate a new kernel buffer for the whole thing instead
> of pinning the user buffer.
>
> Arnd
Why is swiotlb involved at all? The DMA controller on BCM2837 can
access all RAM that is visible to the ARM cores.
Phil
