Date: Sun, 16 Feb 2014 18:12:35 -0700 From: Chris Torek <torek@torek.net> To: Mikolaj Golub <trociny@freebsd.org> Cc: hackers@freebsd.org, Photo stuff <w-info2@xs4all.nl> Subject: Re: The sonewconn listen queue overflow issue Message-ID: <201402170112.s1H1CZlR064210@elf.torek.net> In-Reply-To: Your message of "Sun, 16 Feb 2014 23:58:43 %2B0200." <20140216215842.GB14237@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Unfortunately, netstat(1) shows tcpcb address for TCP sockets, >while in debug messages like above the socket's pcb is printed. This happens because, in the place where the listen queue overflow occurs, we do not have access to that which would allow identifying the specific overflowing queue. Specifically, we only know the socket, and a PCB for it (so_pcb), and that happens to be an inpcb rather than a tcpcb, in the case of a TCP socket. (I'm not sure why the socket pcb is the inpcb in the first place. Seems like the whole system could have been designed to work from top down to bottom: so_pcb is the tcp or udp block, and from there we get the inpcb, etc. [This would match so_proto being the TCP or UDP protocol, etc.] But it wasn't, and reversing that is too painful now.) >It looks like the simplest way to assiciate a socket with the >reported pcb address is to hack netstat(1) to output pcb instead >of tcpcb: [snip patch] That's kind of going backwards though: dumbing down netstat just to handle some deliberate ignorance in the kernel. :-) I think a better fix might be to have a "report listen-queue overflow" function in the protocol (so_proto or its pr_usrreqs -- season to taste). For tcp sockets this could log the local address; other protocols would log something else as appropriate; and For backwards compatibility, if there is no reporting function, the existing code can remain as-is. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402170112.s1H1CZlR064210>