All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-block@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-kernel@vger.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Mike Christie <michael.christie@oracle.com>,
	linux-nvme@lists.infradead.org, Jens Axboe <axboe@kernel.dk>,
	linux-scsi@vger.kernel.org, Sagi Grimberg <sagi@grimberg.me>
Subject: Re: [PATCH v2 3/4] block: add IOC_PR_READ_KEYS ioctl
Date: Mon, 1 Dec 2025 11:33:06 -0500	[thread overview]
Message-ID: <20251201163306.GF866564@fedora> (raw)
In-Reply-To: <20251201064016.GC19461@lst.de>

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

On Mon, Dec 01, 2025 at 07:40:16AM +0100, Christoph Hellwig wrote:
> On Thu, Nov 27, 2025 at 10:54:23AM -0500, Stefan Hajnoczi wrote:
> > +static int blkdev_pr_read_keys(struct block_device *bdev, blk_mode_t mode,
> > +		struct pr_read_keys __user *arg)
> > +{
> > +	const struct pr_ops *ops = bdev->bd_disk->fops->pr_ops;
> > +	struct pr_keys *keys_info __free(kfree) = NULL;
> 
> Please avoid the use of the __free mess and write readable and maintainable
> code instead.

Okay.

> > +	struct pr_read_keys inout;
> 
> Inout is not a very good variable name, as it doesn't really have much
> of meaning.  

It's the ioctl argument. I will change it to read_keys in the next
revision. I'm not sure if that's any better, but it reminds us which
struct this is.

> > +	if (copy_from_user(&inout, arg, sizeof(inout)))
> > +		return -EFAULT;
> > +
> > +	/*
> > +	 * 64-bit hosts could handle more keys than 32-bit hosts, but this
> > +	 * limit is more than enough in practice.
> > +	 */
> > +	if (inout.num_keys > (U32_MAX - sizeof(*keys_info)) /
> > +	                     sizeof(keys_info->keys[0]))
> > +		return -EINVAL;
> > +
> > +	keys_info_len = struct_size(keys_info, keys, inout.num_keys);
> 
> Do the size check on the calculate len here?

Yes, that's better. Checking SIZE_MAX also gets rid of the 32-bit vs
64-bit host comment.

> > +		return ret;
> > +
> > +	/* Copy out individual keys */
> > +	keys_ptr = u64_to_user_ptr(inout.keys_ptr);
> > +	num_copy_keys = min(inout.num_keys, keys_info->num_keys);
> > +	keys_copy_len = num_copy_keys * sizeof(keys_info->keys[0]);
> 
> num_copy_keys is only used once, so maybe drop it?

Will fix.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

  reply	other threads:[~2025-12-01 16:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-27 15:54 [PATCH v2 0/4] block: add IOC_PR_READ_KEYS and IOC_PR_READ_RESERVATION ioctls Stefan Hajnoczi
2025-11-27 15:54 ` [PATCH v2 1/4] scsi: sd: reject invalid pr_read_keys() num_keys values Stefan Hajnoczi
2025-11-27 18:03   ` Hannes Reinecke
2025-12-01  6:34   ` Christoph Hellwig
2025-12-01 15:09     ` Stefan Hajnoczi
2025-12-01 16:23     ` Stefan Hajnoczi
2025-11-27 15:54 ` [PATCH v2 2/4] nvme: " Stefan Hajnoczi
2025-11-27 18:04   ` Hannes Reinecke
2025-12-01  6:36   ` Christoph Hellwig
2025-12-01 16:22     ` Stefan Hajnoczi
2025-12-02  5:55       ` Christoph Hellwig
2025-12-01  7:11   ` Chaitanya Kulkarni
2025-12-01  7:27     ` Christoph Hellwig
2025-11-27 15:54 ` [PATCH v2 3/4] block: add IOC_PR_READ_KEYS ioctl Stefan Hajnoczi
2025-11-27 18:06   ` Hannes Reinecke
2025-12-01  6:40   ` Christoph Hellwig
2025-12-01 16:33     ` Stefan Hajnoczi [this message]
2025-11-27 15:54 ` [PATCH v2 4/4] block: add IOC_PR_READ_RESERVATION ioctl Stefan Hajnoczi
2025-12-01  6:40   ` Christoph Hellwig
2025-11-29 21:44 ` [PATCH v2 0/4] block: add IOC_PR_READ_KEYS and IOC_PR_READ_RESERVATION ioctls Martin K. Petersen

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=20251201163306.GF866564@fedora \
    --to=stefanha@redhat.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=sagi@grimberg.me \
    /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.