linux-kernel - Re: [PATCH 0/3] fix GART to respect device's dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080918182029.GO25711@one.firstfloor.org>
Date:	Thu, 18 Sep 2008 20:20:29 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	andi@...stfloor.org, mingo@...e.hu, joerg.roedel@....com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] fix GART to respect device's dma_mask about virtual mappings

> The falling back mechanism was moved to pci-nommu from the common code
> since it doesn't work for other IOMMUs that always need virtual

There's no fallback for _map_sg/_map_single. All the fallback to GFP
only works for coherent allocations, but not for streaming mappings.

To make this "fully robust" for masks < 32bit you would need to implement 
a new swiotlb that uses GFP_DMA allocations as fallback (or use the DMA 
allocator's swiotlb which can actually handle this)

So you're right now basically checking for something that you cannot
fix. And also you try to check for (but not handle) something that even 
32bit x86 doesn't handle. So if some driver relied on you checking
for it on 64bit it wouldn't work on 32bit x86 which would be a bad 
thing.

> mappings. Calgary needs this dma_mask trick too but I guess that it's
> unlikely that the IBM servers with Calgary have weird hardware.

On a full IOMMU like calgary it's easier to do because you don't
 need to deal with GFP_DMA at least. But as you say it's unlikely
to be worth the effort on these systems.

Also the earlier problem that it wouldn't work on 32bit x86 and other
systems would make it also not too useful. Having drivers that only
work on Calgary wouldn't be a good thing.

-Andi

-- 
ak@...ux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/