All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nilay Shroff <nilay@linux.ibm.com>
To: Jack Wang <jinpu.wang@ionos.com>, Song Liu <song@kernel.org>,
	Yu Kuai <yukuai@fygo.io>,
	linux-raid@vger.kernel.org, abd.masalkhi@gmail.com
Cc: linux-block@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@lst.de>,
	Damien Le Moal <dlemoal@kernel.org>,
	Ming Lei <tom.leiming@gmail.com>, Xiao Ni <xiao@kernel.org>,
	Li Nan <magiclinan@didiglobal.com>,
	Mike Snitzer <snitzer@kernel.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
	Jack Wang <jinpu.wang@cloud.ionos.com>
Subject: Re: [PATCH v2 6/8] md: pass a queue_limits through ->run()
Date: Fri, 11 Sep 2026 16:24:44 +0530	[thread overview]
Message-ID: <ec866125-6e45-4977-bb01-b13697fd3a8c@linux.ibm.com> (raw)
In-Reply-To: <20260910081114.1605746-7-jinpu.wang@ionos.com>

> diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
> index 35e103f0c2c3..59141e4299a8 100644
> --- a/drivers/md/raid0.c
> +++ b/drivers/md/raid0.c
> @@ -379,7 +379,8 @@ static void raid0_free(struct mddev *mddev, void *priv)
>   	kfree(conf);
>   }
>   
> -static int raid0_set_limits(struct mddev *mddev)
> +static int raid0_set_limits(struct mddev *mddev,
> +			    struct queue_limits *caller_lim)
>   {
>   	struct queue_limits lim;
>   	int err;
> @@ -398,10 +399,19 @@ static int raid0_set_limits(struct mddev *mddev)
>   	err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);
>   	if (err)
>   		return err;
> +	/*
> +	 * The caller owns an update and commits it itself; taking
> +	 * q->limits_lock here would take it a second time.
> +	 */
> +	if (caller_lim) {
> +		*caller_lim = lim;
> +		return 0;
> +	}
> +
>   	return queue_limits_set(mddev->gendisk->queue, &lim);
>   }
>   
[...]

> -static int raid1_set_limits(struct mddev *mddev)
> +static int raid1_set_limits(struct mddev *mddev,
> +			    struct queue_limits *caller_lim)
>   {
>   	struct queue_limits lim;
>   	int err;
> @@ -3185,10 +3186,19 @@ static int raid1_set_limits(struct mddev *mddev)
>   	err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);
>   	if (err)
>   		return err;
> +	/*
> +	 * The caller owns an update and commits it itself; taking
> +	 * q->limits_lock here would take it a second time.
> +	 */
> +	if (caller_lim) {
> +		*caller_lim = lim;
> +		return 0;
> +	}
> +
>   	return queue_limits_set(mddev->gendisk->queue, &lim);
>   }
>   

[...]

>   
> -static int raid10_set_queue_limits(struct mddev *mddev)
> +static int raid10_set_queue_limits(struct mddev *mddev,
> +				   struct queue_limits *caller_lim)
>   {
>   	struct r10conf *conf = mddev->private;
>   	struct queue_limits lim;
> @@ -3948,10 +3949,19 @@ static int raid10_set_queue_limits(struct mddev *mddev)
>   	err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);
>   	if (err)
>   		return err;
> +	/*
> +	 * The caller owns an update and commits it itself; taking
> +	 * q->limits_lock here would take it a second time.
> +	 */
> +	if (caller_lim) {
> +		*caller_lim = lim;
> +		return 0;
> +	}
> +
>   	return queue_limits_set(mddev->gendisk->queue, &lim);
>   }
>   

[...]

> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 22759c631c4d..28bd81de86c1 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -7944,7 +7944,8 @@ static int raid5_create_ctx_pool(struct r5conf *conf)
>   	return conf->ctx_pool ? 0 : -ENOMEM;
>   }
>   
> -static int raid5_set_limits(struct mddev *mddev)
> +static int raid5_set_limits(struct mddev *mddev,
> +			    struct queue_limits *caller_lim)
>   {
>   	struct r5conf *conf = mddev->private;
>   	struct queue_limits lim;
> @@ -7996,10 +7997,19 @@ static int raid5_set_limits(struct mddev *mddev)
>   	/* No restrictions on the number of segments in the request */
>   	lim.max_segments = USHRT_MAX;
>   
> +	/*
> +	 * The caller owns an update and commits it itself; taking
> +	 * q->limits_lock here would take it a second time.
> +	 */
> +	if (caller_lim) {
> +		*caller_lim = lim;
> +		return 0;
> +	}
> +
>   	return queue_limits_set(mddev->gendisk->queue, &lim);
>   }
>   
[...]
I'd propose the same changes as I suggested in patch 1/8, for
raid5_set_limits(), raid10_set_queue_limits(), raid1_set_limits()
and raid0_set_limits().

In particular, I think these functions should always operate on
a caller-provided struct queue_limits and only prepare/update the
limits, without deciding whether to commit them. The caller should
own the limits update and commit it as appropriate for its locking
context.

Thanks,
--Nilay


  parent reply	other threads:[~2026-09-11 10:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10  8:11 [PATCH v2 0/8] md: don't wait for q->limits_lock while md holds back I/O Jack Wang
2026-09-10  8:11 ` [PATCH v2 1/8] md: pass a queue_limits down to ->hot_add_disk() Jack Wang
2026-09-10  8:31   ` sashiko-bot
2026-09-11 10:46   ` Nilay Shroff
2026-09-10  8:11 ` [PATCH v2 2/8] md: don't wait for q->limits_lock in check_sb_changes() Jack Wang
2026-09-10  8:36   ` sashiko-bot
2026-09-10  8:11 ` [PATCH v2 3/8] md: pass a queue_limits through the rdev sysfs stores Jack Wang
2026-09-10  8:11 ` [PATCH v2 4/8] md: defer the io_opt update out of the sync thread Jack Wang
2026-09-10  8:37   ` sashiko-bot
2026-09-10  8:11 ` [PATCH v2 5/8] md: take q->limits_lock before locking and suspending the array Jack Wang
2026-09-10  8:51   ` sashiko-bot
2026-09-10  8:11 ` [PATCH v2 6/8] md: pass a queue_limits through ->run() Jack Wang
2026-09-10  8:49   ` sashiko-bot
2026-09-11 10:54   ` Nilay Shroff [this message]
2026-09-10  8:11 ` [PATCH v2 7/8] md: open new legs before locking the array Jack Wang
2026-09-10  8:48   ` sashiko-bot
2026-09-10  8:11 ` [PATCH v2 8/8] md: link a new leg's holder " Jack Wang

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=ec866125-6e45-4977-bb01-b13697fd3a8c@linux.ibm.com \
    --to=nilay@linux.ibm.com \
    --cc=abd.masalkhi@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=dlemoal@kernel.org \
    --cc=dm-devel@lists.linux.dev \
    --cc=hch@lst.de \
    --cc=jinpu.wang@cloud.ionos.com \
    --cc=jinpu.wang@ionos.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=magiclinan@didiglobal.com \
    --cc=mpatocka@redhat.com \
    --cc=snitzer@kernel.org \
    --cc=song@kernel.org \
    --cc=tom.leiming@gmail.com \
    --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 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.