diff --git a/man2/seccomp_unotify.2 b/man2/seccomp_unotify.2
index 1cc9d8ea2..a9deb6abf 100644
--- a/man2/seccomp_unotify.2
+++ b/man2/seccomp_unotify.2
@@ -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