@@ -250,14 +250,14 @@ Users can read via ``ioctl(SECCOMP_IOCTL_NOTIF_RECV)`` (or ``poll()``) on a
250
250
seccomp notification fd to receive a ``struct seccomp_notif ``, which contains
251
251
five members: the input length of the structure, a unique-per-filter ``id ``,
252
252
the ``pid `` of the task which triggered this request (which may be 0 if the
253
- task is in a pid ns not visible from the listener's pid namespace), a `` flags ``
254
- member which for now only has `` SECCOMP_NOTIF_FLAG_SIGNALED ``, representing
255
- whether or not the notification is a result of a non-fatal signal, and the
256
- `` data `` passed to seccomp. Userspace can then make a decision based on this
257
- information about what to do, and `` ioctl(SECCOMP_IOCTL_NOTIF_SEND) `` a
258
- response, indicating what should be returned to userspace. The `` id `` member of
259
- `` struct seccomp_notif_resp `` should be the same ``id `` as in ``struct
260
- seccomp_notif ``.
253
+ task is in a pid ns not visible from the listener's pid namespace). The
254
+ notification also contains the `` data `` passed to seccomp, and a filters flag.
255
+ The structure should be zeroed out prior to calling the ioctl.
256
+
257
+ Userspace can then make a decision based on this information about what to do,
258
+ and `` ioctl(SECCOMP_IOCTL_NOTIF_SEND) `` a response, indicating what should be
259
+ returned to userspace. The ``id `` member of ``struct seccomp_notif_resp `` should
260
+ be the same `` id `` as in `` struct seccomp_notif ``.
261
261
262
262
It is worth noting that ``struct seccomp_data `` contains the values of register
263
263
arguments to the syscall, but does not contain pointers to memory. The task's
0 commit comments