From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:51555)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1UT6Za-0003Yn-UO
	for qemu-devel@nongnu.org; Fri, 19 Apr 2013 04:21:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1UT6ZW-0004JS-H5
	for qemu-devel@nongnu.org; Fri, 19 Apr 2013 04:21:34 -0400
Received: from david.siemens.de ([192.35.17.14]:21019)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1UT6ZW-0004Iw-7Z
	for qemu-devel@nongnu.org; Fri, 19 Apr 2013 04:21:30 -0400
Message-ID: <5170FE7F.3050904@siemens.com>
Date: Fri, 19 Apr 2013 10:21:19 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <1366187964-14265-1-git-send-email-qemulist@gmail.com>
	<1366187964-14265-15-git-send-email-qemulist@gmail.com>
	<516F9D26.2020904@siemens.com>
	<CAJnKYQnoDWvkmjzz6N5ZVdWfFB5RqAd3TyQR93UKe_TiWvs+Xw@mail.gmail.com>
In-Reply-To: <CAJnKYQnoDWvkmjzz6N5ZVdWfFB5RqAd3TyQR93UKe_TiWvs+Xw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH v4 14/15] slirp: handle race condition
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: liu ping fan <qemulist@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Anthony Liguori <anthony@codemonkey.ws>, mdroth <mdroth@linux.vnet.ibm.com>

On 2013-04-19 02:18, liu ping fan wrote:
> On Thu, Apr 18, 2013 at 3:13 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2013-04-17 10:39, Liu Ping Fan wrote:
>>> From: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>>>
>>> Slirp and its peer can run on different context at the same time.
>>> Using lock to protect
>>
>> What are the usage rules for this lock, what precisely is it protecting?
>> Is it ensured that we do not take the BQL while holding this one?
>>
> It protect the slirp state, since slirp can be touched by slrip_input
> called by frontend(ex, e1000), also it can be touched by its event
> handler.  With this lock, we do not need BQL

...but the BQL will, at least initially, remain to be everywhere. Every
non-converted device model will hold it while calling into Slirp. So we
have the ordering "BQL before Slirp lock" already. And we must ensure
that there is no "BQL after Slirp lock". Can you guarantee this?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux