Page MenuHomeFreeBSD

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

Authored by markj on Sep 11 2021, 6:25 PM.
Tags
None
Referenced Files
F81672085: D31915.diff
Fri, Apr 19, 5:56 PM
Unknown Object (File)
Thu, Mar 28, 2:41 PM
Unknown Object (File)
Mar 7 2024, 7:04 PM
Unknown Object (File)
Feb 13 2024, 5:40 AM
Unknown Object (File)
Jan 10 2024, 2:19 AM
Unknown Object (File)
Dec 23 2023, 3:30 AM
Unknown Object (File)
Dec 14 2023, 8:41 PM
Unknown Object (File)
Dec 7 2023, 12:23 AM
Subscribers

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
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Sep 11 2021, 6:25 PM
This revision is now accepted and ready to land.Sep 11 2021, 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.