Re: [RFC] virtio: Support releasing lock during kick

[Rusty Russell <rusty@rustcorp.com.au>]

On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote:
> On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > Shouldn't it be possible to just drop the lock before invoking
> > virtqueue_kick() and reacquire it afterwards?  There's nothing in that
> > virtqueue_kick() path that the lock is protecting AFAICT.
> 
> No, that would lead to a race condition because vq->num_added is
> modified by both virtqueue_add_buf_gfp() and virtqueue_kick().
> Without a lock held during virtqueue_kick() another vcpu could add
> bufs while vq->num_added is used and cleared by virtqueue_kick():

Right, this dovetails with another proposed change (was it Michael?)
where we would update the avail idx inside add_buf, rather than waiting
until kick.  This means a barrier inside add_buf, but that's probably
fine.

If we do that, then we don't need a lock on virtqueue_kick.

Michael, thoughts?

Thanks,
Rusty.