(2011/06/02 4:46), Thomas Gleixner wrote:

On Wed, 1 Jun 2011, David Rientjes wrote:

quoted

On Wed, 1 Jun 2011, Thomas Gleixner wrote:

quoted

quoted

That is NOT an unreasonable request, but it seems that its far too much
to ask of you.

Full ack.

David,

stop that nonsense already. You changed the behaviour and broke stuff
which was working fine before for whatever reason. That behaviour was
in the kernel for ages and we tolerated the abuse.

Did I nack this patch and not realize it?

No, you did not realize anything.
 

quoted

Does my patch fix the warning for pxaficp_ir that would still be emitted 
with this patch?  If the driver uses GFP_DMA and nobody from the arm side 

Your patch does not fix anything. It papers over the problem and
that's the f@&^%%@^#ing wrong approach.

And just to be clear. You CANNOT fix a warning. You can fix the code
which causes the warning, but that's not what your patch is
doing. Your patch HIDES the problem.

quoted

is prepared to remove it yet, then I'd suggest merging my patch until that 
can be determined.  Otherwise, you have no guarantees about where the 
memory is actually coming from.

Did you actually try to understand what I wrote? 

You decided that it's a BUG just because it should not be allowed. So
you changed the behaviour, which was perfectly fine before.

Now you try to paper over the problem by selecting ZONE_DMA and refuse
to give a grace period of _ONE_ kernel release.

IOW, you are preventing that the abusers of GFP_DMA are fixed
properly.

I can see that you neither have the bandwidth nor the knowledge to
analyse each user of GFP_DMA. And that should tell you something.

If you cannot fix it yourself, then f*(&!@$#ng not break it.

Then, the revert patch is here.