From: Paul LeoNerd Evans <leonerd@leonerd.org.uk>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Anyone familiar with the slirp code?
Date: Fri, 22 Jul 2005 16:51:25 +0100 [thread overview]
Message-ID: <20050722155125.GC3558@cel.leo> (raw)
[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]
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
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2005-07-22 16:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-22 15:51 Paul LeoNerd Evans [this message]
2005-07-22 16:47 ` [Qemu-devel] Anyone familiar with the slirp code? John R. Hogerhuis
2005-07-22 18:14 ` Paul LeoNerd Evans
2005-07-22 18:45 ` Gwenole Beauchesne
2005-07-22 22:05 ` Jim C. Brown
2005-07-22 22:53 ` Gwenole Beauchesne
2005-07-23 4:15 ` Jim C. Brown
2005-07-24 18:09 ` Adrian Smarzewski
2005-07-22 22:29 ` Josh Metzler
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=20050722155125.GC3558@cel.leo \
--to=leonerd@leonerd.org.uk \
--cc=qemu-devel@nongnu.org \
/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).