[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1106012134120.3078@ionos>
Date: Wed, 1 Jun 2011 21:46:37 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: David Rientjes <rientjes@...gle.com>
cc: Russell King - ARM Linux <linux@....linux.org.uk>,
Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Mel Gorman <mel@....ul.ie>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Rik van Riel <riel@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] Make GFP_DMA allocations w/o ZONE_DMA emit a warning
instead of failing
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@...%@...ng 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*(&!@...g not break it.
Thanks,
tglx
--
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/
Powered by blists - more mailing lists