From: Mike Snitzer <snitzer@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Ming Lei <ming.lei@redhat.com>,
axboe@kernel.dk, dm-devel@lists.linux.dev,
linux-block@vger.kernel.org, Marco Patalano <mpatalan@redhat.com>,
Ewan Milne <emilne@redhat.com>,
linux-raid@vger.kernel.org
Subject: Re: [PATCH for-6.10-rc1] block: fix blk_validate_limits() to properly handle stacked devices
Date: Thu, 23 May 2024 11:48:50 -0400 [thread overview]
Message-ID: <Zk9lYpthswuegMhn@kernel.org> (raw)
In-Reply-To: <20240523154435.GA1783@lst.de>
On Thu, May 23, 2024 at 05:44:35PM +0200, Christoph Hellwig wrote:
> On Thu, May 23, 2024 at 11:38:21AM -0400, Mike Snitzer wrote:
> > Sure, we could elevate it to blk_validate_limits (and callers) but
> > adding a 'stacking' parameter is more intrusive on an API level.
> >
> > Best to just update blk_set_stacking_limits() to set a new 'stacking'
> > flag in struct queue_limits, and update blk_stack_limits() to stack
> > that flag up.
> >
> > I've verified this commit to work and have staged it in linux-next via
> > linux-dm.git's 'for-next', see:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=cedc03d697ff255dd5b600146521434e2e921815
> >
> > Jens (and obviously: Christoph, Ming and others), I'm happy to send
> > this to Linus tomorrow morning if you could please provide your
> > Reviewed-by or Acked-by. I'd prefer to keep the intermediate DM fix
> > just to "show the work and testing".
>
> A stacking flag in the limits is fundamentally wrong, please don't
> do this.
Um, how so? It serves as a hint to how the limits were constructed.
Reality is, we have stacking block devices that regularly are _not_
accounted for when people make changes to block core queue_limits
code. That is a serious problem.
Happy to see the need for the 'stacking' flag to go away in time but I
fail to see why it is "fundamentally wrong".
Mike
next prev parent reply other threads:[~2024-05-23 15:48 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 [this message]
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
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=Zk9lYpthswuegMhn@kernel.org \
--to=snitzer@kernel.org \
--cc=axboe@kernel.dk \
--cc=dm-devel@lists.linux.dev \
--cc=emilne@redhat.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=ming.lei@redhat.com \
--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.