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:   Tue, 30 Oct 2018 15:24:05 -0700
From:   Joel Fernandes <joel@joelfernandes.org>
To:     Daniel Colascione <dancol@google.com>
Cc:     Joel Fernandes <joelaf@google.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Tim Murray <timmurray@google.com>
Subject: Re: [RFC PATCH] Minimal non-child process exit notification support
Message-ID: <20181030222405.GC44036@joelaf.mtv.corp.google.com>
References: <20181029175322.189042-1-dancol@google.com>
 <CAJWu+opR5bU7b0ux5GZjO-Wu+=2F8sARke-E_y4PpH0XSubx9g@mail.gmail.com>
 <CAKOZuetEeP2QgowUL60LYoOgavN7e-WX52adzTdMQhZX0bZn-Q@mail.gmail.com>
 <CAJWu+orRE9HL2KWRzEhr2B2Owi=66x-mgjYiJV=cje-rgOeSxQ@mail.gmail.com>
 <CAKOZuetNC8Z4a5HAZkm2D4RMrTOCWj71rLJXOOtuoFaF3gGEpA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKOZuetNC8Z4a5HAZkm2D4RMrTOCWj71rLJXOOtuoFaF3gGEpA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Oct 30, 2018 at 08:59:25AM +0000, Daniel Colascione wrote:
> On Tue, Oct 30, 2018 at 3:06 AM, Joel Fernandes <joelaf@google.com> wrote:
> > On Mon, Oct 29, 2018 at 1:01 PM Daniel Colascione <dancol@google.com> wrote:
> >>
> >> Thanks for taking a look.
> >>
> >> On Mon, Oct 29, 2018 at 7:45 PM, Joel Fernandes <joelaf@google.com> wrote:
> >> >
> >> > On Mon, Oct 29, 2018 at 10:53 AM 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 proces to actually die after being sent
> >> > > SIGKILL; today, lmkd resorts to polling the proc filesystem pid
> >> >
> >> > Any idea why it needs to wait and then send SIGKILL? Why not do
> >> > SIGKILL and look for errno == ESRCH in a loop with a delay.
> >>
> >> I want to get polling loops out of the system. Polling loops are bad
> >> for wakeup attribution, bad for power, bad for priority inheritance,
> >> and bad for latency. There's no right answer to the question "How long
> >> should I wait before checking $CONDITION again?". If we can have an
> >> explicit waitqueue interface to something, we should. Besides, PID
> >> polling is vulnerable to PID reuse, whereas this mechanism (just like
> >> anything based on struct pid) is immune to it.
> >
> > The argument sounds Ok to me. I would also more details in the commit
> > message about the alternate methods to do this (such as kill polling
> > or ptrace) and why they don't work well etc so no one asks any
> > questions. Like maybe under a "other ways to do this" section. A bit
> > of googling also showed a netlink way of doing it without polling
> > (though I don't look into that much and wouldn't be surprised if its
> > more complicated)
> 
> Thanks for taking a look. I'll add to the commit message.
> 
> Re: netlink isn't enabled everywhere and is subject to lossy buffy
> overruns, AIUI. You could also monitor process exit by setting up
> ftrace and watching events, or by installing BPF that watched for
> process exit and sent a perf event. :-) All of these interfaces feel
> like abusing a "monitoring" API for controlling system operations, and
> this kind of abuse tends to have ugly failure modes. I'm looking for
> something a bit more explicit and robust.

Sounds good to me!

 - Joel