[GIT PULL] dma-mapping fix for Linux 5.14

[GIT PULL] dma-mapping fix for Linux 5.14

[Christoph Hellwig]

The following changes since commit d936eb23874433caa3e3d841cfa16f5434b85dcf:

  Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" (2021-07-15 18:05:31 -0700)

are available in the Git repository at:

  git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.14-1

for you to fetch changes up to 40ac971eab89330d6153e7721e88acd2d98833f9:

  dma-mapping: handle vmalloc addresses in dma_common_{mmap,get_sgtable} (2021-07-16 11:30:26 +0200)

----------------------------------------------------------------
dma-mapping fix for Lonux 5.14

  - handle vmalloc addresses in dma_common_{mmap,get_sgtable}
    (Roman Skakun)

----------------------------------------------------------------
Roman Skakun (1):
      dma-mapping: handle vmalloc addresses in dma_common_{mmap,get_sgtable}

 kernel/dma/ops_helpers.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

Re: [GIT PULL] dma-mapping fix for Linux 5.14

[Linus Torvalds]

On Sat, Jul 24, 2021 at 11:03 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> dma-mapping fix for Lonux 5.14

We're calling it "Lonux" now?

>   - handle vmalloc addresses in dma_common_{mmap,get_sgtable}
>     (Roman Skakun)

I've pulled this, but my reaction is that we've tried to avoid this in
the past. Why is Xen using vmalloc'ed addresses and passing those in
to the dma mapping routines?

It *smells* to me like a Xen-swiotlb bug, and it would have been
better to try to fix it there. Was that just too painful?

                  Lonus

Re: [GIT PULL] dma-mapping fix for Linux 5.14

[Christoph Hellwig]

On Sun, Jul 25, 2021 at 09:50:29AM -0700, Linus Torvalds wrote:
> On Sat, Jul 24, 2021 at 11:03 PM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > dma-mapping fix for Lonux 5.14
> 
> We're calling it "Lonux" now?

Only on weekends :)

> >   - handle vmalloc addresses in dma_common_{mmap,get_sgtable}
> >     (Roman Skakun)
> 
> I've pulled this, but my reaction is that we've tried to avoid this in
> the past. Why is Xen using vmalloc'ed addresses and passing those in
> to the dma mapping routines?
> 
> It *smells* to me like a Xen-swiotlb bug, and it would have been
> better to try to fix it there. Was that just too painful?

vmalloc (or rather vmap) addresses actually are the most common
way to provide uncachable mappings on architectures that are not
cache coherent.  The only Xen part here is that swiotlb-xen is a mess
and gets the address from the dma-direct allocator which does vmapping
for arm/arm64, but then uses the common helpers later due to a variety
of issues that will take a while to address.

Re: [GIT PULL] dma-mapping fix for Linux 5.14

[Boris Ostrovsky]

On 7/25/21 12:50 PM, Linus Torvalds wrote:
> On Sat, Jul 24, 2021 at 11:03 PM Christoph Hellwig <hch@infradead.org> wrote:
>
>>   - handle vmalloc addresses in dma_common_{mmap,get_sgtable}
>>     (Roman Skakun)
> I've pulled this, but my reaction is that we've tried to avoid this in
> the past. Why is Xen using vmalloc'ed addresses and passing those in
> to the dma mapping routines?
>
> It *smells* to me like a Xen-swiotlb bug, and it would have been
> better to try to fix it there. Was that just too painful?


Stefano will probably know better but this appears to have something to do with how Pi (and possibly more ARM systems?) manage DMA memory: https://lore.kernel.org/xen-devel/CADz_WD5Ln7Pe1WAFp73d2Mz9wxspzTE3WgAJusp5S8LX4=83Bw@mail.gmail.com/.




-boris

Re: [GIT PULL] dma-mapping fix for Linux 5.14

[Stefano Stabellini]

On Mon, 26 Jul 2021, Boris Ostrovsky wrote:
> On 7/25/21 12:50 PM, Linus Torvalds wrote:
> > On Sat, Jul 24, 2021 at 11:03 PM Christoph Hellwig <hch@infradead.org> wrote:
> >
> >>   - handle vmalloc addresses in dma_common_{mmap,get_sgtable}
> >>     (Roman Skakun)
> > I've pulled this, but my reaction is that we've tried to avoid this in
> > the past. Why is Xen using vmalloc'ed addresses and passing those in
> > to the dma mapping routines?
> >
> > It *smells* to me like a Xen-swiotlb bug, and it would have been
> > better to try to fix it there. Was that just too painful?
> 
> 
> Stefano will probably know better but this appears to have something to do with how Pi (and possibly more ARM systems?) manage DMA memory: https://lore.kernel.org/xen-devel/CADz_WD5Ln7Pe1WAFp73d2Mz9wxspzTE3WgAJusp5S8LX4=83Bw@mail.gmail.com/.

