linux-kernel - Re: [RFC PATCH] virtio_console: link vq to port with a private pointer in struct virtqueue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Apr 2012 19:10:29 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org,
	Amit Shah <amit.shah@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [RFC PATCH] virtio_console: link vq to port with a private
 pointer in struct virtqueue

On Wed, Apr 18, 2012 at 04:34:12PM +0200, Paolo Bonzini wrote:
> Il 18/04/2012 16:21, Michael S. Tsirkin ha scritto:
> >> @@ -1872,6 +1864,8 @@ static int virtcons_restore(struct virtio_device *vdev)
> >>  	list_for_each_entry(port, &portdev->ports, list) {
> >>  		port->in_vq = portdev->in_vqs[port->id];
> >>  		port->out_vq = portdev->out_vqs[port->id];
> >> +		port->in_vq->vdev_priv = port;
> >> +		port->out_vq->vdev_priv = port;
> >>  
> >>  		fill_queue(port->in_vq, &port->inbuf_lock);
> >>  
> > 
> > Let's add an API to set this pointer.
> > Document that you must not set it after
> > probe/restore returned.
> 
> Why?

How would you prevent races if you do?

> > With an API we can actually have a BUG_ON that checks it's not modified
> > after probe.
> > 
> >> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> >> index c193ccf..6b39c1a 100644
> >> --- a/include/linux/virtio.h
> >> +++ b/include/linux/virtio.h
> >> @@ -14,6 +14,7 @@
> >>   * @callback: the function to call when buffers are consumed (can be NULL).
> >>   * @name: the name of this virtqueue (mainly for debugging)
> >>   * @vdev: the virtio device this queue was created for.
> >> + * @vdev_priv: a pointer for the virtio device to use.
> > 
> > It's for the driver actually.
> 
> Right.  However...

pointer for a device can also be misunerstood as
'pointer to a device'. Note priv below actually
gets the correct meaning however you interpret 'for'.

Better 'pointer for the virtqueue driver to use'.

> 
> >>   * @priv: a pointer for the virtqueue implementation to use.
> >>   */
> >>  struct virtqueue {
> >> @@ -21,6 +22,7 @@ struct virtqueue {
> >>  	void (*callback)(struct virtqueue *vq);
> >>  	const char *name;
> >>  	struct virtio_device *vdev;
> >> +	void *vdev_priv;
> >>  	void *priv;
> > 
> > The name is confusing: it seems to imply it's a device pointer.
> 
> ... it's private to the driver that owns vdev, hence the name.

I own a car but I'm not called Michael Car :)
driver_priv might be ok too. unfortunately virtio-pci
is also a driver so it can be misunderstood.

> > Maybe we should rename priv to something like __priv and make
> > priv useful for devices?
> 
> I wanted to go for the smallest possible changes.  Right now we have 1
> user for each member (virtio-ring vs. virtio-console) so neither member
> is really dominating.
> 
> Paolo

devices should dominate. ring is an implementation detail.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/