linux-kernel - Re: IrDA driver fails on PXA255

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:	Tue, 31 May 2011 15:11:40 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Eric Miao <eric.y.miao@...il.com>,
	Samuel Ortiz <samuel@...tiz.org>
Subject: Re: IrDA driver fails on PXA255

On Tue, 31 May 2011, Russell King - ARM Linux wrote:

> > The problem certainly isn't being ignored in this thread, or in the patch 
> > that I sent to fix Dmitry's issue by default, so that doesn't seem to be 
> > the case.  What would be ignored, though, is if it just emitted a 
> > WARN_ON() without failing the allocation so everything works perfectly.
> 
> Sorry, you did not send a patch to fix it.  You sent a *bodge* to enable
> the DMA zone.  As long as you insist that's a valid fix, you're going
> to carry zero credibility with me.
> 
> The fact is that this driver should not be using GFP_DMA to allocate
> things which aren't even DMA buffers, and its use of GFP_DMA should be
> removed.  But rather than look at that and work it out, and then produce
> a patch to sort that out, the only thing you can do is come up with
> bodge to enable the DMA zone, and continue to insist that's the right
> solution.
> 

I'm not going to hack on an arm driver when I have no idea what its DMA 
requirements are and have no ability to test the change.  I'll rely on the 
authors or maintainers of that driver to figure it out.  In the meantime, 
I suggested enabling CONFIG_ZONE_DMA for that driver because, in its 
current state, it is using GFP_DMA and you haven't provided a single 
reason why enabling CONFIG_ZONE_DMA is going to cause an issue.

In other words, I cannot do your work for you: if GFP_DMA can be removed 
from that driver, great, in the meantime it should enable CONFIG_ZONE_DMA 
to fix the invalid configurations that are currently allowed.  It's 
simple: if you're going to pass GFP_DMA to the page allocator, you need to 
require CONFIG_ZONE_DMA for it to be useful.  Anything else is an invalid 
configuration and is error prone.

> Your whinge that we should re-enable the DMA zone which has been
> disabled for quite a long time now to work around this new restriction
> is extremely idiotic.
> 

The restriction isn't new: GFP_DMA only makes sense with CONFIG_ZONE_DMA.  
The fact that the page allocator completely ignored GFP_DMA in the past 
for CONFIG_ZONE_DMA=n doesn't change that.  That's obviously error prone 
since it will return memory from anywhere simply because of the fact that 
it is an invalid configuration.
--
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/