Page MenuHomeFreeBSD

sctp: Allow blocking on I/O locks even with non-blocking sockets
ClosedPublic

Authored by markj on Sat, Sep 11, 6:25 PM.

Details

Summary

There are two flags to request a non-blocking receive on a socket:
MSG_NBIO and MSG_DONTWAIT. They are handled a bit differently in that
soreceive_generic() and soreceive_stream() will block on the socket I/O
lock when MSG_NBIO is set, but not if MSG_DONTWAIT is set. In general,
MSG_NBIO seems to mean, "don't block if there is no data to receive" and
MSG_DONTWAIT means "don't go to sleep for any reason".

SCTP's soreceive implementation does not allow blocking on the I/O lock
if either flag is set, but this violates an assumption in
aio_process_sb(), which specifies MSG_NBIO. Change sctp_sorecvmsg() to
block on the I/O lock only if MSG_DONTWAIT is not set.

Reported by: syzbot+c7d22dbbb9aef509421d@syzkaller.appspotmail.com

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

markj requested review of this revision.Sat, Sep 11, 6:25 PM
This revision is now accepted and ready to land.Sat, Sep 11, 6:56 PM

Does it make sense to document MSG_NBIO? I don't see it mentioned in the man-page of send?

Does it make sense to document MSG_NBIO? I don't see it mentioned in the man-page of send?

I am not sure. Really I think that MSG_NBIO and MSG_DONTWAIT should do the same thing. This weird behaviour for MSG_DONTWAIT comes from the original 4.4BSD import. Skimming through the code, it looks like it *might* be due to the fact that the kernel could sbwait() without releasing the sblock in some cases, so if MSG_DONTWAIT is specified, we don't want to block at all. But sblock() now always releases the sblock.

Does it make sense to document MSG_NBIO? I don't see it mentioned in the man-page of send?

I am not sure. Really I think that MSG_NBIO and MSG_DONTWAIT should do the same thing. This weird behaviour for MSG_DONTWAIT comes from the original 4.4BSD import. Skimming through the code, it looks like it *might* be due to the fact that the kernel could sbwait() without releasing the sblock in some cases, so if MSG_DONTWAIT is specified, we don't want to block at all. But sblock() now always releases the sblock.

I don't care what exactly MSG_DONTWAIT and MSG_NBIO do. However, I would prefer that

  • the semantic of both flags is defined and documented.
  • all protocols implement these semantics.