[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1106012043080.3078@ionos>
Date: Wed, 1 Jun 2011 20:55:58 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Russell King - ARM Linux <linux@....linux.org.uk>
cc: David Rientjes <rientjes@...gle.com>,
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, Russell King - ARM Linux wrote:
> On Wed, Jun 01, 2011 at 10:23:15AM -0700, David Rientjes wrote:
> > On Wed, 1 Jun 2011, Dmitry Eremin-Solenikov wrote:
> >
> > > I've hit this with IrDA driver on PXA. Also I've seen the report regarding
> > > other ARM platform (ep-something). Thus I've included Russell in the cc.
> > >
> >
> > So you want to continue to allow the page allocator to return pages from
> > anywhere, even when GFP_DMA is specified, just as though it was lowmem?
>
> No. What *everyone* is asking for is to allow the situation which has
> persisted thus far to continue for ONE MORE RELEASE but with a WARNING
> so that these problems can be found without causing REGRESSIONS.
>
> 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.
So making it a warning for this release and then break stuff which has
not been fixed is a sensible request and the only sensible approach.
If you think that you need to force that behaviour change now, then
you better go and audit _ALL_ GFP_DMA users yourself for correctness
and fix them case by case either by replacing the GFP_DMA flag or by
selecting ZONE_DMA with a proper changelog for every instance.
It's not up to your total ignorance of reality to break stuff at will
and then paper over the problems you caused by selecting ZONE_DMA
which will keep the abusers around forever.
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