From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DvkQQ-0006vR-CK for qemu-devel@nongnu.org; Thu, 21 Jul 2005 19:25:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DvkQK-0006uP-VX for qemu-devel@nongnu.org; Thu, 21 Jul 2005 19:25:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DvkQK-0006ho-0o for qemu-devel@nongnu.org; Thu, 21 Jul 2005 19:25:52 -0400 Received: from [217.147.80.44] (helo=cel.leo) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dvk9V-0004gQ-CG for qemu-devel@nongnu.org; Thu, 21 Jul 2005 19:08:29 -0400 Date: Thu, 21 Jul 2005 23:58:25 +0100 From: Paul LeoNerd Evans Subject: Re: [Qemu-devel] Network code on AMD64 Message-ID: <20050721225825.GB3558@cel.leo> References: <20050721123232.7bf2456c@nim.leo> <20050721152543.GA4122@jbrown.mylinuxbox.org> <20050721215522.GA3558@cel.leo> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b5gNqxB1S1yM7hjW" Content-Disposition: inline In-Reply-To: <20050721215522.GA3558@cel.leo> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 10:55:22PM +0100, Paul LeoNerd Evans wrote: > I have determined, by the way, a much more precise location for the bug. > I can start a Knoppix image, which can reliably resolve hostnames, and > ping the host machine. I then tried a http-over-telnet, to test TCP. I > connect, send/receive data just fine. The moment I Ctrl+C the telnet, > that's when qemu dies. So I suspect the bug is related to the TCP close > code. I shall investigate further... Maybe there's some developers around who know the slirp code better than I do... But I'm finding something truely bizare here.. slirp/tcp_input.c lines 137-139: for (q =3D (struct tcpiphdr *)tp->seg_next; q !=3D (struct tcpiphdr *)tp; q =3D (struct tcpiphdr *)q->ti_next) if (SEQ_GT(q->ti_seq, ti->ti_seq)) break; We're using tp->seg_next and q->ti_next as pointers to an in-memory struct. But; tp's type is defined as: #if SIZEOF_CHAR_P =3D=3D 4 typedef struct tcpiphdr *tcpiphdrp_32; #else typedef u_int32_t tcpiphdrp_32; #endif struct tcpcb { tcpiphdrp_32 seg_next;=BB/* sequencing queue */ tcpiphdrp_32 seg_prev; ... } Which I find odd, seeing as therefore we're using a u_int32_t as a pointer to a struct..? Sounds oddly dangerous. Similarly, ti_next is really a macro for ti_i.ih_next, which is similarly typed as uint32_t. As sizeof(int) =3D=3D sizeof(void*) on i386 platforms, I'm guessing that's why the code works there. Seems quite broken here on AMD64 where sizeof(void*) =3D=3D 8.=20 Seems to me an overloaded use of fields to mean ints in some cases, and pointers in others... --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC4CiRvcPg11V/1hgRAqDdAJ9JwBKqf+Fsovm6KLrD9CBNp2PBDQCeI7jL MfTeQQadmCJwG+NeqBiepq4= =QtoL -----END PGP SIGNATURE----- --b5gNqxB1S1yM7hjW--