From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 73EB93D47DD for ; Tue, 7 Jul 2026 10:35:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783420515; cv=none; b=CXziFK3Worgig53Ha2hIPQ3brInivB5pSaL7aJ1PjxG1IKzFd0Uq+aqcgmTlrkEmNC3byyPs/NqITmcGiwHFUHlPtcjxPbpKuIxrmfszUAo9vy0t16uzgp+daHGB9Sq2N7Li+mMxenusXRoUnXeM+M368x9NiKP5wZiJPJFDPho= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783420515; c=relaxed/simple; bh=uTcTJtQiQq9rjhO/KJFkg+mOFmnaKsZjnWAeZcl5Y3s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=qvOcOKlv2prRY2GpEI3wHS/OT3H/LTB3Ka1/zl+V6WfwUxfjkIRkCOcAdHLhwKYFQbmkCqgOjU0YNPQnwNhX34N2Vy9xN2AcBaKVkuX4u1TdUYoVhoZXP1jMpLM9a5sy8MO7Z3YTu3eSenKa2f2JKxnk0BLgEBL98npKKp/5zhE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=D7J6DJIE; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="D7J6DJIE" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-490cf3000f0so38441835e9.1 for ; Tue, 07 Jul 2026 03:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783420513; x=1784025313; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=uTcTJtQiQq9rjhO/KJFkg+mOFmnaKsZjnWAeZcl5Y3s=; b=D7J6DJIEC4jw+dmDd9JGNZ6FhlLXZR2x5H1FMZwucQLbq9IlJxgBQW+iwmRvx53tlR 1XlIQ9R/ROCWViN/97Gn4zk4Zt6CE1TGL2E0pfHdwCGVSnv5xmauQ8t+IC6JHIoZJpE5 1yCt4hqXlVap4fVzSX6V6BwxxR/Rfci3K7ZTjpXY/c7ZxahI7HIv6f5CSopGMG5FWTf+ Ud1aoBuq9VdPOqK8dWTf/cspv1+/PweCNbMpAvJelWLeY/YdZ5lZOdYbQREVYpnAare2 K7DAqBqJ+Cj5NOUUM6ntklpdohX+NMesn2jiXpmihtDgXnphXgf/Q7zylwAmRgQ7dq86 u11w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783420513; x=1784025313; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=uTcTJtQiQq9rjhO/KJFkg+mOFmnaKsZjnWAeZcl5Y3s=; b=PxvF41BMdgox+J8C4/YBvgde8RiDxbtSa2HiThRjz43Nh+d964quclVn9gfSuIwyWN H8CqoarWi+3Wb8uOjxj5bBCAtOvGdvfVwzlNBzbi7JxJmXR8bXUjpNdVRxMao2sWb9Cg NIwyKC95pfP4zigpt2NbO/mXwB7/OmjjKp14RiUSyoFsgbcNfovXWWY0V5JYkMaFuenH 0K/tqlUXtFxNjvch18kXTMIoR2Klx5CeRaJlqWtTmjhN/oiaTSgUZx7vezhAiJPH5d6w 89OAx8H950g3+5t0OHwBllMyuSRcTRD6ZxJzxRjPfgCrGB3VICpMH6mYjhqMISyOo2BO Q0jQ== X-Forwarded-Encrypted: i=1; AHgh+Rrd4xDI8tpPSUaBjFQ6HdZ8ylj0zeUSh4EstA2iDr1b/lDnBaREXvcRpwPo0+g73C/xzLtdNKaFVN/iTv4=@vger.kernel.org X-Gm-Message-State: AOJu0YypPX3pRYf6fCfq5Y6HQImlIbr++XEOE3ggCuN9AytOb351P4Uz Hto02D4tN9NTl44SqSj3+EG733eddPJX3Q9JVugq7GThuuAiB2oco+7Q X-Gm-Gg: AfdE7cn9nNyHGVLIuWTYITVQIfaHiC/euYMzBMMasDhWNo0ZTQ3YUpLib9yLXq0jbWi H3p+aCYthBJp0DeGaz4dDJPgSzWX9BNbBDrXPH/LOfih+CDTbWQ1gPObc8UW7ZEaZZRtnU6vbB4 /6pu+X3Z01Nc7f/NLv/Y7bWmHy8gUN2wgrHxLX8ZqJifUkqw1yeiOO5C02b/FW1Boaz+cBNGus2 Sl3irphL4w2VCjT59fuGgcBEJLXmceTEGHwLDPg1Id4MZK6EWgl1zSUtt5irYl/7CRX7ELvERuW YzmVbOYS6gkFMaObwptuTllq9Nsr0ssHz1uTPWWNnGORP4GLL+7A273nsuScQQaFvIQYhS+77Yj /XhrERwvCTR3cPoHsO9UckA1q/aSbkh/XTdEiZoLvg6Ytm7EzSPNCtGdY3Ww4loQPnXfN4BnDFY rR4jetQTdJXxiAX0yoYms1797nXS7xtvU0lAs8Hoq7ifNhnw== X-Received: by 2002:a05:600c:6994:b0:490:9588:bdb6 with SMTP id 5b1f17b1804b1-493df09a21dmr48212065e9.33.1783420512704; Tue, 07 Jul 2026 03:35:12 -0700 (PDT) Received: from Abds-MacBook-Air.local ([195.72.110.68]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47a9e4d7801sm33321623f8f.16.2026.07.07.03.35.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2026 03:35:12 -0700 (PDT) From: Abd-Alrhman Masalkhi To: yu kuai , yu kuai , song@kernel.org, magiclinan@didiglobal.com, xiao@kernel.org Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, sashiko-bot Subject: Re: [PATCH] md: avoid modifying spares while the array is not suspended In-Reply-To: <4f0b2516-65bd-41fa-abc3-3cd76951ec46@fygo.io> References: <20260630075640.1081634-1-abd.masalkhi@gmail.com> <0a7dc7e2-30af-44de-8c29-b6e27a62fa55@fygo.io> <4f0b2516-65bd-41fa-abc3-3cd76951ec46@fygo.io> Date: Tue, 07 Jul 2026 12:35:10 +0200 Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kuai, On Tue, Jul 07, 2026 at 09:12 +0800, yu kuai wrote: > Hi, > > =E5=9C=A8 2026/7/6 3:58, Abd-Alrhman Masalkhi =E5=86=99=E9=81=93: >>> 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_l= ock? If suspend is >>> supposed to be true, we can release the lock and retry with suspend =3D= 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. > --=20 > Thanks, > Kuai --=20 Best Regards, Abd-Alrhman