Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933281AbcCKAB1 (ORCPT ); Thu, 10 Mar 2016 19:01:27 -0500 Received: from mga02.intel.com ([134.134.136.20]:61724 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932939AbcCJXzo (ORCPT ); Thu, 10 Mar 2016 18:55:44 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,317,1455004800"; d="scan'208";a="762002108" 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, x86@kernel.org, willy@linux.intel.com Subject: [PATCH v5 12/14] dax: Use vmf->gfp_mask Date: Thu, 10 Mar 2016 18:55:29 -0500 Message-Id: <1457654131-4562-13-git-send-email-matthew.r.wilcox@intel.com> X-Mailer: git-send-email 2.7.0 In-Reply-To: <1457654131-4562-1-git-send-email-matthew.r.wilcox@intel.com> References: <1457654131-4562-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 Content-Length: 1011 Lines: 27 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 Reviewed-by: Ross Zwisler --- fs/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/dax.c b/fs/dax.c index 35f0709..50636e1 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -316,7 +316,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