lkml.org 
[lkml]   [2018]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v2] Minimal non-child process exit notification support
    On 2018-11-01, Aleksa Sarai <cyphar@cyphar.com> wrote:
    > On 2018-10-29, Daniel Colascione <dancol@google.com> wrote:
    > > This patch adds a new file under /proc/pid, /proc/pid/exithand.
    > > Attempting to read from an exithand file will block until the
    > > corresponding process exits, at which point the read will successfully
    > > complete with EOF. The file descriptor supports both blocking
    > > operations and poll(2). It's intended to be a minimal interface for
    > > allowing a program to wait for the exit of a process that is not one
    > > of its children.
    > >
    > > Why might we want this interface? Android's lmkd kills processes in
    > > order to free memory in response to various memory pressure
    > > signals. It's desirable to wait until a killed process actually exits
    > > before moving on (if needed) to killing the next process. Since the
    > > processes that lmkd kills are not lmkd's children, lmkd currently
    > > lacks a way to wait for a process to actually die after being sent
    > > SIGKILL; today, lmkd resorts to polling the proc filesystem pid
    > > entry. This interface allow lmkd to give up polling and instead block
    > > and wait for process death.
    >
    > I agree with the need for this interface (with a few caveats), but there
    > are a few points I'd like to make:
    >
    > * I don't think that making a new procfile is necessary. When you open
    > /proc/$pid you already have a handle for the underlying process, and
    > you can already poll to check whether the process has died (fstatat
    > fails for instance). What if we just used an inotify event to tell
    > userspace that the process has died -- to avoid userspace doing a
    > poll loop?
    >
    > * There is a fairly old interface called the proc_connector which gives
    > you global fork+exec+exit events (similar to kevents from FreeBSD
    > though much less full-featured). I was working on some patches to
    > extend proc_connector so that it could be used inside containers as
    > well as unprivileged users. This would be another way we could
    > implement this.
    >
    > I'm really not a huge fan of the "blocking read" semantic (though if we
    > have to have it, can we at least provide as much information as you get
    > from proc_connector -- such as the exit status?). Also maybe we should
    > integrate this into the exit machinery instead of this loop...

    In addition, given that you've posted two patches in the similar vein
    but as separate patchsets -- would you mind re-sending them as a single
    patchset (with all the relevant folks added to Cc)?

    If the idea is to extend /proc/$pid to allow for various
    fd-as-process-handle operations (which I agree with in principle), then
    they should be a single patchset. I'm also a bit cautious about how
    many procfiles the eventual goal is to add.

    --
    Aleksa Sarai
    Senior Software Engineer (Containers)
    SUSE Linux GmbH
    <https://www.cyphar.com/>
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2018-11-01 08:08    [W:16.935 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site