All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: mariusz.tkaczyk@intel.com, song@kernel.org,
	linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
	yukuai3@huawei.com, yi.zhang@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH md-6.12 4/7] md/raid1: factor out helper to handle blocked rdev from raid1_write_request()
Date: Fri, 30 Aug 2024 13:06:45 +0200	[thread overview]
Message-ID: <20240830130645.000076c6@linux.intel.com> (raw)
In-Reply-To: <20240830072721.2112006-5-yukuai1@huaweicloud.com>

On Fri, 30 Aug 2024 15:27:18 +0800
Yu Kuai <yukuai1@huaweicloud.com> wrote:

> From: Yu Kuai <yukuai3@huawei.com>
> 
> Currently raid1 is preparing IO for underlying disks while checking if
> any disk is blocked, if so allocated resources must be released, then
> waiting for rdev to be unblocked and try to prepare IO again.
> 
> Make code cleaner by checking blocked rdev first, it doesn't matter if
> rdev is blocked while issuing this IO.
> 
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
>  drivers/md/raid1.c | 84 ++++++++++++++++++++++++++--------------------
>  1 file changed, 48 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index f55c8e67d059..aa30c3240c85 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -1406,6 +1406,49 @@ static void raid1_read_request(struct mddev *mddev,
> struct bio *bio, submit_bio_noacct(read_bio);
>  }
>  
> +static bool wait_blocked_rdev(struct mddev *mddev, struct bio *bio)
> +{
> +	struct r1conf *conf = mddev->private;
> +	int disks = conf->raid_disks * 2;
> +	int i;
> +
> +retry:
> +	for (i = 0; i < disks; i++) {
> +		struct md_rdev *rdev = conf->mirrors[i].rdev;
> +
> +		if (!rdev)
> +			continue;
> +
> +		if (test_bit(Blocked, &rdev->flags)) {
Don't we need unlikely here?


> +			if (bio->bi_opf & REQ_NOWAIT)
> +				return false;
> +
> +			mddev_add_trace_msg(rdev->mddev, "raid1 wait rdev %d
> blocked",
> +					    rdev->raid_disk);
> +			atomic_inc(&rdev->nr_pending);


retry moves us before for (ugh, ugly) and "theoretically" we can back here
with the same disk and increase nr_pending twice or more because rdve can become
block again from different thread.

This is what I suspect but it could be wrong.

Mariusz


  reply	other threads:[~2024-08-30 11:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-30  7:27 [PATCH md-6.12 0/7] md: enhance faulty chekcing for blocked handling Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 1/7] md: add a new helper rdev_blocked() Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 2/7] md: don't wait faulty rdev in md_wait_for_blocked_rdev() Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 3/7] md: don't record new badblocks for faulty rdev Yu Kuai
2024-08-30 10:28   ` Mariusz Tkaczyk
2024-08-31  1:14     ` Yu Kuai
2024-09-02  8:55       ` Mariusz Tkaczyk
2024-09-02 12:37         ` Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 4/7] md/raid1: factor out helper to handle blocked rdev from raid1_write_request() Yu Kuai
2024-08-30 11:06   ` Mariusz Tkaczyk [this message]
2024-08-31  1:13     ` Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 5/7] md/raid1: don't wait for Faulty rdev in wait_blocked_rdev() Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 6/7] md/raid10: " Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 7/7] md/raid5: don't set Faulty rdev for blocked_rdev Yu Kuai
2024-08-30 11:12 ` [PATCH md-6.12 0/7] md: enhance faulty chekcing for blocked handling Mariusz Tkaczyk
2024-10-09  7:14 ` Mariusz Tkaczyk
2024-10-10 12:38   ` Yu Kuai
2024-10-09  8:52 ` Paul Menzel
2024-10-10 12:40   ` Yu Kuai

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=20240830130645.000076c6@linux.intel.com \
    --to=mariusz.tkaczyk@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=mariusz.tkaczyk@intel.com \
    --cc=song@kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai1@huaweicloud.com \
    --cc=yukuai3@huawei.com \
    /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.