linux-kernel - Re: [PATCH] Make GFP_DMA allocations w/o ZONE

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: <4DF1C9DE.4070605@jp.fujitsu.com>
Date:	Fri, 10 Jun 2011 16:38:06 +0900
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	tglx@...utronix.de
CC:	rientjes@...gle.com, linux@....linux.org.uk, dbaryshkov@...il.com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, mel@....ul.ie,
	kamezawa.hiroyu@...fujitsu.com, riel@...hat.com,
	akpm@...ux-foundation.org, pavel@....cz
Subject: Re: [PATCH] Make GFP_DMA allocations w/o ZONE_DMA emit a warning
 instead of failing

(2011/06/02 4:46), Thomas Gleixner wrote:
> 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.


Then, the revert patch is here.




>From beaf8c4457fffeb3a4bfb3a5109fbcddcfc686cb Mon Sep 17 00:00:00 2001
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Date: Fri, 10 Jun 2011 15:27:06 +0900
Subject: [PATCH] Revert "mm: fail GFP_DMA allocations when ZONE_DMA is not configured"

Dmitry Eremin-Solenikov reported IrDA driver on PXA started to fail
after commit a197b59ae (mm: fail GFP_DMA allocations when ZONE_DMA
is not configured). Pavel Mechek mentioned it also broke zaurus.

Even though the concept of commit a197b59ae is correct. It's no worth
to break ARM. Thus this should be reverted until finished to audit
all GFP_DMA users.

This reverts commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac.

Reported-by: Dmitry Eremin-Solenikov <dbaryshkov@...il.com>
Reported-by: Pavel Machek <pavel@....cz>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc: David Rientjes <rientjes@...gle.com>
Cc: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Mel Gorman <mel@....ul.ie>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc: Rik van Riel <riel@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
---
 mm/page_alloc.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a4e1db3..4e8985a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2247,10 +2247,6 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,

 	if (should_fail_alloc_page(gfp_mask, order))
 		return NULL;
-#ifndef CONFIG_ZONE_DMA
-	if (WARN_ON_ONCE(gfp_mask & __GFP_DMA))
-		return NULL;
-#endif

 	/*
 	 * Check the zones suitable for the gfp_mask contain at least one
-- 
1.7.3.1






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