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, 1 Nov 2018 18:06:52 +1100
From:   Aleksa Sarai <cyphar@cyphar.com>
To:     Daniel Colascione <dancol@google.com>
Cc:     linux-kernel@vger.kernel.org, timmurray@google.com,
        joelaf@google.com, christian@brauner.io,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [RFC PATCH v2] Minimal non-child process exit notification
 support
Message-ID: <20181101070652.jrc3jgdmykc27t4w@yavin>
References: <20181029175322.189042-1-dancol@google.com>
 <20181029192250.130551-1-dancol@google.com>
 <20181101070036.l24c2p432ohuwmqf@yavin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="q523ya7z4aumdipt"
Content-Disposition: inline
In-Reply-To: <20181101070036.l24c2p432ohuwmqf@yavin>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--q523ya7z4aumdipt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
> >=20
> > 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.
>=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. 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?
>=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). 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.
>=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?). 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.

--=20
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

--q523ya7z4aumdipt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEb6Gz4/mhjNy+aiz1Snvnv3Dem58FAlvapgwACgkQSnvnv3De
m5/VXA//dOMH+ASbpNogjnZluZaN6P2PnEWymuHIBenVgDdMQ3f3HpNNQfGqEPDW
d0Pezoyk8h3AyNzKxAtQzTUIFZKg7bzuchfP2TKdV9Apt5Y+BKX8q9BXQbOmPzkY
SN0yFSpT0zwPOFRRgymgJi4J55rBbXDapdoRfDay7zvSz4HrFQJbh9E8JCjILcmk
353BGSWyGbGCxm1dgsUuPpzY+of7bk1WLqL8oSIO4jcUQxM+c1BeeOOWxN0f4tDW
MlwMu6Z5qwtOw2SmovJdZgNhHsmhMyqs+JmHOxEw9ZOIA0Vx4nTUNYb5UtRiQ3hf
yUTZcqABVcXgMnV48Dx6EwQKrBr3Rf71qiHUnOtbar0jKNMOFdtaiM1KXtA3aawO
aeAD+VqtCxq0awxpT18Rr2xVlQCA+syQyoln4Rrs2Fc6zyN/tkI3imhGOOnUJLZj
cPsKPfZa1jsX0vDfhpqP0NmePnBJUubwVCZS5sF1a4IPMQw8O/No9FTCUF5H60uI
TIuZo7QwpHxl7bZOqa0PMQ+UwM1M3k1QpaCEJb4Pteo57SihkDVw9lyGlAIS2eDF
B/evkh9EreGEbv2wyN7V5xc8MSkA30SVJ6sM33U8L/a1D7GB/ZpwU4NFlpRFUFrZ
ltL0wLEEvsw85Ghh3OPyAACU880E8Xwbys1PPeO2XqeZjbTfGqQ=
=3qhz
-----END PGP SIGNATURE-----

--q523ya7z4aumdipt--