qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Anyone familiar with the slirp code?


From: Paul LeoNerd Evans
Subject: [Qemu-devel] Anyone familiar with the slirp code?
Date: Fri, 22 Jul 2005 16:51:25 +0100
User-agent: Mutt/1.5.9i

Hi all again,

I'm looking over the slirp code, trying to work out the exact nature of
this AMD64 bug. So far I've determined that some 32bit integer fields
are being used to store struct pointers in - very bad on AMD64 because
pointers are 64 bit. From what I can tell, I can't see how the code
would ever work on any 64 bit machine - can anyone here confirm if this
is indeed the case? What I observe is an immediate segfault of Qemu
itself when the guest OS closes a TCP socket.

What is further confusing me is that I can't find parts of code that
write many of the values; only bits that read them. For example, a
search for anything on the ti_next field gives only the following hits:

./slirp/tcp_input.c:137:            q = (struct tcpiphdr *)q->ti_next)
./slirp/tcp_input.c:170:                q = (struct tcpiphdr *)(q->ti_next);
./slirp/tcp_input.c:190:                q = (struct tcpiphdr *)q->ti_next;
./slirp/tcp_input.c:218:                ti = (struct tcpiphdr *)ti->ti_next;
./slirp/tcp_input.c:305:        ti->ti_next = ti->ti_prev = 0;
./slirp/tcp_subr.c:87:  n->ti_next = n->ti_prev = 0;
./slirp/tcp_subr.c:170: ti->ti_next = ti->ti_prev = 0;
./slirp/tcp_subr.c:288:         t = (struct tcpiphdr *)t->ti_next;
./slirp/tcpip.h:47:#define      ti_next         ti_i.ih_next

There are no hits for ih_next directly on its own, other than this macro
define, and some unrelated hits in the udp.c file. I can't see anywhere
where these values are initialised, which leads me to think there must
be something odd going on with different types of struct, and pointers
to them specifically cast about between the types, and members accessed
this way. It seems to me quite a fragile way to work....

Is anyone here familiar with the way the code is intended to run..? I
would like to get to the bottom of the issue, and fix it in a proper
robust way...

-- 
Paul "LeoNerd" Evans

address@hidden
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

Attachment: signature.asc
Description: Digital signature


reply via email to

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