From: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
To: yu kuai <yukuai@fygo.io>, yu kuai <yukuai@fygo.io>,
song@kernel.org, magiclinan@didiglobal.com, xiao@kernel.org
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
sashiko-bot <sashiko-bot@kernel.org>
Subject: Re: [PATCH] md: avoid modifying spares while the array is not suspended
Date: Tue, 07 Jul 2026 12:35:10 +0200 [thread overview]
Message-ID: <m2mrw36qap.fsf@gmail.com> (raw)
In-Reply-To: <4f0b2516-65bd-41fa-abc3-3cd76951ec46@fygo.io>
Hi Kuai,
On Tue, Jul 07, 2026 at 09:12 +0800, yu kuai wrote:
> Hi,
>
> 在 2026/7/6 3:58, Abd-Alrhman Masalkhi 写道:
>>> The problem looks real, however, I think this will cause a change that user will be awared,
>>> if there are really spares that can be removed from conf, but array is not suspended here,
>>> user will still expect rdev will be removed from conf automatically.
>>>
>>> In md_start_sync, if suspend is false, can we check again after mddev_lock? If suspend is
>>> supposed to be true, we can release the lock and retry with suspend = true.
>>>
>> Yes, I see, and your approach is much better. But what do you think
>> about taking the lock first and then checking only once?
>
> I don't get what you mean. If we take the lock and then check that array should
> suspend, we still have to release the lock before we suspend the array.
>
Sorry, I was not clear. I meant, do we need to check twice, once before
taking the lock and once after? It seems that the check before taking the
lock is redundant. since the result would need to be checked again after
taking the lock anyway.
Could we drop the check before taking the lock and only check whether
suspension is needed once while holding it? If suspension is needed, we
would release the lock, suspend the array, and then reacquire the lock.
> --
> Thanks,
> Kuai
--
Best Regards,
Abd-Alrhman
next prev parent reply other threads:[~2026-07-07 10:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 7:56 [PATCH] md: avoid modifying spares while the array is not suspended Abd-Alrhman Masalkhi
2026-07-05 16:16 ` yu kuai
2026-07-05 19:58 ` Abd-Alrhman Masalkhi
2026-07-07 1:12 ` yu kuai
2026-07-07 10:35 ` Abd-Alrhman Masalkhi [this message]
2026-07-08 8:32 ` yu kuai
2026-07-08 8:59 ` Abd-Alrhman Masalkhi
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=m2mrw36qap.fsf@gmail.com \
--to=abd.masalkhi@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=magiclinan@didiglobal.com \
--cc=sashiko-bot@kernel.org \
--cc=song@kernel.org \
--cc=xiao@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox