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

Dave Chinner
2013-12-05T20:41:14Z

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