Re: [PATCH 2/5] xfs: use xfs_ilock_map_shared in xfs_qm_dqtobp

From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/5] xfs: use xfs_ilock_map_shared in xfs_qm_dqtobp
Date: Fri, 6 Dec 2013 07:41:08 +1100	[thread overview]
Message-ID: <20131205204108.GB29897@dastard> (raw)
In-Reply-To: <20131205155951.330689967@bombadil.infradead.org>

On Thu, Dec 05, 2013 at 07:58:32AM -0800, Christoph Hellwig wrote:
> We might not have read in the extent list at this point, so make sure we
> take the ilock exclusively if we have to do so.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Index: xfs/fs/xfs/xfs_dquot.c
> ===================================================================
> --- xfs.orig/fs/xfs/xfs_dquot.c	2013-11-18 14:39:01.955589999 +0100
> +++ xfs/fs/xfs/xfs_dquot.c	2013-12-05 11:42:34.759679600 +0100
> @@ -469,16 +469,17 @@ xfs_qm_dqtobp(
>  	struct xfs_mount	*mp = dqp->q_mount;
>  	xfs_dqid_t		id = be32_to_cpu(dqp->q_core.d_id);
>  	struct xfs_trans	*tp = (tpp ? *tpp : NULL);
> +	uint			lock_mode;
>  
>  	dqp->q_fileoffset = (xfs_fileoff_t)id / mp->m_quotainfo->qi_dqperchunk;
>  
> -	xfs_ilock(quotip, XFS_ILOCK_SHARED);
> +	lock_mode = xfs_ilock_map_shared(quotip);
>  	if (!xfs_this_quota_on(dqp->q_mount, dqp->dq_flags)) {
>  		/*
>  		 * Return if this type of quotas is turned off while we
>  		 * didn't have the quota inode lock.
>  		 */
> -		xfs_iunlock(quotip, XFS_ILOCK_SHARED);
> +		xfs_iunlock_map_shared(quotip, lock_mode);
>  		return ESRCH;
>  	}
>  
> @@ -488,7 +489,7 @@ xfs_qm_dqtobp(
>  	error = xfs_bmapi_read(quotip, dqp->q_fileoffset,
>  			       XFS_DQUOT_CLUSTER_SIZE_FSB, &map, &nmaps, 0);
>  
> -	xfs_iunlock(quotip, XFS_ILOCK_SHARED);
> +	xfs_iunlock_map_shared(quotip, lock_mode);
>  	if (error)
>  		return error;

Looks ok, so consider it:

Reviewed-by: Dave Chinner <dchinner@redhat.com>

However, it raises a bigger question about dquot allocation sanity
to me: what makes the map returned valid after we've unlocked the
extent list?

We then use it to determine whether to allocate a
dquot or not, and xfs_qm_dqalloc() then does this after calling
xfs_bmapi_write():

	ASSERT((map.br_startblock != DELAYSTARTBLOCK) &&
	       (map.br_startblock != HOLESTARTBLOCK));

What's to prevent someone coming in between the xfs_bmapi_read()
and *write() calls and allocating a different dquot in the same
cluster and therefore beating the first thread to the allocation?

This read/write race exists elsewhere - e.g. xfs_iomap_write_allocate
documents it for the data path - and it has to be specifically
handled to prevent corruption.....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs