This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Broken (and unnecessary) SMP locking in blktap.c

To: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Subject: Re: [Xen-devel] Broken (and unnecessary) SMP locking in blktap.c
From: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
Date: Wed, 27 Sep 2006 14:02:12 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 27 Sep 2006 14:02:45 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=CiidxSKG4Qq7LVlkbNS2/2oH9TJ4MMgUqGwMpI676AZ+sUuOIqWj0vzhF6N4mSyDZae3UUDJs5F8PTwPv63mqC8Itp39PZfcpj6A3vmPq2KV2B9JFCDBn+cQn/9j9rrOqyXJBb75BD3r395Psi+qKcV8IAHBR4OlDn9bA33yvqQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1159364478.6276.16.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1159364478.6276.16.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
The *only* reason it might be needed is to provide locking for some
hypothetical future use of req_increase() and req_decrease(), which
would need to be locked against each other.  Given that this isn't done
right now, I suggest we nuke both the locking and the (unused)
req_decrease function; that can easily be resurrected with correct
locking if we want it in the future.

Anyone mind if that function dies?

Not at all -- req_decrease is generally broken, and removing it and
the locking seem like a very good plan.  thanks.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>