From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [RFC] virtio: Support releasing lock during kick Date: Fri, 25 Jun 2010 12:39:21 +0930 Message-ID: <201006251239.23224.rusty@rustcorp.com.au> References: <1277328242-10685-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C2286BE.40808@codemonkey.ws> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Stefan Hajnoczi , Anthony Liguori , Stefan Hajnoczi , kvm@vger.kernel.org, "Michael S. Tsirkin" To: virtualization@lists.linux-foundation.org Return-path: Received: from ozlabs.org ([203.10.76.45]:43569 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753973Ab0FYDJ3 (ORCPT ); Thu, 24 Jun 2010 23:09:29 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote: > On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori 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.