From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 17 01:12:42 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4B214C8; Mon, 17 Feb 2014 01:12:42 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FE7410B6; Mon, 17 Feb 2014 01:12:41 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s1H1CZlR064210; Sun, 16 Feb 2014 18:12:35 -0700 (MST) (envelope-from torek@torek.net) Message-Id: <201402170112.s1H1CZlR064210@elf.torek.net> From: Chris Torek To: Mikolaj Golub Subject: Re: The sonewconn listen queue overflow issue In-reply-to: Your message of "Sun, 16 Feb 2014 23:58:43 +0200." <20140216215842.GB14237@gmail.com> Date: Sun, 16 Feb 2014 18:12:35 -0700 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Sun, 16 Feb 2014 18:12:35 -0700 (MST) Cc: hackers@freebsd.org, Photo stuff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 01:12:42 -0000 >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