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]

Date:	Fri, 19 Sep 2008 07:15:59 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	andi@...stfloor.org
Cc:	fujita.tomonori@....ntt.co.jp, 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

On Thu, 18 Sep 2008 20:20:29 +0200
Andi Kleen <andi@...stfloor.org> wrote:

> > 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.

Yeah, so the falling back mechanism was moved to pci-nommu's
alloc_coherent.


> 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)

Do you mean if GART's alloc_coherent can't find a virtual address that
a device can access to, it should try GFP_DMA allocations as fallback?

GART could but why GART should do? If full IOMMUs' alloc_coherent
can't find a virtual address that a device can access to, it's
failure. No fallback is for them. Why can't GART use the same logic?
Yeah, GART is not a full IOMMU, so it can have a fallback for this
case. But why can't GART work in the same way other IOMMUs?


> 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.

What does '32bit x86 doesn't handle' mean? pci-nommu's alloc_coherent
can handle < 32bit bit mask in the fallback path.

Or you are talking about '_map_sg/_map_single'? If so, as we
discussed, < 32bit bit mask can be handled in else where. The patch
just tries to return an address that such tricks are not necessary
with.
--
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/