linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Daniel Colascione <dancol@google.com>,
	Christian Brauner <christian@brauner.io>
Cc: Joel Fernandes <joel@joelfernandes.org>,
	Jann Horn <jannh@google.com>, Oleg Nesterov <oleg@redhat.com>,
	Florian Weimer <fweimer@redhat.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Steven Rostedt <rostedt@goodmis.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrei Vagin <avagin@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>, Michal Hocko <mhocko@suse.com>,
	Nadav Amit <namit@vmware.com>, Serge Hallyn <serge@hallyn.com>,
	Shuah Khan <shuah@kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Taehee Yoo <ap420073@gmail.com>, Tejun Heo <tj@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	kernel-team <kernel-team@android.com>,
	Tycho Andersen <tycho@tycho.ws>
Subject: Re: [PATCH RFC 1/2] Add polling support to pidfd
Date: Wed, 24 Apr 2019 10:20:34 +0200	[thread overview]
Message-ID: <f631a11b-bdaa-1b07-dda5-028bf9efbd58@metux.net> (raw)
In-Reply-To: <CAKOZueuBTwyrLtpVQaoTAgjGSgeHY7392sKv5uAYdy4XKNHKHQ@mail.gmail.com>

On 19.04.19 23:21, Daniel Colascione wrote:

>> EPOLLIN on a pidfd could very well mean that data can be read via
>> a read() on the pidfd *other* than the exit status. The read could e.g.
>> give you a lean struct that indicates the type of state transition: NOTIFY_EXIT,
>> NOTIFY_EXEC, etc.. This way we are not bound to a specific poll event indicating
>> a specific state.
>> Though there's a case to be made that EPOLLHUP could indicate process exit
>> and EPOLLIN a state change + read().
> 
> And do you imagine making read() destructive? Does that read() then
> reset the POLLIN state? You're essentially proposing that a pidfd
> provide an "event stream" interface, delivering notifications packets
> that indicate state changes like "process exited" or "process stopped"
> or "process execed". While this sort of interface is powerful and has
> some nice properties that tools like debuggers and daemon monitors
> might want to use, I think it's too complicated and error prone for
> the overwhelmingly common case of wanting to monitor process lifetime.

I don't think it's so complicated. read() + comparing a few bits
(eg. strncmp(), if the packets are strings) really isn't a big deal.

Actually, I proposed quite the same (before I read this mail).

> I like Linus' idea of just making waitid(2) (not waitpid(2), as I
> mistakenly mentioned earlier) on a pidfd act *exactly* like a
> waitid(2) on the corresponding process and making POLLIN just mean
> "waitid will succeed". It's a nice simple model that's easy to reason
> about and that makes it easy to port existing code to pidfds.

Okay, that's probably a good starting point. We could add more
sophisticated monitoring later.


