From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (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 E35EC3A8738 for ; Wed, 24 Jun 2026 08:12:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782288760; cv=none; b=MCK8ID1DpWFlSgpgzmABz4Qia3tfLEbO0/2l1Vb87+Un9+MxouldJwCqU+hL2lKqCC0M+Kv/KWmMqYUuItQReL7tu9orHinIqD5qb90VOSv9GxOvIAtBKhpOP034YvGIM5aKDHA0WQREEqUJLCwCNvmxoV5uWAvvgii8JnKkImk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782288760; c=relaxed/simple; bh=kDceYG3/TLAjXyKwcJpP88lKt6M1l3v2ftJZp66lxzI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=T8jm3M1wtd4/lzpS16oHaFPOGaLdB8QZ/ZcRT1ITdCyb6RUcTJiF6hZ23L9NCxUahoA3EuxTpzvsujqo37gZ/rwY1F0E21v1ZAkIWI6lZF2sMNdNRa9qY7ZVvkKTqOciYNXxZYDqRKA5AZ+a0FbUVOv9exXOgvJ+IZwIfVQ54/E= 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=f6mFlVNx; arc=none smtp.client-ip=209.85.221.43 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="f6mFlVNx" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-46cbf263113so76545f8f.1 for ; Wed, 24 Jun 2026 01:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782288757; x=1782893557; 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=mrhljFF96ju8Gx+nYRs6h2vCz/Hl+SeggodLEe08vOA=; b=f6mFlVNxa8qfs7mjutCiXjJL/FLUoei6uM5XqFmtlbHR1FzNHljPzs9OSZnY0bobrQ h3iQS8IhE7OWVndMahsVQ7fw6QnIxiFpK+VC4Nz1iXUB6E3J97v8IdCMBLM9m+T3+PFs RzdcK0CPxxyubG7WDSCMLuaw+IdZLwJjO4LLpfwMW7yj/MpzFUy3vikw+r4Y1wSkPzj9 6KTIXCeFVibHzawn8sX/aAAujQVd91HOzyUVt0S8Et+/QNILnu7r5mF+sKe71aFPWsgE 4KN/jD3J/ZlZD77+w/+UPGq7GZ6eK+YcYClOwnlqI36LicH+c9H/RInnv6+ShH/I3eF5 ecCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782288757; x=1782893557; 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=mrhljFF96ju8Gx+nYRs6h2vCz/Hl+SeggodLEe08vOA=; b=QVIhyIUrE/j+rrbCqUjpvjrjmHVq0P8SntYiRo/CcPPK+3Clyo+gCcbMLQn+7ZGeXT SFjHvylYjSN4JhEKuOhi1zqIqh4NslMYKf+DWv2tlcsmhxYDHDEuOxQpgWVAkvvKEKWB U/lOJo4T91a297Oliue8kH2uGya3HOuTMQFCCVoAw7s0yj7PSQ4KgxGXobWsER2YtJBT SQUMHE4Q9fP4urC+mS82kPyiuiwAhBD29SOyNdEEjogK1+WZPMpQtxyJMGTEhY2XQZwn 3ncWqoUeNcT6RFnt7FX336OSyGx9pW7yf787ZgoarP6rLsWZqOf+rBZLMOnruB8KsQYK vEMw== X-Forwarded-Encrypted: i=1; AHgh+Rp7PywrKvYx4/5k69ZR9YUdx4ch9dGkG9mFui2apFHb2VZiaM4SwipT3uaIt8zdSgFCyKwdQmZ4Yy05Qvg=@vger.kernel.org X-Gm-Message-State: AOJu0YwWmCtV2zZZmY/Ttsw2Zked+Kwxs82u6nVr1y96PwW4bKMhthZw aEr8u/H0BlJBadI9/qhyxIF2mulFUFeabvNDBlErqC1a5XjU512k0+1GfbX5rg== X-Gm-Gg: AfdE7cn6CGqrLh7f5wwBWv7rFGNs4d1J9Q7wIFPdAVYYcUYErvh5BDRABlLgHsjkNhP b3gbXRdjis/jtTsNqFd2smF0mzrcwi4njtrqqj6J5gd5wewDjHMi59A8RCcT8OMdIIzl3nJePOx ihtNUY0U6dztpu7ryoBZ3UNRHPkOAJsX57GI5rG0bdt1GnhS0THmZyhmTTdLoTAkSUMdAhq+TKD mM8fLnQuoD+drdcy5O/ZqXVn3rUxf4WIoU1q5J2jAa7XHZHh4HbXZ4PJCxN345XBpBV68siGTwx R2JOP4gaHrLQWqEwkHs3RW9TESEG/kcmR3SCeJLgneAM9yVIPICIxq+XQ6MfNB7PkWGiZE4Ibbv J5wtH6A+duexD2Bz0trdJLHrvVzrADiRJimuqpA+JXKuuG3FFdltkKKWoL7/ooUOMGM//t6e5oc ueZV2PfZxMvQukvhGc1aky/kRvyLlFE5TYN5hn4mA+/ecXew== X-Received: by 2002:adf:f246:0:b0:461:cd9e:2366 with SMTP id ffacd0b85a97d-46c099f5b3dmr3072524f8f.13.1782288757055; Wed, 24 Jun 2026 01:12:37 -0700 (PDT) Received: from Abds-MacBook-Air.local ([141.2.113.191]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-46c1e840f80sm5209933f8f.6.2026.06.24.01.12.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 01:12:36 -0700 (PDT) From: Abd-Alrhman Masalkhi To: yu kuai , song@kernel.org, magiclinan@didiglobal.com, xiao@kernel.org, axboe@kernel.dk, john.g.garry@oracle.com, martin.petersen@oracle.com, yukuai@fygo.io Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/7] md/raid10: raid10_write_request() drops the barrier before calling In-Reply-To: <7239c50c-b257-4179-827a-9facd48e75e1@fygo.io> References: <20260623072456.333437-1-abd.masalkhi@gmail.com> <20260623072456.333437-5-abd.masalkhi@gmail.com> <7239c50c-b257-4179-827a-9facd48e75e1@fygo.io> Date: Wed, 24 Jun 2026 10:12:35 +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 Kaui, On Wed, Jun 24, 2026 at 15:23 +0800, yu kuai wrote: > Hi, > > =E5=9C=A8 2026/6/23 15:24, Abd-Alrhman Masalkhi =E5=86=99=E9=81=93: >> bio_submit_split_bioset() and reacquires it afterwards. This is >> unnecessary because bio_submit_split_bioset() does not require >> releasing the barrier protection. > > Why is this safe? > > It's possible plug is not enabled in this context, and the allocated new > aplit bio will be submitted and enter wait_barrier() again. wait_barrier() > is not supposed to be called recursively. Otherwise deadlock can happend: > > t1: sync_thread grab barrier and waiting for nr_pending to be 0 from rais= e_barrier() > t2: wait_barrier() first inc nr_pending, then recursive wait_barrier() wa= iting > for barrier to be released. > raid10_write_request() is only called from the bio submission path and not from raid10d thread, so we do not re-enter it while already holding barrier. Therefore, the split bio submitted by bio_submit_split_bioset() cannot recurse back into wait_barrier() from the same execution path. The situation is different for reads, where raid10_read_request() will be called both from the submission path and from raid10d. There, dropping and reacquiring the barrier protection remains necessary. >> >> Remove the redundant allow_barrier()/wait_barrier() pair around >> bio_submit_split_bioset(). >> >> Signed-off-by: Abd-Alrhman Masalkhi >> --- >> drivers/md/raid10.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c >> index 840f0446c231..4bc1d5553ec7 100644 >> --- a/drivers/md/raid10.c >> +++ b/drivers/md/raid10.c >> @@ -1493,10 +1493,8 @@ static bool raid10_write_request(struct mddev *md= dev, struct bio *bio, >> if (atomic) >> goto err_handle; >>=20=20=20 >> - allow_barrier(conf); >> bio =3D bio_submit_split_bioset(bio, r10_bio->sectors, >> &conf->bio_split); >> - wait_barrier(conf, false); >> if (!bio) { >> set_bit(R10BIO_Returned, &r10_bio->state); >> goto err_handle; > > --=20 > Thanks, > Kuai --=20 Best Regards, Abd-Alrhman