seccomp_user_notif.2: Small wording fix

Change "read(2) will return 0" to "read(2) may return 0".

Quoting Jann Horn:

    Maybe make that "may return 0" instead of "will return 0" -
    reading from /proc/$pid/mem can only return 0 in the
    following cases AFAICS:

    1. task->mm was already gone at open() time
    2. mm->mm_users has dropped to zero (the mm only has lazytlb
       users; page tables and VMAs are being blown away or have
       been blown away)
    3. the syscall was called with length 0

    When a process has gone away, normally mm->mm_users will
    drop to zero, but someone else could theoretically still be
    holding a reference to the mm (e.g. someone else in the
    middle of accessing /proc/$pid/mem).  (Such references
    should normally not be very long-lived though.)

    Additionally, in the unlikely case that the OOM killer just
    chomped through the page tables of the target process, I
    think the read will return -EIO (same error as if the
    address was simply unmapped) if the address is within a
    non-shared mapping. (Maybe that's something procfs could do
    better...)

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

diff --git a/man2/seccomp_user_notif.2 b/man2/seccomp_user_notif.2
index 87260d1340b2be91fea4b922abdf0a8c739adebc..86d19f4a7bbec9730be7e8a177b0913b643d0fc9 100644 (file)
--- a/man2/seccomp_user_notif.2
+++ b/man2/seccomp_user_notif.2
@@ -435,7 +435,7 @@ is still alive.
 (Note that if the target terminates after the latter step,
 a subsequent
 .BR read (2)
-from the file descriptor will return 0, indicating end of file.)
+from the file descriptor may return 0, indicating end of file.)
 .\" Jann Horn:
 .\"     the PID can be reused, but the /proc/$pid directory is
 .\"     internally not associated with the numeric PID, but,