Re: [PATCH 3/5] xfs: use xfs_ilock_map_shared in xfs_qm_dqiterate

[Dave Chinner <david@xxxxxxxxxxxxx>]

On Thu, Dec 05, 2013 at 07:58:33AM -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@xxxxxx>
> 
> Index: xfs/fs/xfs/xfs_qm.c
> ===================================================================
> --- xfs.orig/fs/xfs/xfs_qm.c  2013-11-18 14:39:01.967589998 +0100
> +++ xfs/fs/xfs/xfs_qm.c       2013-12-05 12:32:36.623617997 +0100
> @@ -1193,16 +1193,18 @@ xfs_qm_dqiterate(
>       lblkno = 0;
>       maxlblkcnt = XFS_B_TO_FSB(mp, mp->m_super->s_maxbytes);
>       do {
> +             uint            lock_mode;
> +
>               nmaps = XFS_DQITER_MAP_SIZE;
>               /*
>                * We aren't changing the inode itself. Just changing
>                * some of its data. No new blocks are added here, and
>                * the inode is never added to the transaction.
>                */
> -             xfs_ilock(qip, XFS_ILOCK_SHARED);
> +             lock_mode = xfs_ilock_map_shared(qip);
>               error = xfs_bmapi_read(qip, lblkno, maxlblkcnt - lblkno,
>                                      map, &nmaps, 0);
> -             xfs_iunlock(qip, XFS_ILOCK_SHARED);
> +             xfs_iunlock_map_shared(qip, lock_mode);
>               if (error)
>                       break;

There's no bug here - this comes from quotacheck, which is
guaranteed to have exclusive access to the filesystem at this point.
Hence there's no-one to race with reading the extent list. Still, it
doesn't hurt.

Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>

-- 
Dave Chinner
david@xxxxxxxxxxxxx