From: Christoph Hellwig <hch@lst.de>
To: Mike Snitzer <snitzer@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, 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 17:52:17 +0200 [thread overview]
Message-ID: <20240523155217.GA2346@lst.de> (raw)
In-Reply-To: <Zk9lYpthswuegMhn@kernel.org>
On Thu, May 23, 2024 at 11:48:50AM -0400, Mike Snitzer wrote:
>
> 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.
Well, maybe we need to sure blktests covers this instead of either
impossible to run on a stock distro (device_mapper tests) or always
somehow hanging (lvm2 testsuite) separate tests..
> Happy to see the need for the 'stacking' flag to go away in time but I
> fail to see why it is "fundamentally wrong".
Because stacking limits should not in any way be built different.
Both the stacking flag and your restoring of the value just hack
around the problem instead of trying to address it. Let's use a
little time to sort this out properly instead of piling up hacks.
next prev parent reply other threads:[~2024-05-23 15:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240522025117.75568-1-snitzer@kernel.org>
[not found] ` <20240522142458.GB7502@lst.de>
[not found] ` <Zk4h-6f2M0XmraJV@kernel.org>
2024-05-23 1:52 ` dm: retain stacked max_sectors when setting queue_limits 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 [this message]
2024-05-23 16:38 ` Mike Snitzer
2024-05-23 17:05 ` Christoph Hellwig
2024-05-23 17:14 ` Mike Snitzer
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=20240523155217.GA2346@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=dm-devel@lists.linux.dev \
--cc=emilne@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=mpatalan@redhat.com \
--cc=snitzer@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).