All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heming Zhao <heming.zhao@suse.com>
To: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
	ocfs2-devel@lists.linux.dev,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] ocfs2: exit recovery thread on mount error path
Date: Fri, 28 Aug 2026 15:41:53 +0800	[thread overview]
Message-ID: <apE7j-pFxA8iCY7_@p15> (raw)
In-Reply-To: <20260828071553.262254-1-joseph.qi@linux.alibaba.com>

On Fri, Aug 28, 2026 at 03:15:52PM +0800, Joseph Qi wrote:
> When a mount fails after the cluster connection has been established,
> e.g. in ocfs2_mount_volume(), ocfs2_fill_super() unwinds via
> out_debugfs/out_super and frees the osb without disabling recovery.
> 
> A node failure event can concurrently launch the recovery thread, which
> blocks in __ocfs2_wait_on_mount() waiting for the volume state to
> become VOLUME_MOUNTED or VOLUME_DISABLED.  As the mount error path
> neither sets VOLUME_DISABLED nor wakes osb_mount_event, the thread can
> never make progress: the kthread leaks and stays blocked on the wait
> queue embedded in the freed osb, which may then be accessed as freed
> memory.
> 
> Fix it by setting VOLUME_DISABLED and waking osb_mount_event on this
> path so the thread bails out, and replace the plain
> kfree(osb->recovery_map) with ocfs2_recovery_exit(), which waits for a
> running recovery thread to exit before the recovery map is freed.
> 
> Fixes: f1e75d128b46 ("ocfs2: rewrite error handling of ocfs2_fill_super")
> Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>

LGTM
Reviewed-by: Heming Zhao <heming.zhao@suse.com>
> ---
>  fs/ocfs2/super.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
> index c62e389d4dd6..f785c39d1fb8 100644
> --- a/fs/ocfs2/super.c
> +++ b/fs/ocfs2/super.c
> @@ -1169,8 +1169,17 @@ static int ocfs2_fill_super(struct super_block *sb, struct fs_context *fc)
>  out_debugfs:
>  	debugfs_remove_recursive(osb->osb_debug_root);
>  out_super:
> +	/*
> +	 * A recovery thread launched by a node failure event may still be
> +	 * waiting for the volume to be mounted.  Set VOLUME_DISABLED and
> +	 * wake it up, then wait for it to exit before osb is freed,
> +	 * otherwise the kthread would leak and stay blocked on the wait
> +	 * queue embedded in the freed osb.
> +	 */
> +	atomic_set(&osb->vol_state, VOLUME_DISABLED);
> +	wake_up(&osb->osb_mount_event);
>  	ocfs2_release_system_inodes(osb);
> -	kfree(osb->recovery_map);
> +	ocfs2_recovery_exit(osb);
>  	ocfs2_delete_osb(osb);
>  	kfree(osb);
>  out:
> -- 
> 2.39.3
> 

  parent reply	other threads:[~2026-08-28  7:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28  7:15 [PATCH v2 1/2] ocfs2: exit recovery thread on mount error path Joseph Qi
2026-08-28  7:15 ` [PATCH v2 2/2] ocfs2: defer suballocator block group reclaim to workqueue Joseph Qi
2026-08-28  7:42   ` Heming Zhao
2026-08-28  7:41 ` Heming Zhao [this message]
2026-08-28  8:17 ` [PATCH v2 1/2] ocfs2: exit recovery thread on mount error path 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=apE7j-pFxA8iCY7_@p15 \
    --to=heming.zhao@suse.com \
    --cc=akpm@linux-foundation.org \
    --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 \
    /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.