From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id 59C7A6B0069 for ; Thu, 6 Oct 2016 12:55:29 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id n202so9386724oig.2 for ; Thu, 06 Oct 2016 09:55:29 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com. [2607:f8b0:4003:c06::231]) by mx.google.com with ESMTPS id 65si14347829oih.11.2016.10.06.09.55.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Oct 2016 09:55:28 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id m72so28300681oik.3 for ; Thu, 06 Oct 2016 09:55:28 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20161006153443.GT1041@n2100.armlinux.org.uk> References: <20161006153443.GT1041@n2100.armlinux.org.uk> From: Dan Williams Date: Thu, 6 Oct 2016 09:55:27 -0700 Message-ID: Subject: Re: DMA-API: cpu touching an active dma mapped cacheline Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Russell King - ARM Linux Cc: "linux-kernel@vger.kernel.org" , Linux MM , Andrew Morton , Linus Torvalds On Thu, Oct 6, 2016 at 8:34 AM, Russell King - ARM Linux 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: email@kvack.org