linux-kernel - Re: DMA APIs gumble grumble

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: <1163127327.4982.79.camel@localhost.localdomain>
Date:	Fri, 10 Nov 2006 13:55:27 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	David Miller <davem@...emloft.net>
Cc:	linux-input@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org,
	paulus@...ba.org, anton@...ba.org, greg@...ah.com
Subject: Re: DMA APIs gumble grumble


> pci_alloc_consistent() is not allowed from atomic contexts.

Yes, but some drivers did it anyway, though I can't remember under which
circumstances (IDE probe possibly ? It's a usual culprit for that sort
of thing). This is why most implementations use GFP_ATOMIC (including
sparc64 :-)

> > I'm splitting it into a pci_do_alloc_consistent that takes a gfp arg,
> > and a pair of pci_alloc_consistent & dma_alloc_consistent wrappers.
> > 
> > Do you think I should have the former pass GFP_KERNEL like the current
> > implementation does or switch it to GFP_ATOMIC like everybody does ? In
> > this case, should I also change the kmalloc done in there to allocate a
> > struct resource to use the gfp argument ? (It's currently doing
> > GFP_KERNEL).
> 
> pci_alloc_consistent() really cannot be allowed to use GFP_ATOMIC.

Oh well, I have no problem with leaving sparc32 do GFP_KERNEL indeed, I
can't remember for sure the reason why we have most architectures do
GFP_ATOMIC, but it probably never hit sparc32.

Ben.


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