All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: ghuicao@163.com
Cc: yukuai@fygo.io, linux-raid@vger.kernel.org
Subject: Re: [PATCH v2 1/3] md-cluster: fix error handling and superblock update in update_size revert
Date: Thu, 27 Aug 2026 06:24:49 +0000	[thread overview]
Message-ID: <20260827062449.958811F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260827061200.79753-1-ghuicao@163.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Guaranteed self-deadlock and potential double-unlocks in `update_size` due to calling `md_update_sb()` while the cluster communication lock is held.
--

commit bae2db67348747b3864a225bb7b24be69937b7a2
Author: Cao Guanghui <caoguanghui@kylinos.cn>

md-cluster: fix error handling and superblock update in update_size revert

This commit addresses error handling and metadata updates when reverting an
array resize operation in a cluster. It checks the return value of resize()
and updates the superblock to match the in-memory array size.

> diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
> index 24dac6f09da82..9f404660a1fb7 100644
> --- a/drivers/md/md-cluster.c
> +++ b/drivers/md/md-cluster.c
> @@ -1349,6 +1349,10 @@ static void update_size(struct mddev *mddev, sector_t old_dev_sectors)
>  	} else {
>  		/* revert to previous sectors */
>  		ret = mddev->pers->resize(mddev, old_dev_sectors);
> +		if (ret)
> +			pr_err("%s:%d: failed to revert array size\n",
> +			       __func__, __LINE__);
> +		md_update_sb(mddev, 1);

[Severity: High]
Does this call to md_update_sb() cause a self-deadlock?

At this point in update_size(), the cluster communication lock
(MD_CLUSTER_SEND_LOCK) is already held via lock_comm(). When md_update_sb()
is called, it enters mddev->cluster_ops->metadata_update_start(mddev), which
waits for MD_CLUSTER_SEND_LOCK to be cleared. Since the lock is held by the
same thread, this appears to result in a strict self-deadlock during a failed
array resize operation.

Additionally, if the deadlock could somehow be bypassed, md_update_sb() would
complete by calling metadata_update_finish(), which prematurely calls
unlock_comm(), leading to a fatal double-unlock when update_size() later
attempts to call unlock_comm() itself.

>  		ret = __sendmsg(cinfo, &cmsg);
>  		if (ret)
>  			pr_err("%s:%d: failed to send METADATA_UPDATED msg\n",

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827061200.79753-1-ghuicao@163.com?part=1

  parent reply	other threads:[~2026-08-27  6:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27  2:52 [PATCH] md-cluster: check pers->resize() return value in update_size() ghuicao
2026-08-27  3:07 ` sashiko-bot
2026-08-27  6:11 ` [PATCH v2 1/3] md-cluster: fix error handling and superblock update in update_size revert ghuicao
2026-08-27  6:11   ` [PATCH v2 2/3] md-cluster: propagate update_size() errors to callers ghuicao
2026-08-27  6:23     ` sashiko-bot
2026-08-27  6:12   ` [PATCH v2 3/3] md-cluster: fix ack_lockres leak in __sendmsg error path ghuicao
2026-08-27  6:24     ` sashiko-bot
2026-08-27  6:24   ` sashiko-bot [this message]
2026-08-27  8:44   ` [PATCH v3 1/3] md-cluster: fix lock_comm leak and " ghuicao
2026-08-27  8:44     ` [PATCH v3 2/3] md-cluster: fix error handling and superblock consistency in update_size ghuicao
2026-08-27  8:58       ` sashiko-bot
2026-08-27  8:44     ` [PATCH v3 3/3] md-cluster: revert local resize and propagate cluster errors ghuicao
2026-08-27  9:04       ` sashiko-bot
2026-08-27  8:58     ` [PATCH v3 1/3] md-cluster: fix lock_comm leak and __sendmsg error path sashiko-bot

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=20260827062449.958811F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ghuicao@163.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yukuai@fygo.io \
    /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.