linux-kernel - Re: [PATCH] swiotlb: fix dma_alloc_coherent allocation failures with swiotlb

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: <20080904080528.GZ18288@one.firstfloor.org>
Date:	Thu, 4 Sep 2008 10:05:28 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	andi@...stfloor.org, joerg.roedel@....com, mingo@...hat.com,
	tglx@...utronix.de, hpa@...or.com, linux-kernel@...r.kernel.org,
	iommu@...ts.linux-foundation.org, kamezawa.hiroyu@...fujitsu.com,
	tony.luck@...el.com
Subject: Re: [PATCH] swiotlb: fix dma_alloc_coherent allocation failures with swiotlb

On Thu, Sep 04, 2008 at 04:58:37PM +0900, FUJITA Tomonori wrote:
> On Thu, 4 Sep 2008 09:44:41 +0200
> Andi Kleen <andi@...stfloor.org> wrote:
> 
> > On Thu, Sep 04, 2008 at 01:11:47PM +0900, FUJITA Tomonori wrote:
> > > On Thu, 04 Sep 2008 00:09:51 +0200
> > > Andi Kleen <andi@...stfloor.org> wrote:
> > > 
> > > > Joerg Roedel <joerg.roedel@....com> writes:
> > > > 
> > > > > The SWIOTLB version of dma_alloc_coherent allocates all memory with
> > > > > GFP_DMA unconditionally. This leads sometimes unnecessary to allocation
> > > > > failures. This patch makes the allocation strategy to use the DMA32 zone
> > > > > first if this is possible. The changes are boot tested on AMD64 and
> > > > > compile tested for i386 and IA64.
> > > > 
> > > > The high level dma_alloc_coherent() does that anyways.
> > > 
> > > The high level dma_alloc_coherent means the tricks in
> > > arch/x86/pci-dma.c? If so, all the tricks has gone in tip/master.
> > 
> > Seems wrong -- that is something that is needed by multiple
> > IOMMUs. Pretty much all which work with real memory instead
> > of virtual mappings.
> 
> Not all the IOMMUs need the old tricks used in arch/x86/pci-dma.c.

That is what I meant with "with real memory"

But actually even for real IOMMus it can make sense to maintain
some memory for bypass.

Also there's usually the problem that not all busses are translated,
e.g. Calgary used to do that so for e.g. dev == NULL allocations you had
to use  these fallback algorithms anyways.

Clearly copying the fallback logic into lots of low level IOMMUs instead
of having it in one place is a big step backwards.

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