Re: Bugzilla PR#293127 and 292884

On Sun, Feb 22, 2026 at 3:21 PM Rick Macklem <[email protected]> wrote:
>
> 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.)
Oh, and it appears that soreceive_stream_locked() returns EAGAIN when
there is no data to be read and not EWOULDBLOCK.

rick

>
> 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.