Merge tag 'seccomp-v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

Pull seccomp updates from Kees Cook:

 - Rework USER_NOTIF notification ordering and kill logic (Sargun
   Dhillon)

 - Improved PTRACE_O_SUSPEND_SECCOMP selftest (Jann Horn)

 - Gracefully handle failed unshare() in selftests (Yang Guang)

 - Spelling fix (Colin Ian King)

* tag 'seccomp-v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  selftests/seccomp: Fix spelling mistake "Coud" -> "Could"
  selftests/seccomp: Add test for wait killable notifier
  selftests/seccomp: Refactor get_proc_stat to split out file reading code
  seccomp: Add wait_killable semantic to seccomp user notifier
  selftests/seccomp: Ensure that notifications come in FIFO order
  seccomp: Use FIFO semantics to order notifications
  selftests/seccomp: Add SKIP for failed unshare()
  selftests/seccomp: Test PTRACE_O_SUSPEND_SECCOMP without CAP_SYS_ADMIN

1 files changed, 10 insertions, 0 deletions

diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst
index 539e9d4a4860..d1e2b9193f09 100644
--- a/Documentation/userspace-api/seccomp_filter.rst
+++ b/Documentation/userspace-api/seccomp_filter.rst
@@ -271,6 +271,16 @@ notifying process it will be replaced. The supervisor can also add an FD, and
 respond atomically by using the ``SECCOMP_ADDFD_FLAG_SEND`` flag and the return
 value will be the injected file descriptor number.
 
+The notifying process can be preempted, resulting in the notification being
+aborted. This can be problematic when trying to take actions on behalf of the
+notifying process that are long-running and typically retryable (mounting a
+filesytem). Alternatively, at filter installation time, the
+``SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV`` flag can be set. This flag makes it
+such that when a user notification is received by the supervisor, the notifying
+process will ignore non-fatal signals until the response is sent. Signals that
+are sent prior to the notification being received by userspace are handled
+normally.
+
 It is worth noting that ``struct seccomp_data`` contains the values of register
 arguments to the syscall, but does not contain pointers to memory. The task's
 memory is accessible to suitably privileged traces via ``ptrace()`` or