[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120614021547.GC7339@dastard>
Date: Thu, 14 Jun 2012 12:15:47 +1000
From: Dave Chinner <david@...morbit.com>
To: Fengguang Wu <fengguang.wu@...el.com>
Cc: Dave Chinner <dchinner@...hat.com>,
Christoph Hellwig <hch@...radead.org>,
linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
xfs@....sgi.com
Subject: Re: [PATCH] mm: add gfp_mask parameter to vm_map_ram()
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@...morbit.com
--
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