qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] slirp-related crash


From: Jan Kiszka
Subject: Re: [Qemu-devel] slirp-related crash
Date: Mon, 13 Feb 2012 20:35:45 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-02-13 16:27, Zhi Yong Wu wrote:
> On Mon, Feb 13, 2012 at 4:24 AM, Jan Kiszka <address@hidden> 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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]