From: Christoph Hellwig <hch@infradead.org>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
"Matwey V. Kornilov" <matwey@sai.msu.ru>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Matwey V. Kornilov" <matwey.kornilov@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
Ezequiel Garcia <ezequiel@collabora.com>,
hdegoede@redhat.com, Hans Verkuil <hverkuil@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
rostedt@goodmis.org, mingo@redhat.com,
Mike Isely <isely@pobox.com>, Bhumika Goyal <bhumirks@gmail.com>,
Colin King <colin.king@canonical.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
keiichiw@chromium.org
Subject: Re: [PATCH v5 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
Date: Fri, 21 Dec 2018 00:13:59 -0800 [thread overview]
Message-ID: <20181221081359.GA14707@infradead.org> (raw)
In-Reply-To: <CAAFQd5CsX-YJdwQUS+eEK6kj1xU94AiGHY0QX=QGnf67JcKyaQ@mail.gmail.com>
On Thu, Dec 20, 2018 at 12:23:46PM +0900, Tomasz Figa wrote:
> I haven't been following the problems with virtually tagged cases,
> would you mind sharing some background, so that we can consider it
> when adding non-consistent allocations to VB2?
The problem exists at least partially with the current consistent
allocator, and we need to fix it. My non-coherent series does not have
it, but we would add it if we allowed virtual remapping.
The problem with get_sgtable is that it creates aliasing of kernel
virtual addresses used to access memory and thus the cache. We have
the mapping return from dma_alloc_*, which in case of a remap contains
a vmap/ioremap style address that is different from the kernel direct
mapping address you get from using page_address/kmap on the pages
backing that mapping. (assuming you even have pages - in a few corner
cases we don't and the whole interface concept breaks down).
This creates various problems as the the scatterlist returned from
get_stable now gives a second way to access this memory through direct
mapping addresses in the pages contained in it, but as soon as we do
that we:
a) don't use the nocache mapping used by the coherent allocator if that
is on a per-mapping basis (which it is for many architectures), so
you do get data in the cache even when that might not be assumed
b) if the data returned from dma_alloc_coherent was not actually a
remap but a special pool of non-cached address the cache flushing
instructions might be invalid and caused problems
c) any cache flushing now operates on just those direct mappings, which
in case of the non-coherent allocator and access through the
remapped address does the wrong thing for virtually tagged caches
prev parent reply other threads:[~2018-12-21 8:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-21 17:06 [PATCH v5 0/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer Matwey V. Kornilov
2018-08-21 17:06 ` [PATCH v5 1/2] media: usb: pwc: Introduce TRACE_EVENTs for pwc_isoc_handler() Matwey V. Kornilov
2018-08-21 19:49 ` Steven Rostedt
2018-08-21 19:49 ` Steven Rostedt
2018-08-21 17:06 ` [PATCH v5 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer Matwey V. Kornilov
2018-08-28 7:17 ` Matwey V. Kornilov
2018-09-11 18:58 ` Matwey V. Kornilov
2018-09-19 16:12 ` Ezequiel Garcia
2018-10-10 21:13 ` Matwey V. Kornilov
2018-10-30 22:00 ` Laurent Pinchart
2018-10-31 5:38 ` Christoph Hellwig
2018-12-07 15:25 ` Christoph Hellwig
2018-12-12 8:57 ` Tomasz Figa
2018-12-12 9:09 ` Christoph Hellwig
2018-12-12 9:34 ` Tomasz Figa
2018-12-12 13:54 ` Christoph Hellwig
2018-12-13 3:13 ` Tomasz Figa
2018-12-13 14:03 ` Christoph Hellwig
2018-12-14 3:12 ` Tomasz Figa
2018-12-14 12:36 ` Christoph Hellwig
2018-12-18 7:22 ` Tomasz Figa
2018-12-18 7:38 ` Christoph Hellwig
2018-12-18 9:48 ` Tomasz Figa
2018-12-19 7:51 ` Christoph Hellwig
2018-12-19 8:18 ` Tomasz Figa
2018-12-19 14:51 ` Christoph Hellwig
2018-12-20 3:23 ` Tomasz Figa
2018-12-21 8:13 ` Christoph Hellwig [this message]
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=20181221081359.GA14707@infradead.org \
--to=hch@infradead.org \
--cc=bhumirks@gmail.com \
--cc=colin.king@canonical.com \
--cc=ezequiel@collabora.com \
--cc=hdegoede@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=isely@pobox.com \
--cc=keiichiw@chromium.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=matwey.kornilov@gmail.com \
--cc=matwey@sai.msu.ru \
--cc=mchehab@kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=stern@rowland.harvard.edu \
--cc=tfiga@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.