On Sun, Feb 22, 2026 at 03:27:42PM -0800, Rick Macklem wrote:
> 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().

That'll happen only if a different thread holds the socket I/O lock,
i.e., a different thread is trying to read data from the socket at the
same time.  Can that happen here?

> > 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"?

Yes, if it's possible that something else is reading from the socket at
the same time, then we might be doing the wrong thing here, but I'm not
sure if that's possible?  Are xprts one-to-one with kernel worker
threads?

I'm pretty this hasn't changed recently either, though certainly that
part of the socket code's been refactored recently.

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

EAGAIN and EWOULDBLOCK are two names for the same thing.  errno.h
defines EWOULDBLOCK to be EAGAIN.

Reply via email to