On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote: > On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori <anth...@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. _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
