From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@lst.de>, Hannes Reinecke <hare@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, Mike Snitzer <snitzer@kernel.org>,
linux-block@vger.kernel.org, dm-devel@lists.linux.dev
Subject: Re: [PATCH] block: blk_set_stacking_limits() doesn't validate
Date: Fri, 24 May 2024 11:56:17 +0200 [thread overview]
Message-ID: <6658470a-fce2-4570-ab2d-6eb28f2fc421@suse.de> (raw)
In-Reply-To: <20240524073957.GB16336@lst.de>
On 5/24/24 09:39, Christoph Hellwig wrote:
> On Fri, May 24, 2024 at 08:21:19AM +0200, Hannes Reinecke wrote:
>> blk_validate_zoned_limits() checks whether any of the zoned limits
>> are set for non-zoned limits. As blk_set_stacking_limits() sets
>> max_zone_append_sectors() it'll fail to validate.
>
> Except that you now broke it for zone devices. Normally if we are
> not building a stacked zoned device there should at least be one
> underlying device that has a zero max_zone_append_limit, thus lowering
> the stacked device limit to 0. I guess you have a scenario where that
> is not the case, so please explain it so that we can fix it.
>
I just found it weird that a simple 'memset' for the initial device
configuration and then calling blk_set_stacking_limits() will lead to a
failure in blk_validate_limits() ...
But I'll relent; this had been coming up during large block testing with
NVMe, but was only tangentially related.
So I'll retract it.
Cheers,
Hannes
next prev parent reply other threads:[~2024-05-24 9:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 6:21 [PATCH] block: blk_set_stacking_limits() doesn't validate Hannes Reinecke
2024-05-24 7:39 ` Christoph Hellwig
2024-05-24 9:56 ` Hannes Reinecke [this message]
2024-05-24 9:58 ` Christoph Hellwig
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=6658470a-fce2-4570-ab2d-6eb28f2fc421@suse.de \
--to=hare@suse.de \
--cc=axboe@kernel.dk \
--cc=dm-devel@lists.linux.dev \
--cc=hare@kernel.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--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