From: Jan Kiszka <jan.kiszka@siemens.com>
To: Zhi Yong Wu <zwu.kernel@gmail.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
qemu-devel@nongnu.org, Fabien Chouteau <chouteau@adacore.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] slirp-related crash
Date: Mon, 13 Feb 2012 20:38:57 +0100 [thread overview]
Message-ID: <4F3966D1.8050300@siemens.com> (raw)
In-Reply-To: <4F396611.8070103@siemens.com>
On 2012-02-13 20:35, Jan Kiszka wrote:
> On 2012-02-13 16:27, Zhi Yong Wu wrote:
>> On Mon, Feb 13, 2012 at 4:24 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>> On 2012-02-12 19:34, Michael S. Tsirkin wrote:
>>>> It seems somewhat easy to crash qemu with slirp if we queue multiple packets.
>>>> I didn't investigate further yet so I don't know if this
>>>> is a regression. Anyone knowledgeable about slirp wants to take a look?
>>>>
>>>> /home/mst/qemu-test/bin/qemu-system-x86_64 -enable-kvm -m 1G -drive
>>>> file=/home/mst/rhel6.qcow2 -netdev user,id=bar -net
>>>> nic,netdev=bar,model=e1000,macaddr=52:54:00:12:34:57 -redir
>>>> tcp:8022::22 -vnc :1 -monitor stdio
>>>>
>>>> While guest is booting, quickly do this
>>>>
>>>> ssh localhost -p 8022
>>>> CTRL-C
>>>> ssh localhost -p 8022
>>>> CTRL-C
>>>> ssh localhost -p 8022
>>>> CTRL-C
>>>> ssh localhost -p 8022
>>>> CTRL-C
>>>
>>> Confirmed. A single canceled connection prior the interface setup is
>>> enough. Possibly something is not properly removed / cleaned up here.
>>> Will see if I find some time to debug, can't promise.
>> Interesting thing, pls give me some time, and i am trying to debug this issue.
>
> I had a look today, but haven't found a fix yet. The problem is related
> to our requeuing of packets if the target MAC is not yet known.
> Something goes terribly wrong once it gets resolved (mbuf use after
> release?). Maybe it was always wrong and the requeuing just surfaced the
> bug, dunno.
>
> After starring at the code for a while, I got the bad feeling of
> "unfixable with reasonable effort". The queuing code is horrible (well,
> like most of slirp), and the requeuing just made it worse. But maybe I'm
> just missing some trick now - yet another one that would make the code
> even more unreadable...
>
> I'm inclined to suggest a slirp rewrite (base support, not all features
> at once) as a GSOC project. QEMU really deserves something better.
>
Despite my grumbling, I would welcome any patch that fixes the bug, of
course!
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2012-02-13 19:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-12 18:34 [Qemu-devel] slirp-related crash Michael S. Tsirkin
2012-02-12 20:24 ` Jan Kiszka
2012-02-13 15:27 ` Zhi Yong Wu
2012-02-13 19:35 ` Jan Kiszka
2012-02-13 19:38 ` Jan Kiszka [this message]
2012-02-13 20:43 ` Alex Bradbury
2012-02-13 21:01 ` Jan Kiszka
2012-02-14 8:22 ` Stefan Hajnoczi
2012-02-14 10:14 ` Jan Kiszka
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=4F3966D1.8050300@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=chouteau@adacore.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=zwu.kernel@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.