Date: Mon, 26 Sep 2011 02:06:20 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-net@freebsd.org, dave jones <s.dave.jones@gmail.com> Subject: Re: Kernel panic on FreeBSD 9.0-beta2 Message-ID: <CACqU3MXeYm95VosMm97f03X=SRh8z%2BLyaCsGVPVWTxVjKQnorg@mail.gmail.com> In-Reply-To: <CAJ-Vmom-177OkdUXjz%2BZLqbaqn=p%2BuTGypiVuMqdeXgdOgb4hQ@mail.gmail.com> References: <CANf5e8aG4go4M_vsRExUsJB_sjaN5x-QK-TCDAhSH64JSo0mdQ@mail.gmail.com> <CACqU3MXStMMEoppvDtZS6hV4WGttbdJiF8E-ORwJ%2BQSmnTy-Yg@mail.gmail.com> <CACqU3MV-t4Va6VWUoXy1Y9FYnNJTUw1X%2BE7ik-2%2BtMVuVOV3RA@mail.gmail.com> <CAJ-Vmom-177OkdUXjz%2BZLqbaqn=p%2BuTGypiVuMqdeXgdOgb4hQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Mon, Sep 26, 2011 at 1:45 AM, Adrian Chadd <adrian@freebsd.org> wrote: > On 26 September 2011 13:41, Arnaud Lacombe <lacombar@gmail.com> wrote: >> =A0/* >> =A0 * XXX >> =A0 * This entire block sorely needs a rewrite. >> =A0 */ >> =A0 =A0 =A0 =A0if (t && >> =A0 =A0 =A0 =A0 =A0 =A0((t->inp_flags & INP_TIMEWAIT) =3D=3D 0) && >> =A0 =A0 =A0 =A0 =A0 =A0(so->so_type !=3D SOCK_STREAM || >> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_faddr.s_addr) =3D=3D INADDR_ANY) && >> =A0 =A0 =A0 =A0 =A0 =A0(ntohl(sin->sin_addr.s_addr) !=3D INADDR_ANY || >> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_laddr.s_addr) !=3D INADDR_ANY || >> =A0 =A0 =A0 =A0 =A0 =A0 (t->inp_socket->so_options & >> =A0 =A0 =A0 =A0 =A0 SO_REUSEPORT) =3D=3D 0) && >> =A0 =A0 =A0 =A0 =A0 =A0(inp->inp_cred->cr_uid !=3D >> =A0 =A0 =A0 =A0 =A0 =A0 t->inp_cred->cr_uid)) >> =A0 =A0 =A0 =A0 =A0return (EADDRINUSE); >> =A0 =A0 =A0} >> >> more specifically, `t->inp_socket' is NULL. The top comment may not be >> relevant, as it's been here for the past 8 years. > > Why would t->inp_socket be NULL at this point? > I really have no idea. This is just what gdb's disassembly and gcc's verbose assembly output led me to[0]: it crashes on the following instruction: 0xc0b235af <in_pcbbind_setup+655>: testb $0x2,0x7(%eax) 0xc0b235b3 <in_pcbbind_setup+659>: jne 0xc0b235c7 <in_pcbbind_setup+679> for which gcc originally generated: testb $2, 7(%eax) #, <variable>.so_options jne .L523 Test of the second bit at offset 0x7 is consistent with `(t->inp_socket->so_options & SO_REUSEPORT) =3D=3D 0', and that instruction is followed by a bunch of `cr_uid' checks: movl 48(%edi), %eax # <variable>.inp_cred, <variable>.inp_cred movl 48(%edx), %edx # <variable>.inp_cred, <variable>.inp_cred movl 4(%eax), %eax # <variable>.cr_uid, <variable>.cr_uid cmpl 4(%edx), %eax # <variable>.cr_uid, <variable>.cr_uid jne .L535 #, matching gdb disassembly: 0xc0b235b5 <in_pcbbind_setup+661>: mov 0x30(%edi),%eax 0xc0b235b8 <in_pcbbind_setup+664>: mov 0x30(%edx),%edx 0xc0b235bb <in_pcbbind_setup+667>: mov 0x4(%eax),%eax 0xc0b235be <in_pcbbind_setup+670>: cmp 0x4(%edx),%eax 0xc0b235c1 <in_pcbbind_setup+673>: jne 0xc0b236be <in_pcbbind_setup+926> moreover, .L535 terminates the function and returns EADDRINUSE. That said, I agree, this only tells "where" and "what", not "why" we ended up in this situation :-) - Arnaud [0]: and I'd be glad to be wrong, provided the other side provides a more meaningful answer :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MXeYm95VosMm97f03X=SRh8z%2BLyaCsGVPVWTxVjKQnorg>