[lkml]   [2020]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: For review: seccomp_user_notif(2) manual page [v2]
On Mon, Nov 2, 2020 at 8:50 PM Sargun Dhillon <> wrote:
> On Mon, Nov 2, 2020 at 11:45 AM Michael Kerrisk (man-pages)
> <> wrote:
> > Caveats regarding blocking system calls
> > Suppose that the target performs a blocking system call (e.g.,
> > accept(2)) that the supervisor should handle. The supervisor
> > might then in turn execute the same blocking system call.
> >
> > In this scenario, it is important to note that if the target's
> > system call is now interrupted by a signal, the supervisor is not
> > informed of this. If the supervisor does not take suitable steps
> > to actively discover that the target's system call has been
> > canceled, various difficulties can occur. Taking the example of
> > accept(2), the supervisor might remain blocked in its accept(2)
> > holding a port number that the target (which, after the
> > interruption by the signal handler, perhaps closed its listening
> > socket) might expect to be able to reuse in a bind(2) call.
> >
> > Therefore, when the supervisor wishes to emulate a blocking system
> > call, it must do so in such a way that it gets informed if the
> > target's system call is interrupted by a signal handler. For
> > example, if the supervisor itself executes the same blocking
> > system call, then it could employ a separate thread that uses the
> > SECCOMP_IOCTL_NOTIF_ID_VALID operation to check if the target is
> > still blocked in its system call. Alternatively, in the accept(2)
> > example, the supervisor might use poll(2) to monitor both the
> > notification file descriptor (so as as to discover when the
> > target's accept(2) call has been interrupted) and the listening
> > file descriptor (so as to know when a connection is available).
> >
> > If the target's system call is interrupted, the supervisor must
> > take care to release resources (e.g., file descriptors) that it
> > acquired on behalf of the target.
> >
> > Does that seem okay?
> >
> This is far clearer than my explanation. The one thing is that *just*
> poll is not good enough, you would poll, with some timeout, and when
> that timeout is hit, check if all the current notifications are valid,
> as poll isn't woken up when an in progress notification goes off

Arguably that's so terrible that it qualifies for being in the BUGS
section of the manpage.

If you want this to be fixed properly, I recommend that someone
implements my proposal from
unless you can come up with something better.

 \ /
  Last update: 2020-11-02 21:14    [W:0.049 / U:1.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site