All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	Chaitanya Kulkarni <chaitanyak@nvidia.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH v2] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
Date: Thu, 24 Nov 2022 15:38:53 -0500	[thread overview]
Message-ID: <Y3/WXWoV1jcJnohR@fedora> (raw)
In-Reply-To: <20221124013830-mutt-send-email-mst@kernel.org>


[-- Attachment #1.1: Type: text/plain, Size: 4542 bytes --]

On Thu, Nov 24, 2022 at 01:42:37AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 23, 2022 at 10:41:46PM +0000, Chaitanya Kulkarni wrote:
> > 
> > > +/* Get lifetime information from device */
> > > +static int virtblk_ioctl_lifetime(struct virtio_blk *vblk, unsigned long arg)
> > > +{
> > > +	struct request_queue *q = vblk->disk->queue;
> > > +	struct request *req = NULL;
> > > +	struct virtblk_req *vbr;
> > > +	struct virtio_blk_lifetime lifetime;
> > > +	int ret;
> > > +
> > > +	/* The virtio_blk_lifetime struct fields follow virtio spec.
> > > +	 * There is no check/decode on values received from the device.
> > > +	 * The data is sent as is to the user.
> > > +	 */
> > 
> > Odd comment style, why not :-
> > 
> > 	/*
> > 	 * The virtio_blk_lifetime struct fields follow virtio spec.
> > 	 * There is no check/decode on values received from the device.
> > 	 * The data is sent as is to the user.
> > 	 */
> 
> most of virtio blk is like this. I don't really care much.
> 
> > > +
> > > +	/* This ioctl is allowed only if VIRTIO_BLK_F_LIFETIME
> > > +	 * feature is negotiated.
> > > +	 */
> > 
> > above comment is redundant to the below code as following code is
> > self explanatory.,..
> 
> i find it helpful personally - this point is important enough to
> stress at cost of some duplication.
> 
> > > +	if (!virtio_has_feature(vblk->vdev, VIRTIO_BLK_F_LIFETIME))
> > > +		return -ENOTTY;
> > > +
> > > +	memset(&lifetime, 0, sizeof(lifetime));
> > > +
> > > +	req = blk_mq_alloc_request(q, REQ_OP_DRV_IN, 0);
> > > +	if (IS_ERR(req))
> > > +		return PTR_ERR(req);
> > > +
> > > +	/* Write the correct type */
> > 
> > same here for above comment...
> 
> it's pretty harmless though
> 
> > > +	vbr = blk_mq_rq_to_pdu(req);
> > > +	vbr->out_hdr.type = cpu_to_virtio32(vblk->vdev, VIRTIO_BLK_T_GET_LIFETIME);
> > > +
> > > +	ret = blk_rq_map_kern(q, req, &lifetime, sizeof(lifetime), GFP_KERNEL);
> > > +	if (ret)
> > > +		goto out;
> > > +
> > > +	blk_execute_rq(req, false);
> > > +
> > > +	ret = virtblk_ioctl_result(blk_mq_rq_to_pdu(req));
> > > +	if (ret)
> > > +		goto out;
> > > +
> > > +	/* Pass the data to the user */
> > > +	if (copy_to_user((void __user *)arg, &lifetime, sizeof(lifetime))) {
> > > +		ret = -EFAULT;
> > > +		goto out;
> > 
> > there nothing here to "goto out" following is sufficient I guess :-
> > 
> > if (copy_to_user((void __user *)arg, &lifetime, sizeof(lifetime)))
> > 	ret = -EFAULT;
> 
> error handling with goto seems cleaner, easier to add code down
> the road.
> 
> > > +	}
> > > +
> > > +out:
> > > +	blk_mq_free_request(req);
> > > +	return ret;
> > > +}
> > > +
> > 
> > [...]
> > 
> >    };
> > >   
> > > +/* Get lifetime information struct for each request */
> > > +struct virtio_blk_lifetime {
> > > +	/*
> > > +	 * specifies the percentage of reserved blocks that are consumed.
> > > +	 * optional values following virtio spec:
> > > +	 * 0 - undefined
> > > +	 * 1 - normal, < 80% of reserved blocks are consumed
> > > +	 * 2 - warning, 80% of reserved blocks are consumed
> > > +	 * 3 - urgent, 90% of reserved blocks are consumed
> > > +	 */
> > > +	__le16 pre_eol_info;
> > > +	/*
> > > +	 * this field refers to wear of SLC cells and is provided in increments of 10used,
> > > +	 * and so on, thru to 11 meaning estimated lifetime exceeded. All values above 11
> > > +	 * are reserved
> > > +	 */
> > > +	__le16 device_lifetime_est_typ_a;
> > > +	/*
> > > +	 * this field refers to wear of MLC cells and is provided with the same semantics as
> > > +	 * device_lifetime_est_typ_a
> > > +	 */
> > > +	__le16 device_lifetime_est_typ_b;
> > > +};
> > > +
> > 
> > are you sure there won't be any new members ever be added in future ?
> > to make it is futuresafe I'd add padding to this structure and keep
> > the reserve bytes to the meaningful size...
> > 
> > -ck
> 
> 
> virtio has feature bits for this kind of thing, we don't do padding.

The struct defined in the VIRTIO spec is being reused in the ioctl
userspace ABI. While feature bits are used by VIRTIO, padding is common
in the Linux UAPI.

Adding padding would require decoupling the VIRTIO spec struct from the
ioctl struct. That's probably a good idea because I noticed endianness
is left to userspace due to the __le fields in the VIRTIO spec struct
and that's likely to cause userspace bugs/confusion.

I suggest defining a separate UAPI struct for this ioctl.

Stefan

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

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2022-11-24 20:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21  8:59 [PATCH v2] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support Alvaro Karsz
     [not found] ` <1bd1c77e-d8c3-b04a-4fbc-bbc85391e630@nvidia.com>
2022-11-24  6:42   ` Michael S. Tsirkin
2022-11-24 20:38     ` Stefan Hajnoczi [this message]
2022-11-24 22:02       ` Alvaro Karsz
2022-11-24 22:09       ` Alvaro Karsz
2022-11-28 19:07         ` Stefan Hajnoczi
     [not found]           ` <dc8bf007-a6f6-9824-63e1-9447335da732@nvidia.com>
2022-11-29  5:28             ` Michael S. Tsirkin
     [not found]               ` <b76ad252-3f6a-8f4b-cb2d-0a4f45860aae@nvidia.com>
2022-12-04  8:19                 ` Alvaro Karsz
2022-12-04 10:59                   ` Michael S. Tsirkin
2022-12-04 12:00                     ` Alvaro Karsz
2022-12-04 12:27                       ` Michael S. Tsirkin
2022-12-04 14:37                         ` Alvaro Karsz
2022-12-04 16:51                           ` Michael S. Tsirkin
     [not found]                   ` <ce455ec6-353b-d273-0d52-44673f4dc0cc@nvidia.com>
2022-12-05  5:43                     ` Michael S. Tsirkin
2022-11-28 20:02         ` Michael S. Tsirkin
     [not found] ` <1b8d59e1-8702-8b81-f82c-a743116da799@nvidia.com>
2022-11-24  6:46   ` Michael S. Tsirkin
2022-11-24  8:07     ` Alvaro Karsz
2022-11-24 20:35 ` Stefan Hajnoczi

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=Y3/WXWoV1jcJnohR@fedora \
    --to=stefanha@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=chaitanyak@nvidia.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=virtualization@lists.linux-foundation.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.