Re: [PATCH 0/2] virtio: console: add locking around control out-vq

[Asias He <asias@redhat.com>]

On Fri, Mar 29, 2013 at 04:05:00PM +0530, Amit Shah wrote:
> On (Fri) 29 Mar 2013 [08:38:49], Asias He wrote:
> > On Thu, Mar 28, 2013 at 04:58:31PM +0530, Amit Shah wrote:
> > > The in-vq operations were protected by a lock, but the out-vq
> > > operations were not.  This caused panics / errors as described in
> > > patch 2.  Fix that.
> > 
> > BTW, this looks suspicious. Why no lock here?
> > 
> >    static void remove_controlq_data(struct ports_device *portdev)
> >    {
> >            struct port_buffer *buf;
> >            unsigned int len;
> >    
> >            if (!use_multiport(portdev))
> >                    return;
> >    
> >            while ((buf = virtqueue_get_buf(portdev->c_ivq, &len)))
> >                    free_buf(buf, true);
> >    
> >            while ((buf = virtqueue_detach_unused_buf(portdev->c_ivq)))
> >                    free_buf(buf, true);
> >    }
> 
> Since this is c_ivq, you mean why can't the host be queueing up data
> in the vq while we're removing the buffers from the vq.
> 
> This function is called from two places, virtcons_remove() and
> virtcons_freeze(). In both the cases, everything is set up so the host
> can't send anything: vdev->config->reset() ensures that.
> 
> Is there something else that can be happening?

OK, this makes sense to me now. Thanks.  

> 		Amit

-- 
Asias