All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heming Zhao <heming.zhao@suse.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
	 Joseph Qi <joseph.qi@linux.alibaba.com>,
	jiangyiwen <jiangyiwen@huawei.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	ocfs2-devel@lists.linux.dev, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] ocfs2: kill osb->system_file_mutex lock
Date: Mon, 18 May 2026 12:56:22 +0800	[thread overview]
Message-ID: <agqbeO8Ykf6ntxNX@c73> (raw)
In-Reply-To: <fea8d1fd-afb0-4302-a560-c202e2ef7afd@I-love.SAKURA.ne.jp>

On Mon, May 18, 2026 at 01:23:40PM +0900, Tetsuo Handa wrote:
> Commit 43b10a20372d ("ocfs2: avoid system inode ref confusion by adding
> mutex lock") tried to avoid a refcount leak caused by allowing multiple
> threads to call igrab(inode). But addition of osb->system_file_mutex made
> locking dependency complicated and is causing lockdep to warn about
> possibility of AB-BA deadlock.
> 
> Since _ocfs2_get_system_file_inode() returns the same inode for the same
> input arguments, we don't need to serialize _ocfs2_get_system_file_inode().
> What we need to make sure is that igrab(inode) is called for only once().
> Therefore, replace osb->system_file_mutex with cmpxchg()-based locking.
> 
> Fixes: 43b10a20372d ("ocfs2: avoid system inode ref confusion by adding mutex lock")
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

LGTM. Thanks for the patch.
Reviewed-by: Heming Zhao <heming.zhao@suse.com>
> ---
> Changes in v2:
>   Updated patch description.
> 
>  fs/ocfs2/ocfs2.h   | 2 --
>  fs/ocfs2/super.c   | 2 --
>  fs/ocfs2/sysfile.c | 9 +++------
>  3 files changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/ocfs2/ocfs2.h b/fs/ocfs2/ocfs2.h
> index 7b50e03dfa66..62cad6522c7a 100644
> --- a/fs/ocfs2/ocfs2.h
> +++ b/fs/ocfs2/ocfs2.h
> @@ -494,8 +494,6 @@ struct ocfs2_super
>  	struct rb_root	osb_rf_lock_tree;
>  	struct ocfs2_refcount_tree *osb_ref_tree_lru;
>  
> -	struct mutex system_file_mutex;
> -
>  	/*
>  	 * OCFS2 needs to schedule several different types of work which
>  	 * require cluster locking, disk I/O, recovery waits, etc. Since these
> diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
> index b875f01c9756..6dd45c2153f8 100644
> --- a/fs/ocfs2/super.c
> +++ b/fs/ocfs2/super.c
> @@ -1997,8 +1997,6 @@ static int ocfs2_initialize_super(struct super_block *sb,
>  	spin_lock_init(&osb->osb_xattr_lock);
>  	ocfs2_init_steal_slots(osb);
>  
> -	mutex_init(&osb->system_file_mutex);
> -
>  	atomic_set(&osb->alloc_stats.moves, 0);
>  	atomic_set(&osb->alloc_stats.local_data, 0);
>  	atomic_set(&osb->alloc_stats.bitmap_data, 0);
> diff --git a/fs/ocfs2/sysfile.c b/fs/ocfs2/sysfile.c
> index d53a6cc866be..67e492f4b828 100644
> --- a/fs/ocfs2/sysfile.c
> +++ b/fs/ocfs2/sysfile.c
> @@ -98,11 +98,9 @@ struct inode *ocfs2_get_system_file_inode(struct ocfs2_super *osb,
>  	} else
>  		arr = get_local_system_inode(osb, type, slot);
>  
> -	mutex_lock(&osb->system_file_mutex);
>  	if (arr && ((inode = *arr) != NULL)) {
>  		/* get a ref in addition to the array ref */
>  		inode = igrab(inode);
> -		mutex_unlock(&osb->system_file_mutex);
>  		BUG_ON(!inode);
>  
>  		return inode;
> @@ -112,11 +110,10 @@ struct inode *ocfs2_get_system_file_inode(struct ocfs2_super *osb,
>  	inode = _ocfs2_get_system_file_inode(osb, type, slot);
>  
>  	/* add one more if putting into array for first time */
> -	if (arr && inode) {
> -		*arr = igrab(inode);
> -		BUG_ON(!*arr);
> +	if (inode && arr && !*arr && !cmpxchg(&(*arr), NULL, inode)) {
> +		inode = igrab(inode);
> +		BUG_ON(!inode);
>  	}
> -	mutex_unlock(&osb->system_file_mutex);
>  	return inode;
>  }
>  
> -- 
> 2.54.0
> 
> 

  reply	other threads:[~2026-05-18  4:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-21 15:56 [PATCH] ocfs2: kill osb->system_file_mutex lock Tetsuo Handa
2025-06-24  1:33 ` Heming Zhao
2025-06-24  1:55   ` Tetsuo Handa
2025-06-24  2:51     ` Heming Zhao
2025-06-24  2:17   ` Tetsuo Handa
2025-06-24  2:40     ` Heming Zhao
2025-06-24  3:05       ` Tetsuo Handa
2026-05-14  7:09 ` Tetsuo Handa
2026-05-15 15:35   ` Heming Zhao
2026-05-15 15:51     ` Tetsuo Handa
2026-05-15 23:56       ` Heming Zhao
2026-05-15 23:53     ` Heming Zhao
2026-05-16  5:52       ` Tetsuo Handa
2026-05-16 12:27         ` Heming Zhao
2026-05-16 13:10           ` Tetsuo Handa
2026-05-18  2:52             ` Heming Zhao
2026-05-18  4:23               ` [PATCH v2] " Tetsuo Handa
2026-05-18  4:56                 ` Heming Zhao [this message]
2026-05-18  6:20                   ` Joseph Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=agqbeO8Ykf6ntxNX@c73 \
    --to=heming.zhao@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=jiangyiwen@huawei.com \
    --cc=jlbec@evilplan.org \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@fasheh.com \
    --cc=ocfs2-devel@lists.linux.dev \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.