Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 01 Nov 2018 10:58:09 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <20181101070652.jrc3jgdmykc27t4w@yavin>
References: <20181029175322.189042-1-dancol@google.com> <20181029192250.130551-1-dancol@google.com> <20181101070036.l24c2p432ohuwmqf@yavin> <20181101070652.jrc3jgdmykc27t4w@yavin>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [RFC PATCH v2] Minimal non-child process exit notification support
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>
From:   Christian Brauner <christian@brauner.io>
Message-ID: <09DBEEE6-57B8-4DA8-9C2B-4B19FDD53F04@brauner.io>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On November 1, 2018 8:06:52 AM GMT+01:00, Aleksa Sarai <cyphar@cyphar=2Ecom=
> wrote:
>On 2018-11-01, Aleksa Sarai <cyphar@cyphar=2Ecom> wrote:
>> On 2018-10-29, Daniel Colascione <dancol@google=2Ecom> wrote:
>> > This patch adds a new file under /proc/pid, /proc/pid/exithand=2E
>> > Attempting to read from an exithand file will block until the
>> > corresponding process exits, at which point the read will
>successfully
>> > complete with EOF=2E  The file descriptor supports both blocking
>> > operations and poll(2)=2E 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=2E
>> >=20
>> > Why might we want this interface? Android's lmkd kills processes in
>> > order to free memory in response to various memory pressure
>> > signals=2E It's desirable to wait until a killed process actually
>exits
>> > before moving on (if needed) to killing the next process=2E 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=2E This interface allow lmkd to give up polling and instead
>block
>> > and wait for process death=2E
>>=20
>> I agree with the need for this interface (with a few caveats), but
>there
>> are a few points I'd like to make:
>>=20
>>  * I don't think that making a new procfile is necessary=2E 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)=2E What if we just used an inotify event to tell
>>    userspace that the process has died -- to avoid userspace doing a
>>    poll loop?
>>=20
>>  * 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)=2E I was working on some patches to
>>    extend proc_connector so that it could be used inside containers
>as
>>    well as unprivileged users=2E This would be another way we could
>>    implement this=2E
>>=20
>> 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?)=2E Also maybe we
>should
>> integrate this into the exit machinery instead of this loop=2E=2E=2E
>
>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=2Epl against your patches
if you haven't already done so to make sure that the right people are=20
Cc'ed=2E
I would suggest to a least Cc Eric, Serge, Andy, Kees, and Oleg=2E

>
>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=2E I'm also a bit cautious about how
>many procfiles the eventual goal is to add=2E