All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] fs/xfs: fix comments mentioning i_mutex
@ 2022-01-21  7:15 hongnanli
  2022-01-21 20:28 ` Darrick J. Wong
  0 siblings, 1 reply; 2+ messages in thread
From: hongnanli @ 2022-01-21  7:15 UTC (permalink / raw)
  To: linux-xfs; +Cc: djwong

inode->i_mutex has been replaced with inode->i_rwsem long ago. Fix
comments still mentioning i_mutex.

Signed-off-by: hongnanli <hongnan.li@linux.alibaba.com>
---
 fs/xfs/xfs_acl.c   | 2 +-
 fs/xfs/xfs_iomap.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_acl.c b/fs/xfs/xfs_acl.c
index 5c52ee869272..b02c83f8b8c4 100644
--- a/fs/xfs/xfs_acl.c
+++ b/fs/xfs/xfs_acl.c
@@ -22,7 +22,7 @@
 
 /*
  * Locking scheme:
- *  - all ACL updates are protected by inode->i_mutex, which is taken before
+ *  - all ACL updates are protected by inode->i_rwsem, which is taken before
  *    calling into this file.
  */
 
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index e552ce541ec2..288a5cdcaa61 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1126,7 +1126,7 @@ xfs_buffered_write_iomap_end(
 	 * Trim delalloc blocks if they were allocated by this write and we
 	 * didn't manage to write the whole range.
 	 *
-	 * We don't need to care about racing delalloc as we hold i_mutex
+	 * We don't need to care about racing delalloc as we hold i_rwsem
 	 * across the reserve/allocate/unreserve calls. If there are delalloc
 	 * blocks in the range, they are ours.
 	 */
-- 
2.19.1.6.gb485710b


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] fs/xfs: fix comments mentioning i_mutex
  2022-01-21  7:15 [PATCH] fs/xfs: fix comments mentioning i_mutex hongnanli
@ 2022-01-21 20:28 ` Darrick J. Wong
  0 siblings, 0 replies; 2+ messages in thread
From: Darrick J. Wong @ 2022-01-21 20:28 UTC (permalink / raw)
  To: hongnanli; +Cc: linux-xfs

On Fri, Jan 21, 2022 at 03:15:05PM +0800, hongnanli wrote:
> inode->i_mutex has been replaced with inode->i_rwsem long ago. Fix
> comments still mentioning i_mutex.
> 
> Signed-off-by: hongnanli <hongnan.li@linux.alibaba.com>
> ---
>  fs/xfs/xfs_acl.c   | 2 +-
>  fs/xfs/xfs_iomap.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/xfs/xfs_acl.c b/fs/xfs/xfs_acl.c
> index 5c52ee869272..b02c83f8b8c4 100644
> --- a/fs/xfs/xfs_acl.c
> +++ b/fs/xfs/xfs_acl.c
> @@ -22,7 +22,7 @@
>  
>  /*
>   * Locking scheme:
> - *  - all ACL updates are protected by inode->i_mutex, which is taken before
> + *  - all ACL updates are protected by inode->i_rwsem, which is taken before

This should use more general terminology here, such as "VFS inode lock"
or "IOLOCK" (XFS-specific shorthand), since the implementation may
change again in the future.

--D

>   *    calling into this file.
>   */
>  
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index e552ce541ec2..288a5cdcaa61 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1126,7 +1126,7 @@ xfs_buffered_write_iomap_end(
>  	 * Trim delalloc blocks if they were allocated by this write and we
>  	 * didn't manage to write the whole range.
>  	 *
> -	 * We don't need to care about racing delalloc as we hold i_mutex
> +	 * We don't need to care about racing delalloc as we hold i_rwsem
>  	 * across the reserve/allocate/unreserve calls. If there are delalloc
>  	 * blocks in the range, they are ours.
>  	 */
> -- 
> 2.19.1.6.gb485710b
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-01-21 20:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-21  7:15 [PATCH] fs/xfs: fix comments mentioning i_mutex hongnanli
2022-01-21 20:28 ` Darrick J. Wong

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.