On Thu, Dec 15, 2016 at 04:40:41PM -0700, Dave Jiang wrote:
> The caller into dax needs to clear __GFP_FS mask bit since it's
> responsible for acquiring locks / transactions that blocks __GFP_FS
> allocation. The caller will restore the original mask when dax function
> returns.
What's the allocation problem you're working around here? Can you
please describe the call chain that is the problem?
> xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
>
> if (IS_DAX(inode)) {
> + gfp_t old_gfp = vmf->gfp_mask;
> +
> + vmf->gfp_mask &= ~__GFP_FS;
> ret = dax_iomap_fault(vma, vmf, &xfs_iomap_ops);
> + vmf->gfp_mask = old_gfp;
I really have to say that I hate code that clears and restores flags
without any explanation of why the code needs to play flag tricks. I
take one look at the XFS fault handling code and ask myself now "why
the hell do we need to clear those flags?" Especially as the other
paths into generic fault handlers /don't/ require us to do this.
What does DAX do that require us to treat memory allocation contexts
differently to the filemap_fault() path?
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>