On Fri, Mar 01, 2019 at 04:16:27PM +0100, Michael Kerrisk (man-pages) wrote: > Hello Tycho, > > On 3/1/19 3:53 PM, Tycho Andersen wrote: > > On Thu, Feb 28, 2019 at 01:52:19PM +0100, Michael Kerrisk (man-pages) wrote: > >>> +a notification will be sent to this fd. See "Userspace Notification" below for > >> > >> s/fd/file descriptor/ throughout please. > > > > Will do. > > > >>> +more details. > >> > >> I think the description here could be better worded as something like: > >> > >> SECCOMP_FILTER_FLAG_NEW_LISTENER > >> Register a new filter, as usual, but on success return a > >> new file descriptor that provides user-space notifications. > >> When the filter returns SECCOMP_RET_USER_NOTIF, a notification > >> will be provided via this file descriptor. The close-on-exec > >> flag is automatically set on the new file descriptor. ... > >> > >>> .RE > >>> .TP > >>> .BR SECCOMP_GET_ACTION_AVAIL " (since Linux 4.14)" > >>> @@ -606,6 +613,17 @@ file. > >>> .TP > >>> .BR SECCOMP_RET_ALLOW > >>> This value results in the system call being executed. > >>> +.TP > >>> +.BR SECCOMP_RET_USER_NOTIF " (since Linux 4.21)" > >> > >> Please see the start of this hanging list in the manual page. > >> Can you confirm that SECCOMP_RET_USER_NOTIF really is the lowest > >> in the precedence order of all of the filter return values? > > > > Oh, no, I didn't realize it was in a particular order. I'll switch it. > > Just for my immediate education (I'm experimenting right now), > where/how does it fit in the precedence order? In between RET_ERRNO and RET_TRACE; see include/uapi/linux/seccomp.h for details. Tycho
