[lkml]   [2018]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH v2] Minimal non-child process exit notification support
On November 1, 2018 8:06:52 AM GMT+01:00, Aleksa Sarai <> wrote:
>On 2018-11-01, Aleksa Sarai <> wrote:
>> On 2018-10-29, Daniel Colascione <> 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
>> > 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
>> > 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
>> > 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
>> > and wait for process death.
>> I agree with the need for this interface (with a few caveats), but
>> are a few points I'd like to make:
>> * I don't think that making a new procfile is necessary. When you
>> /proc/$pid you already have a handle for the underlying process,
>> you can already poll to check whether the process has died
>> 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
>> 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
>> 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
>> have to have it, can we at least provide as much information as you
>> from proc_connector -- such as the exit status?). Also maybe we
>> 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)?

Please make sure to run against your patches
if you haven't already done so to make sure that the right people are
I would suggest to a least Cc Eric, Serge, Andy, Kees, and Oleg.

>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.

 \ /
  Last update: 2018-11-01 10:59    [W:0.071 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site