On 2013-04-19 02:18, liu ping fan wrote: > On Thu, Apr 18, 2013 at 3:13 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >> On 2013-04-17 10:39, Liu Ping Fan wrote: >>> From: Liu Ping Fan <pingf...@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
