On Wed, 1 Jun 2011, David Rientjes wrote: > On Wed, 1 Jun 2011, Thomas Gleixner wrote: > > > > 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. > 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. > 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. Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>