From patchwork Thu Mar 10 23:55:29 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Wilcox, Matthew R" X-Patchwork-Id: 8560521 Return-Path: X-Original-To: patchwork-linux-nvdimm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 552C9C0555 for ; Thu, 10 Mar 2016 23:55:47 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 505CE203A1 for ; Thu, 10 Mar 2016 23:55:46 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4E85420377 for ; Thu, 10 Mar 2016 23:55:45 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id C9B961A1F89; Thu, 10 Mar 2016 15:55:56 -0800 (PST) X-Original-To: linux-nvdimm@lists.01.org Delivered-To: linux-nvdimm@lists.01.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ml01.01.org (Postfix) with ESMTP id A72A11A1EF8 for ; Thu, 10 Mar 2016 15:55:55 -0800 (PST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 10 Mar 2016 15:55:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,317,1455004800"; d="scan'208";a="762002108" Received: from jduan1-mobl2.amr.corp.intel.com (HELO thog.int.wil.cx) ([10.252.134.213]) by orsmga003.jf.intel.com with SMTP; 10 Mar 2016 15:55:39 -0800 Received: by thog.int.wil.cx (Postfix, from userid 1000) id 524A05FBAA; Thu, 10 Mar 2016 18:55:36 -0500 (EST) From: Matthew Wilcox To: Andrew Morton 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> Cc: linux-nvdimm@lists.01.org, x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Matthew Wilcox , linux-fsdevel@vger.kernel.org X-BeenThere: linux-nvdimm@lists.01.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Linux-nvdimm developer list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 */