From: Daniel Colascione <dancol@google.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-api@vger.kernel.org, Tim Murray <timmurray@google.com>,
Joel Fernandes <joelaf@google.com>
Subject: Re: [RFC PATCH] Minimal non-child process exit notification support
Date: Wed, 31 Oct 2018 17:44:24 +0000 [thread overview]
Message-ID: <CAKOZuevXXqwJepmLNUtrU=f8jtdgdKAzUAnAA2+KVcWoMxMyFg@mail.gmail.com> (raw)
In-Reply-To: <175DDE5D-E738-4C35-B664-6AD8B9CF446D@amacapital.net>
On Wed, Oct 31, 2018 at 5:25 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> I had an old patch to do much the same thing:
It's a perennial idea. :-)
> https://lore.kernel.org/patchwork/patch/345098/
>
> Can you comment as to how your API compares to my old patch?
Sure. Basically, my approach is sort-of eventfd-esque, whereas your
approach involves adding a very unusual operation (poll support) to a
type of file (a directory) that normally doesn't support it. My
approach feels a bit more "conventional" than poll on a dfd.
Additionally, my approach is usable from the shell. In your model,
poll(2) returning *is* the notification, whereas in my approach, the
canonical notification is read() yielding EOF, with poll(2) acting
like a wakeup hint, just like for eventfd. (You can set O_NONBLOCK on
the exithand FD just like you would any other FD.)
The use of read() for notification of exit also allows for a simple
extension in which we return a siginfo_t with exit information to the
waiter, without changing the API model. My initial patch doesn't
include this feature because I wanted to keep the initial version as
simple as possible.
> You’re using
> some fairly gnarly global synchronization
The global synchronization only kicks for a particular process exit if
somebody has used an exithand FD to wait on that process. (Or more
precisely, that process's struct signal.) Since most process exits
don't require global synchronization, I don't think the global
waitqueue for exithand is a big problem, but if it is, there are
options for fixing it.
> , and that seems unnecessary
It is necessary, and I don't see how your patch is correct. In your
proc_task_base_poll, you call poll_wait() with &task->detach_wqh. What
prevents that waitqueue disappearing (and the poll table waitqueue
pointer dangling) immediately after proc_task_base_poll returns? The
proc_inode maintains a reference to a struct pid, not a task_struct,
but your waitqueue lives in task_struct.
The waitqueue living in task_struct is also wrong in the case that a
multithreaded program execs from a non-main thread; in this case (if
I'm reading the code in exec.c right) we destroy the old main thread
task_struct and have the caller-of-exec's task_struct adopt the old
main thread's struct pid. That is, identity-continuity of struct task
is not the same as identity-continuity of the logical thread group.
prev parent reply other threads:[~2018-10-31 17:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 17:53 [RFC PATCH] Minimal non-child process exit notification support Daniel Colascione
2018-10-29 19:22 ` [RFC PATCH v2] " Daniel Colascione
2018-11-01 7:00 ` Aleksa Sarai
2018-11-01 7:06 ` Aleksa Sarai
2018-11-01 9:58 ` Christian Brauner
2018-11-01 9:59 ` Daniel Colascione
2018-11-01 10:47 ` Aleksa Sarai
2018-11-01 11:32 ` Daniel Colascione
2018-10-29 19:45 ` [RFC PATCH] " Joel Fernandes
2018-10-29 19:47 ` Joel Fernandes
2018-10-29 20:01 ` Daniel Colascione
2018-10-30 3:06 ` Joel Fernandes
2018-10-30 8:59 ` Daniel Colascione
2018-10-30 22:24 ` Joel Fernandes
2018-10-31 12:27 ` David Laight
2018-10-31 12:56 ` Daniel Colascione
2018-10-31 14:25 ` David Laight
2018-10-31 14:41 ` Joel Fernandes
2018-10-31 14:43 ` Joel Fernandes
2018-10-31 14:48 ` Daniel Colascione
2018-10-31 16:53 ` Daniel Colascione
[not found] ` <175DDE5D-E738-4C35-B664-6AD8B9CF446D@amacapital.net>
2018-10-31 17:44 ` Daniel Colascione [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKOZuevXXqwJepmLNUtrU=f8jtdgdKAzUAnAA2+KVcWoMxMyFg@mail.gmail.com' \
--to=dancol@google.com \
--cc=joelaf@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=timmurray@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).