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
Unknown Object (File)
Thu, Jan 2, 3:47 PM
Unknown Object (File)
Sat, Dec 28, 3:10 PM
Unknown Object (File)
Wed, Dec 18, 6:58 PM
Unknown Object (File)
Nov 28 2024, 9:06 PM
Unknown Object (File)
Nov 28 2024, 9:05 PM
Unknown Object (File)
Nov 28 2024, 9:05 PM
Unknown Object (File)
Nov 28 2024, 8:41 PM
Unknown Object (File)
Nov 7 2024, 3:05 PM
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.