seccomp_unotify.2: Note when notification FD indicates as writable by select/poll/epoll

Reported-by: Tycho Andersen <tycho@tycho.pizza>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2020-10-14 07:28:40 +02:00
parent ea4d03e6b0
commit 6048506c77
1 changed files with 13 additions and 3 deletions

View File

@ -579,6 +579,7 @@ or the target has terminated.
.\" whether the target thread has picked up the response yet
.RE
.SH NOTES
.SS select()/poll()/epoll semantics
The file descriptor returned when
.BR seccomp (2)
is employed with the
@ -588,6 +589,8 @@ flag can be monitored using
.BR epoll (7),
and
.BR select (2).
These interfaces indicate that the file descriptor is ready as follows:
.IP \(bu 2
When a notification is pending,
these interfaces indicate that the file descriptor is readable.
Following such an indication, a subsequent
@ -598,10 +601,17 @@ or else failing with the error
.B EINTR
if the target has been killed by a signal or its system call
has been interrupted by a signal handler.
.IP \(bu
After the notification has been received (i.e., by the
.B SECCOMP_IOCTL_NOTIF_RECV
.BR ioctl (2)
operation), these interfaces indicate that the file descriptor is writable,
meaning that a notification response can be sent using the
.B SECCOMP_IOCTL_NOTIF_SEND
.BR ioctl (2)
operation.
.\" FIXME
.\" Interestingly, after the event had been received, the file
.\" descriptor indicates as writable (verified from the source
.\" code and by experiment). How is this useful?
.\" But (how) is the writable/(E)POLLOUT useful?
.SH BUGS
If a
.BR SECCOMP_IOCTL_NOTIF_RECV