Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 26 Apr 2019 17:37:37 +0200
From:   Andrew Lunn <andrew@lunn.ch>
To:     Robin Murphy <robin.murphy@arm.com>
Cc:     Esben Haabendal <esben@geanix.com>, netdev@vger.kernel.org,
        YueHaibing <yuehaibing@huawei.com>,
        Michal Simek <michal.simek@xilinx.com>,
        linux-kernel@vger.kernel.org, Yang Wei <yang.wei9@zte.com.cn>,
        Luis Chamberlain <mcgrof@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 08/12] net: ll_temac: Fix iommu/swiotlb leak
Message-ID: <20190426153737.GC4041@lunn.ch>
References: <20190426073231.4008-1-esben@geanix.com>
 <20190426073231.4008-9-esben@geanix.com>
 <20190426142103.GI14432@lunn.ch>
 <0aab6152-82c6-b53f-6b9b-0905995de43a@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0aab6152-82c6-b53f-6b9b-0905995de43a@arm.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Apr 26, 2019 at 03:43:20PM +0100, Robin Murphy wrote:
> On 26/04/2019 15:21, Andrew Lunn wrote:
> >On Fri, Apr 26, 2019 at 09:32:27AM +0200, Esben Haabendal wrote:
> >>Unmap the actual buffer length, not the amount of data received.
> >
> >Hi Esben
> >
> >The patch Subject does not seem to match the content?
> >
> >Also, there can be performance advantages of just unmapping the
> >received length. The unmap operation does a cache invalidate, which
> >can be expensive. Consider the effort of unmapping a 64 byte ACK vs 9K
> >jumbo frame?
> 
> If the size passed to dma_unmap_*() is not the same as was passed to the
> corresponding dma_map_*(), that is fundamentally incorrect use of the API
> and may lead to warnings, resource exhaustion, or possibly even corruption
> and crashes for some DMA API implementations.
> 
> If there's a case where you just need to look at a small part of the buffer
> right now, but can unmap the whole thing properly later. then
> dma_sync_single_*() does allow operating on partial buffers. Even better, if
> you're able to recycle buffers in your Rx pool you could potentially replace
> the unmap/map dance altogether with some careful use of sync_single.

Hi Robin

Thanks for the info.

I went back to the driver i was thinking of, and it is using
dma_sync_single_range_for_cpu() for just the received packet length.

Sorry for the mixup.

      Andrew