[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190611184834.GD12859@char.us.oracle.com>
Date: Tue, 11 Jun 2019 14:48:34 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: linux-kernel@...r.kernel.org,
bcm-kernel-feedback-list@...adcom.com,
Christoph Hellwig <hch@....de>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
"David S. Miller" <davem@...emloft.net>,
"open list:DMA MAPPING HELPERS" <iommu@...ts.linux-foundation.org>,
"open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>
Subject: Re: [PATCH 0/2] swiotlb: Cleanup and consistency fix
On Tue, Jun 11, 2019 at 10:58:23AM -0700, Florian Fainelli wrote:
> Hi Christoph,
I pulled the patches in my tree.
>
> Still with my contrived memory layout where there is no physical memory
> the kernel can use below 4GB, it was possible to fail swiotlb_init(),
> but still not hit swiotlb_map_single() since all peripherals have a
> DMA_BIT_MASK() that is within the remaining addressable physical memory.
>
> The second path could be backported to stable, but for the same reasons
> as the one we had just discussed before, this requires a very contrived
> test case that is not necessarily realistic or would warrant a stable
> backport IMHO.
>
> Thanks!
>
> Florian Fainelli (2):
> swiotlb: Group identical cleanup in swiotlb_cleanup()
> swiotlb: Return consistent SWIOTLB segments/nr_tbl
>
> kernel/dma/swiotlb.c | 26 ++++++++++++++------------
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> --
> 2.17.1
>
Powered by blists - more mailing lists