Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1322631
| From | Matthew Wilcox <matthew.r.wilcox@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | [PATCH 1/6] dax: Use vmf->gfp_mask |
| Date | 2016-01-31 13:30 +0100 |
| Message-ID | <qWZiG-3dk-21@gated-at.bofh.it> (permalink) |
| References | <qWZiG-3dk-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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 <matthew.r.wilcox@intel.com> --- 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
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
[PATCH 1/6] dax: Use vmf->gfp_mask Matthew Wilcox <matthew.r.wilcox@intel.com> - 2016-01-31 13:30 +0100
csiph-web