On November 1, 2018 8:06:52 AM GMT+01:00, Aleksa Sarai <cyp...@cyphar.com> wrote: >On 2018-11-01, Aleksa Sarai <cyp...@cyphar.com> wrote: >> On 2018-10-29, Daniel Colascione <dan...@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.
