From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id q5E2Fq37208975 for ; Wed, 13 Jun 2012 21:15:53 -0500 Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id mLcy8QmYYglfGjtL for ; Wed, 13 Jun 2012 19:15:51 -0700 (PDT) Date: Thu, 14 Jun 2012 12:15:47 +1000 From: Dave Chinner Subject: Re: [PATCH] mm: add gfp_mask parameter to vm_map_ram() Message-ID: <20120614021547.GC7339@dastard> References: <20120612012134.GA7706@localhost> <20120613123932.GA1445@localhost> <20120614012026.GL3019@devil.redhat.com> <20120614014902.GB7289@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120614014902.GB7289@localhost> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Fengguang Wu Cc: Linux Memory Management List , LKML , xfs@oss.sgi.com, Christoph Hellwig , Tejun Heo , Dave Chinner , linux-fsdevel@vger.kernel.org, Andrew Morton On Thu, Jun 14, 2012 at 09:49:02AM +0800, Fengguang Wu wrote: > On Thu, Jun 14, 2012 at 11:20:26AM +1000, Dave Chinner wrote: > > > > Bug in vm_map_ram - it does an unconditional GFP_KERNEL allocation > > here, and we are in a GFP_NOFS context. We can't pass a gfp_mask to > > vm_map_ram(), so until vm_map_ram() grows that we can't fix it... > > This trivial patch should fix it. > > The only behavior change is the XFS part: > > @@ -406,7 +406,7 @@ _xfs_buf_map_pages( > > do { > bp->b_addr = vm_map_ram(bp->b_pages, bp->b_page_count, > - -1, PAGE_KERNEL); > + -1, GFP_NOFS, PAGE_KERNEL); This function isn't always called in GFP_NOFS context - readahead uses different memory allocation semantics (no retry, no warn), so there are flags that tell it what to do. i.e. - -1, PAGE_KERNEL); + -1, xb_to_gfp(flags), PAGE_KERNEL); Otherwise looks fine to me... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH] mm: add gfp_mask parameter to vm_map_ram() Date: Thu, 14 Jun 2012 12:15:47 +1000 Message-ID: <20120614021547.GC7339@dastard> References: <20120612012134.GA7706@localhost> <20120613123932.GA1445@localhost> <20120614012026.GL3019@devil.redhat.com> <20120614014902.GB7289@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , Christoph Hellwig , linux-fsdevel@vger.kernel.org, LKML , Andrew Morton , Tejun Heo , Linux Memory Management List , xfs@oss.sgi.com To: Fengguang Wu Return-path: Content-Disposition: inline In-Reply-To: <20120614014902.GB7289@localhost> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jun 14, 2012 at 09:49:02AM +0800, Fengguang Wu wrote: > On Thu, Jun 14, 2012 at 11:20:26AM +1000, Dave Chinner wrote: > > > > Bug in vm_map_ram - it does an unconditional GFP_KERNEL allocation > > here, and we are in a GFP_NOFS context. We can't pass a gfp_mask to > > vm_map_ram(), so until vm_map_ram() grows that we can't fix it... > > This trivial patch should fix it. > > The only behavior change is the XFS part: > > @@ -406,7 +406,7 @@ _xfs_buf_map_pages( > > do { > bp->b_addr = vm_map_ram(bp->b_pages, bp->b_page_count, > - -1, PAGE_KERNEL); > + -1, GFP_NOFS, PAGE_KERNEL); This function isn't always called in GFP_NOFS context - readahead uses different memory allocation semantics (no retry, no warn), so there are flags that tell it what to do. i.e. - -1, PAGE_KERNEL); + -1, xb_to_gfp(flags), PAGE_KERNEL); Otherwise looks fine to me... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755202Ab2FNCPy (ORCPT ); Wed, 13 Jun 2012 22:15:54 -0400 Received: from ipmail05.adl6.internode.on.net ([150.101.137.143]:50706 "EHLO ipmail05.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753167Ab2FNCPw (ORCPT ); Wed, 13 Jun 2012 22:15:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0JABZI2U95LAcV/2dsb2JhbABFtAwEgTCBCIIYAQEFJxMcIxAIAxguFCUDIROICrpFFIscSYRoYAOVIIklhliCcg Date: Thu, 14 Jun 2012 12:15:47 +1000 From: Dave Chinner To: Fengguang Wu Cc: Dave Chinner , Christoph Hellwig , linux-fsdevel@vger.kernel.org, LKML , Andrew Morton , Tejun Heo , Linux Memory Management List , xfs@oss.sgi.com Subject: Re: [PATCH] mm: add gfp_mask parameter to vm_map_ram() Message-ID: <20120614021547.GC7339@dastard> References: <20120612012134.GA7706@localhost> <20120613123932.GA1445@localhost> <20120614012026.GL3019@devil.redhat.com> <20120614014902.GB7289@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120614014902.GB7289@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 14, 2012 at 09:49:02AM +0800, Fengguang Wu wrote: > On Thu, Jun 14, 2012 at 11:20:26AM +1000, Dave Chinner wrote: > > > > Bug in vm_map_ram - it does an unconditional GFP_KERNEL allocation > > here, and we are in a GFP_NOFS context. We can't pass a gfp_mask to > > vm_map_ram(), so until vm_map_ram() grows that we can't fix it... > > This trivial patch should fix it. > > The only behavior change is the XFS part: > > @@ -406,7 +406,7 @@ _xfs_buf_map_pages( > > do { > bp->b_addr = vm_map_ram(bp->b_pages, bp->b_page_count, > - -1, PAGE_KERNEL); > + -1, GFP_NOFS, PAGE_KERNEL); This function isn't always called in GFP_NOFS context - readahead uses different memory allocation semantics (no retry, no warn), so there are flags that tell it what to do. i.e. - -1, PAGE_KERNEL); + -1, xb_to_gfp(flags), PAGE_KERNEL); Otherwise looks fine to me... Cheers, Dave. -- Dave Chinner david@fromorbit.com