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

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

Details

Reviewers

tuexen

Group Reviewers

transport

Commits

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

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

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 41469
Build 38358: arc lint + arc unit

Event Timeline

markj created this revision.Sep 11 2021, 6:25 PM

Herald added a reviewer: transport. · View Herald TranscriptSep 11 2021, 6:25 PM

Herald added subscribers: melifaro, imp. · View Herald Transcript

markj requested review of this revision.Sep 11 2021, 6:25 PM

Harbormaster completed remote builds in B41469: Diff 94982.Sep 11 2021, 6:26 PM

tuexen accepted this revision.Sep 11 2021, 6:56 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?

In D31915#720059, @tuexen wrote:

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.

In D31915#720205, @markj wrote:

In D31915#720059, @tuexen wrote:

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.