Re: [PATCH 05/43] xfs: don't take m_sb_lock in xfs_fs_statfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 11, 2024 at 09:54:30AM +0100, Christoph Hellwig wrote:
> The only non-constant value read under m_sb_lock in xfs_fs_statfs is
> sb_dblocks, and it could become stale right after dropping the lock
> anyway.  Remove the thus pointless lock section.

Is there a stronger reason later for removing the critical section?
Do we lose much by leaving the protection in place?

--D

> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> ---
>  fs/xfs/xfs_super.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index 0fa7b7cc75c1..bfa8cc927009 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -850,11 +850,9 @@ xfs_fs_statfs(
>  	ifree = percpu_counter_sum(&mp->m_ifree);
>  	fdblocks = percpu_counter_sum(&mp->m_fdblocks);
>  
> -	spin_lock(&mp->m_sb_lock);
>  	statp->f_bsize = sbp->sb_blocksize;
>  	lsize = sbp->sb_logstart ? sbp->sb_logblocks : 0;
>  	statp->f_blocks = sbp->sb_dblocks - lsize;
> -	spin_unlock(&mp->m_sb_lock);
>  
>  	/* make sure statp->f_bfree does not underflow */
>  	statp->f_bfree = max_t(int64_t, 0,
> -- 
> 2.45.2
> 
> 




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux