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: >> /* >> * XXX >> * This entire block sorely needs a rewrite. >> */ >> if (t && >> ((t->inp_flags & INP_TIMEWAIT) == 0) && >> (so->so_type != SOCK_STREAM || >> ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && >> (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || >> ntohl(t->inp_laddr.s_addr) != INADDR_ANY || >> (t->inp_socket->so_options & >> SO_REUSEPORT) == 0) && >> (inp->inp_cred->cr_uid != >> t->inp_cred->cr_uid)) >> return (EADDRINUSE); >> } >> >> 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) == 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>