linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: DMA-API: cpu touching an active dma mapped cacheline
Date: Thu, 6 Oct 2016 09:55:27 -0700	[thread overview]
Message-ID: <CAPcyv4j8fWqwAaX5oCdg5atc+vmp57HoAGT6AfBFwaCiv0RbAQ@mail.gmail.com> (raw)
In-Reply-To: <20161006153443.GT1041@n2100.armlinux.org.uk>

On Thu, Oct 6, 2016 at 8:34 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> Hi,
>
> With DMA API debugging enabled, I'm seeing this splat from it, which to
> me looks like the DMA API debugging is getting too eager for it's own
> good.
>
> The fact of the matter is that the VM passes block devices pages to be
> written out to disk which are page cache pages, which may be looked up
> and written to by write() syscalls and via mmap() mappings.  For example,
> take the case of a writable shared mapping of a page backed by a file on
> a disk - the VM will periodically notice that the page has been dirtied,
> and schedule a writeout to disk.  The disk driver has no idea that the
> page is still mapped - and arguably it doesn't matter.
>
> So, IMHO this whole "the CPU is touching a DMA mapped buffer" is quite
> bogus given our VM behaviour: we have never guaranteed exclusive access
> to DMA buffers.
>
> I don't see any maintainer listed for lib/dma-debug.c, but I see the
> debug_dma_assert_idle() stuff was introduced by Dan via akpm in 2014.

Hmm, there are benign cases where this happens, but there's also one's
that lead to data corruption as was the case with the NET_DMA receive
offload.  Perhaps this change is enough to distinguish between the two
cases:

diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index fcfa1939ac41..dd18235097d0 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -597,7 +597,7 @@ void debug_dma_assert_idle(struct page *page)
        }
        spin_unlock_irqrestore(&radix_lock, flags);

-       if (!entry)
+       if (!entry || entry->direction != DMA_FROM_DEVICE)
                return;

        cln = to_cacheline_number(entry);

...because the problem in the NET_DMA case was that the engine was
writing to page that the process no longer cared about because the cpu
had written to it causing a cow copy to be established.  In the disk
DMA case its fine if the DMA is acting on stale results in a
DMA_TO_DEVICE operation.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-10-06 16:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06 15:34 Russell King - ARM Linux
2016-10-06 16:55 ` Dan Williams [this message]
2016-10-06 17:57   ` Russell King - ARM Linux

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=CAPcyv4j8fWqwAaX5oCdg5atc+vmp57HoAGT6AfBFwaCiv0RbAQ@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --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