From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 99898346E56 for ; Thu, 16 Apr 2026 07:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776325154; cv=none; b=idktddaa1zg7QXHNQl2I0JVUfRcorSVp4o4SA8DyZFzBWU7r8G8445/3vMcBhJ/qfF04EVxipGKCmhAZZTDzuSW8VQD+TwlhuobT5vQTvfBal8fXcoohCE/uIy91Au8kwGDPO5rlmr2Y4B9007ZlqyLSi7Gzpbpi83id5PD4DPo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776325154; c=relaxed/simple; bh=z2hx6ivnJiU7UzNIvjw5YPMUdSUH2CtVMHSJEfKOCFo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Y3rlNkVx/o9FIfZmLva3NXuTZU7+qMq5v0z5Qw515ZFlyo+aZS5osRW9auFT9Ni6CQWBplH4SQi47gjWtFcaBynA0Lz4gwkXR3jLeJoa5zzhIkJ3G6RyseQ0podYtkSdYLLyglN2G3QmjzI4M/UN3zzLUfAJIpB5nHd9tbkPBVA= 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=qXjdwJpE; arc=none smtp.client-ip=209.85.128.42 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="qXjdwJpE" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4888375f735so75818295e9.3 for ; Thu, 16 Apr 2026 00:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776325152; x=1776929952; 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=CDKFAyjNNZbEVBu27h7dEu+gaClTVdkwmkLAaz3gL9s=; b=qXjdwJpEoWBt2iyzqhEKIwp3LFZcy2INhYf9esfcrn2hzt+3aN2A2ogsgyWZN7eW0s y2rqujFhbLoSwP4Y7cK0grXknNo0WE1WjMgOmzx8nHa8IP6HWdf+zs3M1hyHmghvRfj3 wTrdBRGTOArL1Ic1jKNP1+mdMKIui8Mxp6n11eHnIxlgRqzeqqAIdMgogLJ1I/eTaPdb MZgVPst5zv/m4pEc8TgbWQRRT9A9TTrKL1lYq5zVRSBE9hp2U6speZldow5JYaMMdlqC ja4gVelArGNuHX11BtKAy1M4utRPKMbS3WJ4MiVirSKhv+vFOxx2Rt5EPBk0huaN/Hdo gavw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776325152; x=1776929952; 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=CDKFAyjNNZbEVBu27h7dEu+gaClTVdkwmkLAaz3gL9s=; b=Us4WnIH/m06DoyPOjoidafOhJ3CbZKhEnbWeWZyZuH1KqVRA4ONeBuys9dL5Bf2M3e RArSRwvI5rKVIaWepYipzozxv8UHFph2QN1I2sgFr0xgUeWpkM/I5pBew8q8lZzX/GLT 0JyrI3Zma4qo4hEav9K+tZcvRl3FuMTAcoaIYFBO+4H1yQAWewd1+rmI6og4RFcG8ZaN po2jp/cFNGJ8LBYj3/eunflSf16H1rSRAsiiE1jvLxt+Q2MEWKGmW/3dawR9Co+LbbQq 1fPX+QDNH3QX9I0zvrckyuRS6hXtMnHAeuZtHfvOoC3U+a21DNScDyPYK2xXFIJAv4sF VNhg== X-Forwarded-Encrypted: i=1; AFNElJ8KPLLTv7n1HPAmK9A749CQQ4glk28MfybVzqOVdr1ebuZBUxGpnwv9iFl6qRbHXrADhgImIdOcmVxUdwA=@vger.kernel.org X-Gm-Message-State: AOJu0YyCU058sPTr0TvTsyjYM1DKUdhJN3tZ4weZ1Kb6LjnUyL7Hxn0g AkiidV4BQvW5OqhmmFw4OY47+VZl+Po+kPfaeOoGuom8LMq6+jhnRkMh15v7/w== X-Gm-Gg: AeBDieuS5RdPgL//ffTZttKaGTQgBt+VcU0Rn+8edrg5ajb9EvulCxdwc15K2kJnT4b z0XFjd3YhivjH1zlMyorqzaEcs6VxQWSO6yDZwhHaHSecnQVLaIJwjpHsi0ZH/HkhMif2hFt9py mSdZ1J1BB7vPFozk4OPn6sxoRZAmP0pRTjUXmHS/9kQoFlO6mKG8urmpWCbeKxrJiDFloCodZor R8JZ8sv/rE2XSHSNcsVmPs168S19uV/x+og5YY+NKIBZ56knmYteeEkjAFdZwX9hf0weLTxZz8X u85mIaPjydDWM5cwBKwPdDKyjPDKQccA6sccNt78orx6e4fkJkYHLNXkNJJUrttMDFo0/MOziJV k37lWYOz2c5ODXb6aneZhYFNg6uKP8JftRwSOUIcUAQrcp6HuNFIX1mqWFffHELjug1B0V7cS21 JY5k64xk6xJMZSWt72bOwj3KXCzHKtfrbDbEuouFLlJzJR0pmGO0De7auxWRqweDGrEaMpG1NNO rEfpvpTsCHP X-Received: by 2002:a05:600c:c10d:b0:488:ae4e:51a5 with SMTP id 5b1f17b1804b1-488d683d633mr236535575e9.15.1776325151418; Thu, 16 Apr 2026 00:39:11 -0700 (PDT) Received: from Abds-MacBook-Air.local ([2a02:3037:62f:6885:b8ea:cbdc:574d:dff0]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488f5818d70sm53581085e9.4.2026.04.16.00.39.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2026 00:39:10 -0700 (PDT) From: Abd-Alrhman Masalkhi To: Li Nan , song@kernel.org, yukuai@fnnas.com, linan666@huaweicloud.com Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] md: use md_free_cloned_bio() in md_end_clone_io() In-Reply-To: <7f82e3ae-bb2b-96fc-af9c-632fa6ae07af@huaweicloud.com> References: <20260415081941.352389-1-abd.masalkhi@gmail.com> <7f82e3ae-bb2b-96fc-af9c-632fa6ae07af@huaweicloud.com> Date: Thu, 16 Apr 2026 09:39:09 +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 Nan, thank you for the feedback. On Thu, Apr 16, 2026 at 14:47 +0800, Li Nan wrote: > =E5=9C=A8 2026/4/15 16:19, Abd-Alrhman Masalkhi =E5=86=99=E9=81=93: >> md_end_clone_io() and md_free_cloned_bio() share identical teardown >> logic. Use md_free_cloned_bio() in md_end_clone_io() for cleanup and >> call bio_endio() afterwards. >>=20 >> Signed-off-by: Abd-Alrhman Masalkhi >> --- >> Changes in v2: >> - Reuse md_free_cloned_bio() instead of introducing a new helper >> - Link to v1: https://lore.kernel.org/linux-raid/20260414103813.307601= -1-abd.masalkhi@gmail.com >> --- >> drivers/md/md.c | 13 +------------ >> 1 file changed, 1 insertion(+), 12 deletions(-) >>=20 >> diff --git a/drivers/md/md.c b/drivers/md/md.c >> index ac71640ff3a8..8565566a447b 100644 >> --- a/drivers/md/md.c >> +++ b/drivers/md/md.c >> @@ -9212,20 +9212,9 @@ static void md_end_clone_io(struct bio *bio) >> { >> struct md_io_clone *md_io_clone =3D bio->bi_private; >> struct bio *orig_bio =3D md_io_clone->orig_bio; >> - struct mddev *mddev =3D md_io_clone->mddev; >> - >> - if (bio_data_dir(orig_bio) =3D=3D WRITE && md_bitmap_enabled(mddev, fa= lse)) >> - md_bitmap_end(mddev, md_io_clone); >> - >> - if (bio->bi_status && !orig_bio->bi_status) >> - orig_bio->bi_status =3D bio->bi_status; >> - >> - if (md_io_clone->start_time) >> - bio_end_io_acct(orig_bio, md_io_clone->start_time); >>=20=20=20 >> - bio_put(bio); >> + md_free_cloned_bio(bio); >> bio_endio(orig_bio); > > Is it safe to end orig_bio after putting active_io? As I understand it, active_io is primarily used to account for in-flight bios, allowing the array to be safely suspended once no bios are outstanding. I have made a diagram, while i am reviewing the md driver: mddev->active_io md driver: md_handle_request() mddev->active_io +1 pers->make_request() md_account_bio() +1 if (err) md_free_cloned_bio -1 mddev->active_io -1 lower driver: bio_endio() md_end_clone_io -1 As shown, it incremented in two places, the first is before passing orig_bio to pers->make_request(), and decremented after it returns (regardless of what make_request() does with it). and the second is when cloning the original bio, and it should be decremented after the cloned bio is released. In this context, it should not matter whether bio_endio(orig_bio) is called before or after decrementing active_io, as long as the cloned bio teardown is completed correctly. Am I missing anything that would make this unsafe? > >> - percpu_ref_put(&mddev->active_io); >> } >>=20=20=20 >> static void md_clone_bio(struct mddev *mddev, struct bio **bio) > > --=20 > Thanks, > Nan > --=20 Best Regards, Abd-Alrhman