orking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Mon, 27 Apr 2026 14:51:48 -0700 X-Gm-Features: AVHnY4Ky-LsGlVe0KterS2sS3N9F8xrZr61WYdQYNO9nAzmB-zU4Q-4EvbLqBw4 Message-ID: Subject: Re: socket state questions To: Mark Johnston Cc: "freebsd-net@FreeBSD.org" , Gleb Smirnoff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4g4HNB25yRz3ftn X-Spamd-Bar: ---- On Mon, Apr 27, 2026 at 2:41=E2=80=AFPM Mark Johnston w= rote: > > On Sun, Apr 26, 2026 at 03:24:31PM -0700, Rick Macklem wrote: > > Hi, > > > > I'm trying to figure out what might be causing the > > crashes reported by bugzilla PR#293127. > > > > When I look in svc_vc.c I find this: > > svc_vc_create(SVCPOOL *pool, struct socket *so, size_t sendsize, > > size_t recvsize) > > { > > SVCXPRT *xprt; > > int error; > > > > SOCK_LOCK(so); > > if (so->so_state & (SS_ISCONNECTED|SS_ISDISCONNECTED)) { > > > > This "if" is testing to see if the socket should be used for listening = or > > if it one returned from "accept". For NFS, this should always be true. > > > > I'm wondering about a couple of things... > > - Should SS_ISDISCONNECTING be here, as well, or will accepted > > TCP sockets go directly from SS_ISCONNECTED to SS_ISDISCONNECTED? > > I don't think so: it's possible for TCP sockets to go through > SS_ISDISCONNECTING, but only via system calls, and soisdisconnecting() > doesn't clear SS_ISCONNECTED. > > > - Why would SS_ISDISCONNECTED be here? Can a socket go from > > SS_ISDISCONNECTED back to SS_ISCONNECTED? > > If not, the only reason I can think of is so that it will get closed = by > > svc_vc_destroy_common(), but then why not just soclose() it here? > > It was added there explicitly in commit dad14216507bf: > > commit dad14216507bfff12693742399c3540722178263 > Author: John Baldwin > Date: Mon Apr 8 19:03:01 2013 +0000 > > Fix a potential socket leak in the NFS server. If a client closes it= s > connection after it was accepted by the userland nfsd process but bef= ore > it was handled off to svc_vc_create() in the kernel, then svc_vc_crea= te() > would see it as a new listen socket and try to listen on it leaving a > dangling reference to the socket. Instead, check for disconnected so= ckets > and treat them like a connected socket. The call to pru_getaddr() sh= ould > fail and cause svc_vc_create() to fail. Note that we need to lock th= e > socket to get a consistent snapshot of so_state since there is a wind= ow > in soisdisconnected() where both flags are clear. > > On a somewhat related note, should svc_vc_create() be checking for > errors from solisten()? Maybe. I think I've mentioned before that this code path is currently never used (the solisten() variant of svc_vc_create()), afaik. rick > > > Thanks for any help with this, rick