Date: Wed, 23 Jun 2004 02:23:54 +0100 From: Bruce M Simpson <bms@spc.org> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: kern/45733: file descriptor flags and socket flags out of sync Message-ID: <20040623012354.GQ762@empiric.dek.spc.org> In-Reply-To: <Pine.NEB.3.96L.1040622210340.61099E-100000@fledge.watson.org> References: <20040623005802.GO762@empiric.dek.spc.org> <Pine.NEB.3.96L.1040622210340.61099E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 22, 2004 at 09:04:35PM -0400, Robert Watson wrote: > Since you're looking at the propagation of head so_state to new socket > so_state, you might want to look at the similar statement in sonewconn(), > which copies so_state from head to the new socket, and adds the SS_NOFDREF > flag. Should we only be propagating SS_NBIO here as well? Verdict: not proven. SS_NOFDREF implies that no file descriptor references the socket, so similar inconsistencies between the FD and the SO wouldn't apply here. The state of the socket 'head' is likely to be consistent with regards to the other SS_* flags as 'head' is a listening socket, and such sockets don't generally appear to be used for straight I/O from userland (in the PF_INET, SOCK_STREAM case, listening sockets are effectively just endpoints for servicing SYNs - all userland I/O happens through connected sockets derived from such listening sockets). It is also possible that the fix we applied for the accept1() case is incomplete; it's also possible that we should in fact have applied it here. If you could remind me of the URL of that dotfile you graphed with the socket layer call graph, that would be most useful. ;-) There are however a bunch of bits which probably shouldn't be applied to the new socket, but as above, it looks like these shouldn't be in effect for the listening socket. Regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040623012354.GQ762>