From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: Bug(?) in patch "arm64: Implement coherent DMA API based on swiotlb" (was Re: [GIT PULL] arm64 patches for 3.15)
Date: Wed, 2 Apr 2014 12:13:26 +0100 [thread overview]
Message-ID: <20140402111326.GC31892@arm.com> (raw)
In-Reply-To: <20140402094045.GH7528@n2100.arm.linux.org.uk>
On Wed, Apr 02, 2014 at 10:40:45AM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 02, 2014 at 10:20:32AM +0100, Catalin Marinas wrote:
> > You are right. I think having unaligned DMA buffers for inbound
> > transfers is pointless. We can avoid losing data written by another CPU
> > in the same cache line but, depending on the stage of the DMA transfer,
> > it can corrupt the DMA data.
> >
> > I wonder whether it's easier to define the cache_line_size() macro to
> > read CWG and assume that the DMA buffers are always aligned, ignoring
> > the invalidation of the unaligned boundaries. This wouldn't be much
> > different from your scenario where the shared cache line is written
> > (just less likely to trigger but still a bug, so I would rather notice
> > this early).
> >
> > The ARMv7 code has a similar issue, it performs clean&invalidate on the
> > unaligned start but it doesn't move r0, so it goes into the main loop
> > invalidating the same cache line again. If it was written by something
> > else, the information would be lost.
>
> You can't make that a requirement. People have shared stuff across a
> cache line for years in Linux, and people have brought it up and tried
> to fix it, but there's much resistance against it. In particular is
> SCSI, which submits the sense buffer as part of a larger structure (the
> host.) SCSI sort-of guarantees that the surrounding struct members
> won't be touched, but their data has to be preserved.
Let's hope that CWG stays small enough on real hardware (as the
architecture specifies it to max 2K).
> In any case, remember that there are strict rules about ownership of the
> DMA memory vs calls to the DMA API. It is invalid to call the DMA
> streaming API functions while a DMA transfer is active.
Yes, I was referring to non-DMA buffer area in the same cache line being
touched during a DMA transfer.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "Jon Medhurst (Tixy)" <tixy@linaro.org>,
Liviu Dudau <Liviu.Dudau@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: Bug(?) in patch "arm64: Implement coherent DMA API based on swiotlb" (was Re: [GIT PULL] arm64 patches for 3.15)
Date: Wed, 2 Apr 2014 12:13:26 +0100 [thread overview]
Message-ID: <20140402111326.GC31892@arm.com> (raw)
In-Reply-To: <20140402094045.GH7528@n2100.arm.linux.org.uk>
On Wed, Apr 02, 2014 at 10:40:45AM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 02, 2014 at 10:20:32AM +0100, Catalin Marinas wrote:
> > You are right. I think having unaligned DMA buffers for inbound
> > transfers is pointless. We can avoid losing data written by another CPU
> > in the same cache line but, depending on the stage of the DMA transfer,
> > it can corrupt the DMA data.
> >
> > I wonder whether it's easier to define the cache_line_size() macro to
> > read CWG and assume that the DMA buffers are always aligned, ignoring
> > the invalidation of the unaligned boundaries. This wouldn't be much
> > different from your scenario where the shared cache line is written
> > (just less likely to trigger but still a bug, so I would rather notice
> > this early).
> >
> > The ARMv7 code has a similar issue, it performs clean&invalidate on the
> > unaligned start but it doesn't move r0, so it goes into the main loop
> > invalidating the same cache line again. If it was written by something
> > else, the information would be lost.
>
> You can't make that a requirement. People have shared stuff across a
> cache line for years in Linux, and people have brought it up and tried
> to fix it, but there's much resistance against it. In particular is
> SCSI, which submits the sense buffer as part of a larger structure (the
> host.) SCSI sort-of guarantees that the surrounding struct members
> won't be touched, but their data has to be preserved.
Let's hope that CWG stays small enough on real hardware (as the
architecture specifies it to max 2K).
> In any case, remember that there are strict rules about ownership of the
> DMA memory vs calls to the DMA API. It is invalid to call the DMA
> streaming API functions while a DMA transfer is active.
Yes, I was referring to non-DMA buffer area in the same cache line being
touched during a DMA transfer.
--
Catalin
next prev parent reply other threads:[~2014-04-02 11:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-31 17:52 [GIT PULL] arm64 patches for 3.15 Catalin Marinas
2014-03-31 17:52 ` Catalin Marinas
2014-04-01 16:10 ` Bug(?) in patch "arm64: Implement coherent DMA API based on swiotlb" (was Re: [GIT PULL] arm64 patches for 3.15) Jon Medhurst (Tixy)
2014-04-01 16:10 ` Jon Medhurst (Tixy)
2014-04-01 17:29 ` Catalin Marinas
2014-04-01 17:29 ` Catalin Marinas
2014-04-02 8:52 ` Jon Medhurst (Tixy)
2014-04-02 8:52 ` Jon Medhurst (Tixy)
2014-04-02 9:20 ` Catalin Marinas
2014-04-02 9:20 ` Catalin Marinas
2014-04-02 9:40 ` Russell King - ARM Linux
2014-04-02 9:40 ` Russell King - ARM Linux
2014-04-02 11:13 ` Catalin Marinas [this message]
2014-04-02 11:13 ` Catalin Marinas
2014-04-02 10:41 ` Bug(?) in patch "arm64: Implement coherent DMA API based on swiotlb" Jon Medhurst (Tixy)
2014-04-02 10:41 ` Jon Medhurst (Tixy)
2014-04-02 11:37 ` Catalin Marinas
2014-04-02 11:37 ` Catalin Marinas
2014-04-02 10:54 ` Bug(?) in patch "arm64: Implement coherent DMA API based on swiotlb" (was Re: [GIT PULL] arm64 patches for 3.15) Jon Medhurst (Tixy)
2014-04-02 10:54 ` Jon Medhurst (Tixy)
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=20140402111326.GC31892@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.