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;
MIME-Version: 1.0
In-Reply-To: <4beaaae77bea4cc5b4cc15504331c9a9@AcuMS.aculab.com>
References: <20181029175322.189042-1-dancol@google.com> <4beaaae77bea4cc5b4cc15504331c9a9@AcuMS.aculab.com>
From:   Daniel Colascione <dancol@google.com>
Date:   Wed, 31 Oct 2018 12:56:12 +0000
Message-ID: <CAKOZuetR6_ztfJOe4TMVCX2J5sfuP8XBtG66hmsDkx-KH=CpJw@mail.gmail.com>
Subject: Re: [RFC PATCH] Minimal non-child process exit notification support
To:     David Laight <David.Laight@aculab.com>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "timmurray@google.com" <timmurray@google.com>,
        "joelaf@google.com" <joelaf@google.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Oct 31, 2018 at 12:27 PM, David Laight <David.Laight@aculab.com> wrote:
> From: Daniel Colascione
>> Sent: 29 October 2018 17:53
>>
>> 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 do you need an extra file?

Because no current file suffices.

> It ought to be possible to use poll() to wait for POLLERR having set
> 'events' to zero on any of the nodes in /proc/pid - or even on
> the directory itself.

That doesn't actually work today. And waiting on a directory with
POLLERR would be very weird, since directories in general don't do
things like blocking reads or poll support. A separate file with
self-contained, well-defined semantics is cleaner.

> Indeed, to avoid killing the wrong process you need to have opened
> some node of /proc/pid/* (maybe cmdline) before sending the kill
> signal.

The kernel really needs better documentation of the semantics of
procfs file descriptors. You're not the only person to think,
mistakenly, that keeping a reference to a /proc/$PID/something FD
reserves $PID and prevents it being used for another process. Procfs
FDs do no such thing. kill(2) is unsafe whether or not
/proc/pid/cmdline or any other /proc file is open.