From: liu ping fan <qemulist@gmail.com>
To: Jan Kiszka <jan.kiszka@siemens.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>
Subject: Re: [Qemu-devel] [RFC PATCH v4 14/15] slirp: handle race condition
Date: Fri, 19 Apr 2013 08:18:01 +0800 [thread overview]
Message-ID: <CAJnKYQnoDWvkmjzz6N5ZVdWfFB5RqAd3TyQR93UKe_TiWvs+Xw@mail.gmail.com> (raw)
In-Reply-To: <516F9D26.2020904@siemens.com>
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
Regards,
Pingfan
> Jan
>
>>
>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>> ---
>> slirp/slirp.c | 16 ++++++++++++++--
>> slirp/slirp.h | 3 +++
>> 2 files changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/slirp/slirp.c b/slirp/slirp.c
>> index 883b7bd..6bfcc67 100644
>> --- a/slirp/slirp.c
>> +++ b/slirp/slirp.c
>> @@ -206,6 +206,7 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
>>
>> slirp_init_once();
>>
>> + qemu_mutex_init(&slirp->lock);
>> slirp->restricted = restricted;
>>
>> if_init(slirp);
>> @@ -248,6 +249,7 @@ void slirp_cleanup(Slirp *slirp)
>>
>> ip_cleanup(slirp);
>> m_cleanup(slirp);
>> + qemu_mutex_destroy(&slirp->lock);
>>
>> g_free(slirp->vdnssearch);
>> g_free(slirp->tftp_prefix);
>> @@ -411,6 +413,7 @@ gboolean slirp_handler(gpointer data)
>> struct socket *so, *so_next;
>> int ret;
>>
>> + qemu_mutex_lock(&slirp->lock);
>> /*
>> * See if anything has timed out
>> */
>> @@ -594,6 +597,7 @@ gboolean slirp_handler(gpointer data)
>> }
>>
>> if_start(slirp);
>> + qemu_mutex_unlock(&slirp->lock);
>> return true;
>> }
>>
>> @@ -665,6 +669,7 @@ void slirp_input(Slirp *slirp, const uint8_t *pkt, int pkt_len)
>> return;
>>
>> proto = ntohs(*(uint16_t *)(pkt + 12));
>> + qemu_mutex_lock(&slirp->lock);
>> switch(proto) {
>> case ETH_P_ARP:
>> arp_input(slirp, pkt, pkt_len);
>> @@ -688,6 +693,7 @@ void slirp_input(Slirp *slirp, const uint8_t *pkt, int pkt_len)
>> default:
>> break;
>> }
>> + qemu_mutex_unlock(&slirp->lock);
>> }
>>
>> /* Output the IP packet to the ethernet device. Returns 0 if the packet must be
>> @@ -860,15 +866,21 @@ void slirp_socket_recv(Slirp *slirp, struct in_addr guest_addr, int guest_port,
>> const uint8_t *buf, int size)
>> {
>> int ret;
>> - struct socket *so = slirp_find_ctl_socket(slirp, guest_addr, guest_port);
>> + struct socket *so;
>> +
>> + qemu_mutex_lock(&slirp->lock);
>> + so = slirp_find_ctl_socket(slirp, guest_addr, guest_port);
>>
>> - if (!so)
>> + if (!so) {
>> + qemu_mutex_unlock(&slirp->lock);
>> return;
>> + }
>>
>> ret = soreadbuf(so, (const char *)buf, size);
>>
>> if (ret > 0)
>> tcp_output(sototcpcb(so));
>> + qemu_mutex_unlock(&slirp->lock);
>> }
>>
>> static void slirp_tcp_save(QEMUFile *f, struct tcpcb *tp)
>> diff --git a/slirp/slirp.h b/slirp/slirp.h
>> index 008360e..7ab0c70 100644
>> --- a/slirp/slirp.h
>> +++ b/slirp/slirp.h
>> @@ -135,6 +135,7 @@ void free(void *ptr);
>>
>> #include "qemu/queue.h"
>> #include "qemu/sockets.h"
>> +#include "qemu/thread.h"
>>
>> #include "libslirp.h"
>> #include "ip.h"
>> @@ -207,6 +208,8 @@ struct Slirp {
>> u_int last_slowtimo;
>> int do_slowtimo;
>>
>> + /* lock to protect slirp running both on frontend or SlirpState context */
>> + QemuMutex lock;
>> /* virtual network configuration */
>> struct in_addr vnetwork_addr;
>> struct in_addr vnetwork_mask;
>>
>
> --
> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2013-04-19 0:18 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-17 8:39 [Qemu-devel] [RFC PATCH v4 00/15] port network layer onto glib Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 01/15] util: introduce gsource event abstration Liu Ping Fan
2013-04-18 14:01 ` Stefan Hajnoczi
2013-04-19 6:52 ` liu ping fan
2013-04-19 11:59 ` Stefan Hajnoczi
2013-04-22 7:50 ` liu ping fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 02/15] net: introduce bind_ctx to NetClientInfo Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 03/15] net: port tap onto GSource Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 04/15] net: resolve race of tap backend and its peer Liu Ping Fan
2013-04-18 14:11 ` Stefan Hajnoczi
2013-04-19 5:43 ` liu ping fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 05/15] net: port vde onto GSource Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 06/15] net: port socket to GSource Liu Ping Fan
2013-04-18 14:34 ` Stefan Hajnoczi
2013-04-19 5:58 ` liu ping fan
2013-04-19 12:03 ` Stefan Hajnoczi
2013-04-22 7:52 ` liu ping fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 07/15] net: port tap-win32 onto GSource Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 08/15] net: hub use lock to protect ports list Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 09/15] net: introduce lock to protect NetQueue Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 10/15] net: introduce lock to protect NetClientState's peer's access Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 11/15] net: make netclient re-entrant with refcnt Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 12/15] slirp: make timeout local Liu Ping Fan
2013-04-18 14:22 ` Paolo Bonzini
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 13/15] slirp: make slirp event dispatch based on slirp instance, not global Liu Ping Fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 14/15] slirp: handle race condition Liu Ping Fan
2013-04-18 7:13 ` Jan Kiszka
2013-04-19 0:18 ` liu ping fan [this message]
2013-04-19 8:21 ` Jan Kiszka
2013-04-22 5:55 ` liu ping fan
2013-04-23 7:20 ` liu ping fan
2013-04-17 8:39 ` [Qemu-devel] [RFC PATCH v4 15/15] slirp: use lock to protect the slirp_instances Liu Ping Fan
2013-04-18 7:20 ` Jan Kiszka
2013-04-18 14:16 ` Paolo Bonzini
2013-04-19 6:13 ` liu ping fan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJnKYQnoDWvkmjzz6N5ZVdWfFB5RqAd3TyQR93UKe_TiWvs+Xw@mail.gmail.com \
--to=qemulist@gmail.com \
--cc=anthony@codemonkey.ws \
--cc=jan.kiszka@siemens.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).