--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

  parent reply	other threads:[~2019-04-24  8:22 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 17:50 [PATCH RFC 1/2] Add polling support to pidfd Joel Fernandes (Google)
2019-04-11 17:50 ` [PATCH RFC 2/2] Add selftests for pidfd polling Joel Fernandes (Google)
2019-04-12 14:51   ` Tycho Andersen
2019-04-11 20:00 ` [PATCH RFC 1/2] Add polling support to pidfd Joel Fernandes
2019-04-11 20:02   ` Christian Brauner
2019-04-11 20:20     ` Joel Fernandes
2019-04-12 21:32 ` Andy Lutomirski
2019-04-13  0:09   ` Joel Fernandes
     [not found]     ` <CAKOZuetX4jMPDtDqAvGgSNo4BHf9BOnu79ufEiULfM5X5nDyyQ@mail.gmail.com>
2019-04-13  0:56       ` Daniel Colascione
2019-04-14 18:19   ` Linus Torvalds
2019-04-16 12:04 ` Oleg Nesterov
2019-04-16 12:43   ` Oleg Nesterov
2019-04-16 19:20   ` Joel Fernandes
2019-04-16 19:32     ` Joel Fernandes
2019-04-17 13:09     ` Oleg Nesterov
2019-04-18 17:23       ` Jann Horn
2019-04-18 17:26         ` Christian Brauner
2019-04-18 17:53           ` Daniel Colascione
2019-04-19 19:02           ` Joel Fernandes
2019-04-19 19:18             ` Christian Brauner
2019-04-19 19:22               ` Christian Brauner
2019-04-19 19:42                 ` Christian Brauner
2019-04-19 19:49               ` Joel Fernandes
2019-04-19 20:01                 ` Christian Brauner
2019-04-19 21:13                   ` Joel Fernandes
2019-04-19 20:34                 ` Daniel Colascione
2019-04-19 20:57                   ` Christian Brauner
2019-04-19 21:20                     ` Joel Fernandes
2019-04-19 21:24                       ` Daniel Colascione
2019-04-19 21:45                         ` Joel Fernandes
2019-04-19 22:08                           ` Daniel Colascione
2019-04-19 22:17                             ` Christian Brauner
2019-04-19 22:37                               ` Daniel Colascione
2019-04-24  8:04                         ` Enrico Weigelt, metux IT consult
2019-04-19 21:59                       ` Christian Brauner
2019-04-20 11:51                         ` Oleg Nesterov
2019-04-20 12:26                           ` Oleg Nesterov
2019-04-20 12:35                             ` Christian Brauner
2019-04-19 23:11                       ` Linus Torvalds
2019-04-19 23:20                         ` Christian Brauner
2019-04-19 23:32                           ` Linus Torvalds
2019-04-19 23:36                             ` Daniel Colascione
2019-04-20  0:46                         ` Joel Fernandes
2019-04-19 21:21                     ` Daniel Colascione
2019-04-19 21:48                       ` Christian Brauner
2019-04-19 22:02                         ` Christian Brauner
2019-04-19 22:46                           ` Daniel Colascione
2019-04-19 23:12                             ` Christian Brauner
2019-04-19 23:46                               ` Daniel Colascione
2019-04-20  0:17                                 ` Christian Brauner
2019-04-24  9:05                                   ` Enrico Weigelt, metux IT consult
2019-04-24  9:03                                 ` Enrico Weigelt, metux IT consult
2019-04-19 22:35                         ` Daniel Colascione
2019-04-19 23:02                           ` Christian Brauner
2019-04-19 23:29                             ` Daniel Colascione
2019-04-20  0:02                               ` Christian Brauner
2019-04-24  9:17                               ` Enrico Weigelt, metux IT consult
2019-04-24  9:11                             ` Enrico Weigelt, metux IT consult
2019-04-24  8:56                         ` Enrico Weigelt, metux IT consult
2019-04-24  8:20                       ` Enrico Weigelt, metux IT consult [this message]
2019-04-19 15:43         ` Oleg Nesterov
2019-04-19 18:12       ` Joel Fernandes
2019-04-18 18:44     ` Jonathan Kowalski
2019-04-18 18:57       ` Daniel Colascione
2019-04-18 19:14         ` Linus Torvalds
2019-04-19 19:05           ` Joel Fernandes

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=f631a11b-bdaa-1b07-dda5-028bf9efbd58@metux.net \
    --to=lkml@metux.net \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ap420073@gmail.com \
    --cc=arnd@arndb.de \
    --cc=avagin@gmail.com \
    --cc=christian@brauner.io \
    --cc=dancol@google.com \
    --cc=ebiederm@xmission.com \
    --cc=fweimer@redhat.com \
    --cc=jannh@google.com \
    --cc=joel@joelfernandes.org \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mhocko@suse.com \
    --cc=namit@vmware.com \
    --cc=oleg@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=serge@hallyn.com \
    --cc=sfr@canb.auug.org.au \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tycho@tycho.ws \
    --cc=viro@zeniv.linux.org.uk \
    /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).