Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753835AbcJMKkS (ORCPT ); Thu, 13 Oct 2016 06:40:18 -0400 Received: from smtp-out4.electric.net ([192.162.216.193]:62412 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753567AbcJMKkG (ORCPT ); Thu, 13 Oct 2016 06:40:06 -0400 From: David Laight To: "'Alexander Duyck'" , Nikita Yushchenko CC: Eric Dumazet , David Miller , Jeff Kirsher , intel-wired-lan , Netdev , "linux-kernel@vger.kernel.org" , Chris Healy Subject: RE: igb driver can cause cache invalidation of non-owned memory? Thread-Topic: igb driver can cause cache invalidation of non-owned memory? Thread-Index: AQHSJJ3zk6gikE37GUiDR2euMAz4tKCk9wtQgAAtD3yAAQs88A== Date: Thu, 13 Oct 2016 10:39:52 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB01E773C@AcuExch.aculab.com> References: <0b57cbe2-84f7-6c0a-904a-d166571234b5@cogentembedded.com> <20161010.050125.1981283393312167625.davem@davemloft.net> <10474d19-df1a-3b09-917e-70659be3a56c@cogentembedded.com> <20161010.075731.2449861168238706.davem@davemloft.net> <19aebfc3-5f1a-9206-4493-2255af7269f9@cogentembedded.com> <063D6719AE5E284EB5DD2968C1650D6DB01E6F0F@AcuExch.aculab.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u9DAeLDi017602 Content-Length: 1764 Lines: 39 From: Alexander Duyck > Sent: 12 October 2016 19:30 > On Wed, Oct 12, 2016 at 11:12 AM, Nikita Yushchenko > wrote: > >> It would make more sense to update the DMA API for > >> __dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if > >> the direction is DMA_FROM_DEVICE. > > > > No, in generic case it's unsafe. > > > > If CPU issued a write to a location, and sometime later that location is > > used as DMA buffer, there is danger that write is still in cache only, > > and writeback is pending. Later this writeback can overwrite data > > written to memory via DMA, causing corruption. > > Okay so if I understand it correctly then the invalidation in > sync_for_device is to force any writes to be flushed out, and the > invalidation in sync_for_cpu is to flush out any speculative reads. > So without speculative reads then the sync_for_cpu portion is not > needed. You might want to determine if the core you are using > supports the speculative reads, if not you might be able to get away > without having to do the sync_for_cpu at all. For reads the sync_for_device invalidates (ie discards the contents of) the cache lines to ensure the cpu won't write back dirty lines. The sync_for_cpu invalidates the cache to ensure the cpu actually reads from memory. For writes you need to flush (write back) cache lines prior to the DMA. I don't think anything is needed when the transfer finishes. If headers/trailers might be added the sync_for_device must cover the entire area the frame will be written to. Clearly the sync_for_cpu need only cover the valid frame data. I suspect you can safely skip the sync_for_device in the 'copybreak' path but not if the frame is passed up the protocol stack. David