On Tue, Jun 11, 2019 at 10:58:25AM -0700, Florian Fainelli wrote: > With a specifically contrived memory layout where there is no physical > memory available to the kernel below the 4GB boundary, we will fail to > perform the initial swiotlb_init() call and set no_iotlb_memory to true. > > There are drivers out there that call into swiotlb_nr_tbl() to determine > whether they can use the SWIOTLB. With the right DMA_BIT_MASK() value > for these drivers (say 64-bit), they won't ever need to hit > swiotlb_tbl_map_single() so this can go unoticed and we would be > possibly lying about those drivers. > > Signed-off-by: Florian Fainelli <f.faine...@gmail.com> > --- > kernel/dma/swiotlb.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c > index b2b5c5df273c..e906ef2e6315 100644 > --- a/kernel/dma/swiotlb.c > +++ b/kernel/dma/swiotlb.c > @@ -129,15 +129,17 @@ setup_io_tlb_npages(char *str) > } > early_param("swiotlb", setup_io_tlb_npages); > > +static bool no_iotlb_memory; > + > unsigned long swiotlb_nr_tbl(void) > { > - return io_tlb_nslabs; > + return unlikely(no_iotlb_memory) ? 0 : io_tlb_nslabs; > } > EXPORT_SYMBOL_GPL(swiotlb_nr_tbl); > > unsigned int swiotlb_max_segment(void) > { > - return max_segment; > + return unlikely(no_iotlb_memory) ? 0 : max_segment;
I wouldn't bother with the unlikely here as anythign querying swiotlb details should pretty much be a slow path already. Otherwise looks good: Reviewed-by: Christoph Hellwig <h...@lst.de> _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu