iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Roman Skakun <rm.skakun@gmail.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Roman Skakun <rm.skakun@epam.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	iommu <iommu@lists.linux-foundation.org>,
	Roman Skakun <roman_skakun@epam.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [GIT PULL] dma-mapping fix for Linux 5.14
Date: Thu, 29 Jul 2021 13:17:09 +0300	[thread overview]
Message-ID: <CADu_u-OG0pMQN_nD5ayYOmNRWDn1VSPT05s5ddSQkoemYf_Sew@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2107261212500.10122@sstabellini-ThinkPad-T480s>

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.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-07-29 10:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-25  6:03 [GIT PULL] dma-mapping fix for Linux 5.14 Christoph Hellwig
2021-07-25 16:50 ` Linus Torvalds
2021-07-25 17:36   ` Christoph Hellwig
2021-07-26 17:30   ` Boris Ostrovsky
2021-07-26 20:03     ` Stefano Stabellini
2021-07-29 10:17       ` Roman Skakun [this message]
2021-07-25 17:49 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADu_u-OG0pMQN_nD5ayYOmNRWDn1VSPT05s5ddSQkoemYf_Sew@mail.gmail.com \
    --to=rm.skakun@gmail.com \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rm.skakun@epam.com \
    --cc=roman_skakun@epam.com \
    --cc=sstabellini@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).