Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp489171imd; Thu, 1 Nov 2018 00:08:57 -0700 (PDT) X-Google-Smtp-Source: AJdET5crwYw7TdCD5B0GnmJG9zBxCCbmxzZ4ydMKYYsWFkfc8wVDv5ITmLKa2OLM4xbvW7J4c8dN X-Received: by 2002:a17:902:9a44:: with SMTP id x4-v6mr6461228plv.121.1541056137115; Thu, 01 Nov 2018 00:08:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541056137; cv=none; d=google.com; s=arc-20160816; b=DaX45psE3DMB/ZrNfMPNyUt9lSncL36KdRZFW1uiWdiOK9njJ4Qv5b+IYlJQezdjYe E4X1KbUW49+SzHY31WmqtOcOg5FQnpeLrIN5OIRUS3/s5k1izHwX6qDeqN/lPth/PUpr baB3kjLzcbuS8rDLDwf6JY+IE08pKisnXZ19qjRqUEFlPxqjGnJEUcr9uAUuSXLVOy6k U7imcQrp0JLMWuDattCK4Ykrh1e4bjmhV5YYAx7Ymth+bypUEz7lHl+U9+81oc55PEiL o1IeTD2RcnuyQbt1AVHEAU6r5V5vWX1mHQIlbGrPcRgYlLjJ9eoh4gmY/QZ6wUV2F09t XvCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=uOiDDWETOMoF/aIQfluzBO+q5hFt1E5o7kiDQkis9oE=; b=biGqQywAGqDvGQr1hF/5eRMKgcGZ0wHiYLIJZd50vKLVxClHOJxel6pLdDgrpZA4pF BXB4CuLfOqGU3nY4BUFf7F2TaZlptCO9stBsZA6Kl8nUOrRb3hzEranI06LBaGcM8BgM mF8Sp2TXDLhpR0d4pAKDBSqUNFwS446hKdCb8QURj//bPilDplZ5xyMBc+nhfRPJUUjO HYCQxkR8jvOZjy6W2aKf/IVmJR82Y7VOza+OJsKBU13PZq38Vax+Mz2skt88edghVnXw awSdUq4/NNZ5vURS2uYk9EMY5vFdMvryqklTuQYbs1eZgxvh3kfZ1QR/E+tVfxQqpbeo D2+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d2-v6si23809492pfa.160.2018.11.01.00.08.40; Thu, 01 Nov 2018 00:08:57 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727848AbeKAQIt (ORCPT + 99 others); Thu, 1 Nov 2018 12:08:49 -0400 Received: from mx1.mailbox.org ([80.241.60.212]:55766 "EHLO mx1.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727716AbeKAQIs (ORCPT ); Thu, 1 Nov 2018 12:08:48 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 753FD4BA77; Thu, 1 Nov 2018 08:07:03 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id eYYAC7niajHw; Thu, 1 Nov 2018 08:07:00 +0100 (CET) Date: Thu, 1 Nov 2018 18:06:52 +1100 From: Aleksa Sarai To: Daniel Colascione Cc: linux-kernel@vger.kernel.org, timmurray@google.com, joelaf@google.com, christian@brauner.io, Joel Fernandes 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --q523ya7z4aumdipt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 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 --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--