The original issue was found on the Raspberry Pi 4, and the fix was in
swiotlb-xen.c, commit 8b1e868f6. More recently, Roman realized that
dma_common_mmap might also end up calling virt_to_page on a vmalloc
address. This is the fix for that.


Why is Xen using vmalloc'ed addresses with dma routines at all?

Xen is actually just calling the regular dma_direct_alloc to allocate
pages (xen_swiotlb_alloc_coherent -> xen_alloc_coherent_pages ->
dma_direct_alloc). dma_direct_alloc is the generic implementation. Back
when the original issue was found, dma_direct_alloc returned a vmalloc
address on RPi4.

The original analysis was "xen_alloc_coherent_pages() eventually calls
arch_dma_alloc() in remap.c which successfully allocates pages from
atomic pool." See https://marc.info/?l=xen-devel&m=158878173207775.


I don't know on which platform Roman Skakun (CC'ed) found the problem.
But if we look at arch/arm/mm/dma-mapping.c:__dma_alloc, one of the
possible options is the "remap_allocator", which calls
__alloc_remap_buffer, which calls dma_common_contiguous_remap, which
calls vmap.

So unfortunately it seems that on certain arch/platforms
dma_alloc_coherent can return a vmap'ed address. So I would imagine this
issue could also happen on native (without Xen), at least in theory.

Re: [GIT PULL] dma-mapping fix for Linux 5.14

[Roman Skakun]

Hi, Stefano!

> I don't know on which platform Roman Skakun (CC'ed) found the problem.
> But if we look at arch/arm/mm/dma-mapping.c:__dma_alloc, one of the
> possible options is the "remap_allocator", which calls
> __alloc_remap_buffer, which calls dma_common_contiguous_remap, which
> calls vmap.

Using  Renesas R-car H3 platform.
I have tested this case on 1:1 dom0 with < 4GB memory, but this case
still exists.
I'm still wondering why xen-swiotlb mapped vmalloc'ed addresses for
low memory DMA addresses.

пн, 26 июл. 2021 г. в 23:03, Stefano Stabellini <sstabellini@kernel.org>:
>
> On Mon, 26 Jul 2021, Boris Ostrovsky wrote:
> > On 7/25/21 12:50 PM, Linus Torvalds wrote:
> > > On Sat, Jul 24, 2021 at 11:03 PM Christoph Hellwig <hch@infradead.org> wrote:
> > >
> > >>   - handle vmalloc addresses in dma_common_{mmap,get_sgtable}
> > >>     (Roman Skakun)
> > > I've pulled this, but my reaction is that we've tried to avoid this in
> > > the past. Why is Xen using vmalloc'ed addresses and passing those in
> > > to the dma mapping routines?
> > >
> > > It *smells* to me like a Xen-swiotlb bug, and it would have been
> > > better to try to fix it there. Was that just too painful?
> >
> >
> > Stefano will probably know better but this appears to have something to do with how Pi (and possibly more ARM systems?) manage DMA memory: https://lore.kernel.org/xen-devel/CADz_WD5Ln7Pe1WAFp73d2Mz9wxspzTE3WgAJusp5S8LX4=83Bw@mail.gmail.com/.
>
> The original issue was found on the Raspberry Pi 4, and the fix was in
> swiotlb-xen.c, commit 8b1e868f6. More recently, Roman realized that
> dma_common_mmap might also end up calling virt_to_page on a vmalloc
> address. This is the fix for that.
>
>
> Why is Xen using vmalloc'ed addresses with dma routines at all?
>
> Xen is actually just calling the regular dma_direct_alloc to allocate
> pages (xen_swiotlb_alloc_coherent -> xen_alloc_coherent_pages ->
> dma_direct_alloc). dma_direct_alloc is the generic implementation. Back
> when the original issue was found, dma_direct_alloc returned a vmalloc
> address on RPi4.
>
> The original analysis was "xen_alloc_coherent_pages() eventually calls
> arch_dma_alloc() in remap.c which successfully allocates pages from
> atomic pool." See https://marc.info/?l=xen-devel&m=158878173207775.
>
>
> I don't know on which platform Roman Skakun (CC'ed) found the problem.
> But if we look at arch/arm/mm/dma-mapping.c:__dma_alloc, one of the
> possible options is the "remap_allocator", which calls
> __alloc_remap_buffer, which calls dma_common_contiguous_remap, which
> calls vmap.
>
> So unfortunately it seems that on certain arch/platforms
> dma_alloc_coherent can return a vmap'ed address. So I would imagine this
> issue could also happen on native (without Xen), at least in theory.



-- 
Best Regards, Roman.

Re: [GIT PULL] dma-mapping fix for Linux 5.14

[pr-tracker-bot]

The pull request you sent on Sun, 25 Jul 2021 08:03:21 +0200:

> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.14-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/04ca88d056b44efee1e7635c74c0be3705efc72c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html