From: Christian Brauner <christian@brauner.io>
To: Aleksa Sarai <cyphar@cyphar.com>, Daniel Colascione <dancol@google.com>
Cc: linux-kernel@vger.kernel.org, timmurray@google.com,
joelaf@google.com, Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [RFC PATCH v2] Minimal non-child process exit notification support
Date: Thu, 01 Nov 2018 10:58:09 +0100 [thread overview]
Message-ID: <09DBEEE6-57B8-4DA8-9C2B-4B19FDD53F04@brauner.io> (raw)
In-Reply-To: <20181101070652.jrc3jgdmykc27t4w@yavin>
On November 1, 2018 8:06:52 AM GMT+01:00, Aleksa Sarai <cyphar@cyphar.com> wrote:
>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)?
Please make sure to run get_maintainers.pl against your patches
if you haven't already done so to make sure that the right people are
Cc'ed.
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.
next prev parent reply other threads:[~2018-11-01 9:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 17:53 [RFC PATCH] Minimal non-child process exit notification support Daniel Colascione
2018-10-29 19:22 ` [RFC PATCH v2] " Daniel Colascione
2018-11-01 7:00 ` Aleksa Sarai
2018-11-01 7:06 ` Aleksa Sarai
2018-11-01 9:58 ` Christian Brauner [this message]
2018-11-01 9:59 ` Daniel Colascione
2018-11-01 10:47 ` Aleksa Sarai
2018-11-01 11:32 ` Daniel Colascione
2018-10-29 19:45 ` [RFC PATCH] " Joel Fernandes
2018-10-29 19:47 ` Joel Fernandes
2018-10-29 20:01 ` Daniel Colascione
2018-10-30 3:06 ` Joel Fernandes
2018-10-30 8:59 ` Daniel Colascione
2018-10-30 22:24 ` Joel Fernandes
2018-10-31 12:27 ` David Laight
2018-10-31 12:56 ` Daniel Colascione
2018-10-31 14:25 ` David Laight
2018-10-31 14:41 ` Joel Fernandes
2018-10-31 14:43 ` Joel Fernandes
2018-10-31 14:48 ` Daniel Colascione
2018-10-31 16:53 ` Daniel Colascione
[not found] ` <175DDE5D-E738-4C35-B664-6AD8B9CF446D@amacapital.net>
2018-10-31 17:44 ` Daniel Colascione
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09DBEEE6-57B8-4DA8-9C2B-4B19FDD53F04@brauner.io \
--to=christian@brauner.io \
--cc=cyphar@cyphar.com \
--cc=dancol@google.com \
--cc=joel@joelfernandes.org \
--cc=joelaf@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=timmurray@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).