From: Christoph Hellwig <hch@lst.de>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
linux-scsi@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v5 4/9] block: add storage element management ioctls
Date: Mon, 12 Oct 2026 16:31:46 +0200 [thread overview]
Message-ID: <20261012143146.GB8609@lst.de> (raw)
In-Reply-To: <20261012130121.1902634-5-dlemoal@kernel.org>
On Mon, Oct 12, 2026 at 10:01:16PM +0900, Damien Le Moal wrote:
> +static int blkdev_get_nr_storage_elements_ioctl(struct block_device *bdev,
> + void __user *argp)
> +{
The normal nameing would be more blkdev_ioctl_foo instead of the
ioctl at the end.
> + struct gendisk *disk = bdev->bd_disk;
> +
> + if (put_user(disk->nr_storage_elements, (unsigned int __user *)argp))
Just type the argument as unsigned int and avoid the cast?
> +static int blkdev_report_storage_elements_ioctl(struct block_device *bdev,
> + void __user *argp)
Same naming and typing nitpick here.
> +{
> + struct gendisk *disk = bdev->bd_disk;
> + struct blk_se_report *rep;
> + int ret;
> +
> + if (!argp)
> + return -EINVAL;
copy_from_user will fault on a NULL pointer, so there should be no
need for this.
> + rep = kzalloc_flex(*rep, elements, disk->nr_storage_elements);
> + if (!rep)
> + return -ENOMEM;
> +
> + if (copy_from_user(rep, argp, sizeof(struct blk_se_report))) {
> + ret = -EFAULT;
> + goto free_rep;
> + }
> +
> + if (rep->nr_elements < disk->nr_storage_elements) {
> + ret = -EINVAL;
> + goto free_rep;
> + }
Just report the number of elements the user asked for in this case?
That would also allow you to incorporate the nr storage elements query
ioctl into this one by querying for 0 descriptors and just looking at:
> + rep->nr_reported_elements = disk->nr_storage_elements;
this to size the array in userspace.
> + ret = bdev_report_storage_elements(bdev, rep->elements,
> + &rep->nr_reported_elements);
> + if (ret)
> + goto free_rep;
> +
> + if (copy_to_user(argp, rep, struct_size_t(struct blk_se_report,
> + elements, rep->nr_reported_elements)))
The indent looks a bit odd here. Also can't you use struct_size on
rep, e.g.:
if (copy_to_user(argp, rep,
struct_size(rep, elements, rep->nr_reported_elements)))
> +static int blkdev_flush_and_truncate(struct block_device *bdev,
> + blk_mode_t mode)
> +{
> + int ret;
> +
> + inode_lock(bdev->bd_mapping->host);
> + filemap_invalidate_lock(bdev->bd_mapping);
> + ret = blkdev_issue_flush(bdev->bd_disk->part0);
> + if (!ret)
> + ret = truncate_bdev_range(bdev, mode, 0,
> + bdev_nr_bytes(bdev) - 1);
> + filemap_invalidate_unlock(bdev->bd_mapping);
> + inode_unlock(bdev->bd_mapping->host);
Sashiko is obviously confused here about partitions that aren't supported
on zoned devices. The conventional zones argument isn't entirely
stupid, but also not a great one. Maybe we should add a check to just
reject the ioctls if conventional zones are present, as that would make
a mess of the depop anyway?
> +static int blkdev_remove_storage_element_ioctl(struct block_device *bdev,
> + blk_mode_t mode, void __user *argp)
The usual naming and type nit here again. I'm going to stop that now.
next prev parent reply other threads:[~2026-10-12 14:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 13:01 [PATCH v5 0/9] Add support for storage element depopulation Damien Le Moal
2026-10-12 13:01 ` [PATCH v5 1/9] block: introduce disk_zone_is_offline() Damien Le Moal
2026-10-12 13:01 ` [PATCH v5 2/9] block: refactor blk_revalidate_disk_zones() Damien Le Moal
2026-10-12 13:01 ` [PATCH v5 3/9] block: introduce storage element management Damien Le Moal
2026-10-12 14:23 ` Christoph Hellwig
2026-10-12 13:01 ` [PATCH v5 4/9] block: add storage element management ioctls Damien Le Moal
2026-10-12 14:31 ` Christoph Hellwig [this message]
2026-10-12 14:56 ` Damien Le Moal
2026-10-12 14:57 ` Christoph Hellwig
2026-10-12 14:59 ` Damien Le Moal
2026-10-12 13:01 ` [PATCH v5 5/9] zloop: add storage element emulation Damien Le Moal
2026-10-12 13:01 ` [PATCH v5 6/9] zloop: add degrade_element control command Damien Le Moal
2026-10-12 14:43 ` Christoph Hellwig
2026-10-12 13:01 ` [PATCH v5 7/9] scsi: sd: fail read commands to offline zones early Damien Le Moal
2026-10-12 14:36 ` Christoph Hellwig
2026-10-12 13:01 ` [PATCH v5 8/9] scsi: sd_zbc: always revalidate zones for disks supporting head depopulation Damien Le Moal
2026-10-12 14:37 ` Christoph Hellwig
2026-10-12 14:57 ` Damien Le Moal
2026-10-12 13:01 ` [PATCH v5 9/9] scsi: sd_zbc: define storage element management operations Damien Le Moal
2026-10-12 14:38 ` 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=20261012143146.GB8609@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox