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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