From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932082AbcAaMUB (ORCPT ); Sun, 31 Jan 2016 07:20:01 -0500 Received: from mga01.intel.com ([192.55.52.88]:52244 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757361AbcAaMT6 (ORCPT ); Sun, 31 Jan 2016 07:19:58 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,375,1449561600"; d="scan'208";a="644611913" From: Matthew Wilcox To: Andrew Morton Cc: Matthew Wilcox , linux-mm@kvack.org, linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, willy@linux.intel.com Subject: [PATCH 1/6] dax: Use vmf->gfp_mask Date: Sun, 31 Jan 2016 23:19:50 +1100 Message-Id: <1454242795-18038-2-git-send-email-matthew.r.wilcox@intel.com> X-Mailer: git-send-email 2.7.0.rc3 In-Reply-To: <1454242795-18038-1-git-send-email-matthew.r.wilcox@intel.com> References: <1454242795-18038-1-git-send-email-matthew.r.wilcox@intel.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We were assuming that it was OK to do a GFP_KERNEL allocation in page fault context. That appears to be largely true, but filesystems are permitted to override that in their setting of mapping->gfp_flags, which the VM then massages into vmf->gfp_flags. No practical difference for now, but there may come a day when we would have surprised a filesystem. Signed-off-by: Matthew Wilcox --- fs/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/dax.c b/fs/dax.c index 2f9bb89..11be8c7 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -292,7 +292,7 @@ static int dax_load_hole(struct address_space *mapping, struct page *page, struct inode *inode = mapping->host; if (!page) page = find_or_create_page(mapping, vmf->pgoff, - GFP_KERNEL | __GFP_ZERO); + vmf->gfp_mask | __GFP_ZERO); if (!page) return VM_FAULT_OOM; /* Recheck i_size under page lock to avoid truncate race */ -- 2.7.0.rc3