Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759460Ab1FATJV (ORCPT ); Wed, 1 Jun 2011 15:09:21 -0400 Received: from smtp-out.google.com ([74.125.121.67]:17216 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759443Ab1FATJT (ORCPT ); Wed, 1 Jun 2011 15:09:19 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; b=Oszl/WuYLI82CBSlaJWaVrtlvQb0wI0oqh0gam7/btnH4NeaM9TDsJn9hRkjd8VDe1 pyVwn1EFOjvRoeh3r6tA== Date: Wed, 1 Jun 2011 12:09:12 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Thomas Gleixner cc: Russell King - ARM Linux , Dmitry Eremin-Solenikov , KOSAKI Motohiro , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman , KAMEZAWA Hiroyuki , Rik van Riel , Andrew Morton Subject: Re: [PATCH] Make GFP_DMA allocations w/o ZONE_DMA emit a warning instead of failing In-Reply-To: Message-ID: References: <1306922672-9012-1-git-send-email-dbaryshkov@gmail.com> <20110601181918.GO3660@n2100.arm.linux.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 986 Lines: 26 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? 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 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/