From: "Javier González" <javier@javigon.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
Damien Le Moal <damien.lemoal@wdc.com>,
Hans Holmberg <hans@owltronix.com>,
linux-block@vger.kernel.org
Subject: Re: [PATCH 8/8] block: set the zone size in blk_revalidate_disk_zones atomically
Date: Tue, 3 Dec 2019 16:34:08 +0100 [thread overview]
Message-ID: <8FC173FA-576A-4425-AAE4-EE2A27C5F6BE@javigon.com> (raw)
In-Reply-To: <20191203151808.GA558@lst.de>
> On 3 Dec 2019, at 16.18, Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Dec 03, 2019 at 03:00:09PM +0100, Javier González wrote:
>>> This change also allows to check for a power of two zone size in generic
>>> code.
>>
>> I think however that this checks should remain at the driver level, or
>> at least depend on a flag that signals that the zoned device is actually
>> a power of two.
>
> The block layer requires a power of two zone size / chunk size,
> including having a BUG_ON for that requirement blk_queue_chunk_sectors.
> I'd much rather have a proper check in the zone code with proper
> diagnostics than triggering a BUG_ON..
Agree on the BUG_ON part. But since you’re looking into this part now, would it make sense to do the check in the block layer only if the driver imposes a power of two? We can also do it down the road, but seems like double work.
next prev parent reply other threads:[~2019-12-03 15:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 9:39 avoid out of bounds zone bitmap access Christoph Hellwig
2019-12-03 9:39 ` [PATCH 1/8] null_blk: fix zone size paramter check Christoph Hellwig
2019-12-03 9:39 ` [PATCH 2/8] null_blk: cleanup null_gendisk_register Christoph Hellwig
2019-12-03 9:39 ` [PATCH 3/8] block: remove the empty line at the end of blk-zoned.c Christoph Hellwig
2019-12-03 9:39 ` [PATCH 4/8] block: simplify blkdev_nr_zones Christoph Hellwig
2019-12-03 9:39 ` [PATCH 5/8] block: replace seq_zones_bitmap with conv_zones_bitmap Christoph Hellwig
2019-12-03 14:02 ` Javier González
2019-12-03 9:39 ` [PATCH 6/8] block: allocate the zone bitmaps lazily Christoph Hellwig
2019-12-03 14:03 ` Javier González
2019-12-03 9:39 ` [PATCH 7/8] block: don't handle bio based drivers in blk_revalidate_disk_zones Christoph Hellwig
2019-12-03 14:04 ` Javier González
2019-12-03 9:39 ` [PATCH 8/8] block: set the zone size in blk_revalidate_disk_zones atomically Christoph Hellwig
2019-12-03 14:00 ` Javier González
2019-12-03 15:18 ` Christoph Hellwig
2019-12-03 15:34 ` Javier González [this message]
2019-12-03 15:42 ` Christoph Hellwig
2019-12-03 17:17 ` Javier González
2019-12-03 16:00 ` avoid out of bounds zone bitmap access Jens Axboe
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=8FC173FA-576A-4425-AAE4-EE2A27C5F6BE@javigon.com \
--to=javier@javigon.com \
--cc=axboe@kernel.dk \
--cc=damien.lemoal@wdc.com \
--cc=hans@owltronix.com \
--cc=hch@lst.de \
--cc=linux-block@vger.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 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.