Re: Bugzilla PR#293127 and 292884

On Sun, Feb 22, 2026 at 2:19 PM Rick Macklem <[email protected]> wrote:
>
> Hi,
>
> Could someone who is familiar with what has changed
> related to socket handling between FreeBSD 14 and 15
> please look at these bugzilla PRs.
>
> They show similar crashes, which indicate that the
> socket receive buffer has been discarded when
> soreceive() returns EWOULDBLOCK.
I've been looking at svc_vc.c and I think there needs
to be some updating done to it.

The code currently looks like...
error = soreceive(so, NULL, &uio, &m, &ctrl, &rcvflag);

if (error == EWOULDBLOCK) {
    /*
     * We must re-test for readability after
     * taking the lock to protect us in the case
     * where a new packet arrives on the socket
     * after our call to soreceive fails with
     * EWOULDBLOCK.
     */
     SOCK_RECVBUF_LOCK(so);
     if (!soreadable(so))
          xprt_inactive_self(xprt);
     SOCK_RECVBUF_UNLOCK(so);
     sx_xunlock(&xprt->xp_lock);
     return (FALSE);
}

When I look at the code in soreceive_stream(), it calls
   error = SOCK_IO_RECV_LOCK(so, SBLOCKWAIT(MGS_DONTWAIT));
which will return EWOULDBLOCK and this happens before SOCKBUF_LOCK()
in soreceive_stream_locked().

I don't think the EWOULDBLOCK here was meant to check that some other
thread has the I/O lock.  I think that EWOULDBLOCK was meant to check
for "no rcv data on socket"?

So, does someone (like markj@) know what this code should now be?
(The crashes might be because this code is just plain broken now.)

rick


>
> 292884 seems to be avoided by adding an extra
> reference count on the socket, although that extra
> reference count should not be needed.
> 293127 still happens even with the extra reference
> count on the socket.
>
> It comes down to a couple of questions..
> - Is there any way the socket receive buffer
>   mutex can be free'd even though the socket
>   still has a reference count?
> - How can a socket "go away" even thoiugh the
>   krpc has not done soclose() on it and holds a
>   reference count on the socket until soclose()?
> - For some of these cases (maybe not all), the socket
>   structure has been recycled and become a UDP socket
>   instead of a TCP socket.
>
> This krpc code has not changed in at least a
> decade, so I think the problem must be caused
> by some other change to socket and socket buffer
> handling?
>
> Thanks in advance for any help with this, rick
> ps: At this time, I do not know of any common
>       network component between the three sites
>       reporting crashes.