[PATCH 3/4 v2] xfs: dynamically switch modes when XFS_DIFLAG2_DAX is set/cleared
Ross Zwisler
ross.zwisler at linux.intel.com
Wed Feb 17 14:57:27 CST 2016
On Wed, Feb 17, 2016 at 06:31:21PM +1100, Dave Chinner wrote:
> xfs: dynamically switch modes when XFS_DIFLAG2_DAX is set/cleared
>
> From: Dave Chinner <dchinner at redhat.com>
>
> When we set or clear the XFS_DIFLAG2_DAX flag, we should also
> set/clear the S_DAX flag in the VFS inode. To do this, we need to
> ensure that we first flush and remove any cached entries in the
> radix tree to ensure the correct data access method is used when we
> next try to read or write data. We ahve to be especially careful
> here to lock out page faults so they don't race with the flush and
> invalidation before we change the access mode.
>
> Signed-off-by: Dave Chinner <dchinner at redhat.com>
> ---
> Version 2:
> - fix lock leak in xfs_ioctl_setattr where dquot allocation could
> fail after we'd locked the inode iolock and mmaplock but we didn't
> unlock them on error.
>
> fs/xfs/xfs_ioctl.c | 105 ++++++++++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 92 insertions(+), 13 deletions(-)
<>
> @@ -1072,19 +1115,27 @@ xfs_ioctl_setattr_xflags(
> * have permission to do so. On success, return a clean transaction and the
> * inode locked exclusively ready for further operation specific checks. On
> * failure, return an error without modifying or locking the inode.
> + *
> + * The inode might already be IO locked on call. If this is the case, it is
> + * indicated in @join_flags and we take full responsibility for ensuring they
> + * are unlocked from now on. Hence if we have an error here, we still have to
> + * unlock them. Otherwise, once they are joined to the transaction, they will
> + * be unlocked on commit/cancel.
> */
> static struct xfs_trans *
> xfs_ioctl_setattr_get_trans(
> - struct xs_inode *ip)
> + struct xfs_inode *ip,
Interesting - it looks like 'xfs_inode' got corrupted to 'xs_inode'?
After fixing this the series passed all my testing.
Tested-by: Ross Zwisler <ross.zwisler at linux.intel.com>
More information about the xfs
mailing list