From: Mike Snitzer <snitzer@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: dm-devel@lists.linux.dev, linux-block@vger.kernel.org,
Marco Patalano <mpatalan@redhat.com>,
Ewan Milne <emilne@redhat.com>
Subject: Re: dm: retain stacked max_sectors when setting queue_limits
Date: Thu, 23 May 2024 12:44:05 -0400 [thread overview]
Message-ID: <Zk9yVfZ8TEeEQJbw@kernel.org> (raw)
In-Reply-To: <20240523155009.GB1783@lst.de>
On Thu, May 23, 2024 at 05:50:09PM +0200, Christoph Hellwig wrote:
> On Thu, May 23, 2024 at 11:44:05AM -0400, Mike Snitzer wrote:
> > a difference on larger IOs being formed (given it is virtual
> > scsi_debug devices).
> >
> > In any case, we know I can reproduce with this scsi_debug-based mptest
> > test and Marco has verified my fix resolves the issue on his FC
> > multipath testbed.
> >
> > But I've just floated a patch to elevate the fix to block core (based
> > on Ming's suggestion):
> > https://patchwork.kernel.org/project/dm-devel/patch/Zk9i7V2GRoHxBPRu@kernel.org/
>
> I still think that is wrong. Unfortunately I can't actually reproduce
> the issue locally, but I think we want sd to set the user_max_sectors
> and stack if you want to see the limits propagated, i.e. the combined
> patch below. In the longer run I need to get SCSI out of messing
> with max_sectors directly, and the blk-mq stacking to stop looking
> at it vs just the hardware limits (or just drop the check).
This "works" but it doesn't safeguard blk_stack_limits() and
blk_validate_limits() from other drivers that weren't trained to
(ab)use max_user_sectors to get blk_validate_limits() to preserve the
underlying device's max_sectors.
But I suppose we can worry about any other similar issues if/when
reported.
Please send a proper patch to Jens so we can get this fixed for
6.10-rc1. Thanks.
Acked-by: Mike Snitzer <snitzer@kernel.org>
>
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index a7fe8e90240a6e..7a672021daee6a 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -611,6 +611,8 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
> unsigned int top, bottom, alignment, ret = 0;
>
> t->max_sectors = min_not_zero(t->max_sectors, b->max_sectors);
> + t->max_user_sectors = min_not_zero(t->max_user_sectors,
> + b->max_user_sectors);
> t->max_hw_sectors = min_not_zero(t->max_hw_sectors, b->max_hw_sectors);
> t->max_dev_sectors = min_not_zero(t->max_dev_sectors, b->max_dev_sectors);
> t->max_write_zeroes_sectors = min(t->max_write_zeroes_sectors,
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 332eb9dac22d91..f6c822c9cbd2d3 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -3700,8 +3700,10 @@ static int sd_revalidate_disk(struct gendisk *disk)
> */
> if (sdkp->first_scan ||
> q->limits.max_sectors > q->limits.max_dev_sectors ||
> - q->limits.max_sectors > q->limits.max_hw_sectors)
> + q->limits.max_sectors > q->limits.max_hw_sectors) {
> q->limits.max_sectors = rw_max;
> + q->limits.max_user_sectors = rw_max;
> + }
>
> sdkp->first_scan = 0;
>
>
>
next prev parent reply other threads:[~2024-05-23 16:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 2:51 [PATCH] dm: retain stacked max_sectors when setting queue_limits Mike Snitzer
2024-05-22 14:24 ` Christoph Hellwig
2024-05-22 16:48 ` Mike Snitzer
2024-05-22 17:37 ` Ewan Milne
2024-05-23 1:52 ` Ming Lei
2024-05-23 15:38 ` [PATCH for-6.10-rc1] block: fix blk_validate_limits() to properly handle stacked devices Mike Snitzer
2024-05-23 15:44 ` Christoph Hellwig
2024-05-23 15:48 ` Mike Snitzer
2024-05-23 15:52 ` Christoph Hellwig
2024-05-23 16:38 ` Mike Snitzer
2024-05-23 17:05 ` Christoph Hellwig
2024-05-23 17:14 ` Mike Snitzer
2024-05-23 7:16 ` dm: retain stacked max_sectors when setting queue_limits Christoph Hellwig
2024-05-23 8:27 ` Christoph Hellwig
2024-05-23 14:12 ` Mike Snitzer
2024-05-23 14:49 ` Christoph Hellwig
2024-05-23 15:44 ` Mike Snitzer
2024-05-23 15:50 ` Christoph Hellwig
2024-05-23 16:44 ` Mike Snitzer [this message]
2024-05-23 17:03 ` Christoph Hellwig
2024-05-22 20:33 ` [PATCH] " Ewan Milne
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=Zk9yVfZ8TEeEQJbw@kernel.org \
--to=snitzer@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=emilne@redhat.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=mpatalan@redhat.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.