From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: "Joel Fernandes (Google)" <joel@joelfernandes.org>,
LKML <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Daniel Colascione <dancol@google.com>,
Christian Brauner <christian@brauner.io>,
Jann Horn <jannh@google.com>,
Suren Baghdasaryan <surenb@google.com>,
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 FS Devel <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>, Oleg Nesterov <oleg@redhat.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>,
Tycho Andersen <tycho@tycho.ws>
Subject: Re: [PATCH RFC 1/2] Add polling support to pidfd
Date: Sun, 14 Apr 2019 11:19:10 -0700 [thread overview]
Message-ID: <CAHk-=wiL0GZn+kOyxzaS0igMRs95sipcc9r0ZgU2rRf=CR+fpw@mail.gmail.com> (raw)
In-Reply-To: <CALCETrV7Hw50Bh=qQX86v_6euiGqX7eNboi50_7JmfQsyVR3_A@mail.gmail.com>
On Fri, Apr 12, 2019 at 2:33 PM Andy Lutomirski <luto@kernel.org> wrote:
>
> Are you sure? I admit I'm not all that familiar with the innards of
> poll() on Linux, but I thought that the waitqueue only had to survive
> long enough to kick the polling thread and did *not* have to survive
> until poll() actually returned.
That is *not* true by default.
You can do that, but you need to make sure that your wakeup function
is one that removed itself from the wait queues. You can do that with
DEFINE_WAIT(name), which uses autoremove_wake_function(), or by using
your own auto-removing wakeup function together with
DEFINE_WAIT_FUNC() or init_waitqueue_func_entry().
But the default wake function does not remove on wakeup, and you'll
have to be around until poll() itself tears down all the tables.
In particular, the normal "poll_wait()" will use __pollwait, which does:
init_waitqueue_func_entry(&entry->wait, pollwake);
and pollwake() (which is thus what gets called at wake time) will not
remove anything from the wait queue.
So no, by default your wait queue has to stay around for the duration
of poll() (ie the duration of the file descriptor, since poll() gets a
reference to it).
You *can* play games with pollwait functions (and with wait functions
in general), but by default you should consider the wait function to
stay around.
Linus
WARNING: multiple messages have this Message-ID (diff)
From: torvalds at linux-foundation.org (Linus Torvalds)
Subject: [PATCH RFC 1/2] Add polling support to pidfd
Date: Sun, 14 Apr 2019 11:19:10 -0700 [thread overview]
Message-ID: <CAHk-=wiL0GZn+kOyxzaS0igMRs95sipcc9r0ZgU2rRf=CR+fpw@mail.gmail.com> (raw)
In-Reply-To: <CALCETrV7Hw50Bh=qQX86v_6euiGqX7eNboi50_7JmfQsyVR3_A@mail.gmail.com>
On Fri, Apr 12, 2019 at 2:33 PM Andy Lutomirski <luto at kernel.org> wrote:
>
> Are you sure? I admit I'm not all that familiar with the innards of
> poll() on Linux, but I thought that the waitqueue only had to survive
> long enough to kick the polling thread and did *not* have to survive
> until poll() actually returned.
That is *not* true by default.
You can do that, but you need to make sure that your wakeup function
is one that removed itself from the wait queues. You can do that with
DEFINE_WAIT(name), which uses autoremove_wake_function(), or by using
your own auto-removing wakeup function together with
DEFINE_WAIT_FUNC() or init_waitqueue_func_entry().
But the default wake function does not remove on wakeup, and you'll
have to be around until poll() itself tears down all the tables.
In particular, the normal "poll_wait()" will use __pollwait, which does:
init_waitqueue_func_entry(&entry->wait, pollwake);
and pollwake() (which is thus what gets called at wake time) will not
remove anything from the wait queue.
So no, by default your wait queue has to stay around for the duration
of poll() (ie the duration of the file descriptor, since poll() gets a
reference to it).
You *can* play games with pollwait functions (and with wait functions
in general), but by default you should consider the wait function to
stay around.
Linus
WARNING: multiple messages have this Message-ID (diff)
From: torvalds@linux-foundation.org (Linus Torvalds)
Subject: [PATCH RFC 1/2] Add polling support to pidfd
Date: Sun, 14 Apr 2019 11:19:10 -0700 [thread overview]
Message-ID: <CAHk-=wiL0GZn+kOyxzaS0igMRs95sipcc9r0ZgU2rRf=CR+fpw@mail.gmail.com> (raw)
Message-ID: <20190414181910.km6bPw4eotr4d_qHfIo9_1h8NSlZqneFw3BlGAHkhQg@z> (raw)
In-Reply-To: <CALCETrV7Hw50Bh=qQX86v_6euiGqX7eNboi50_7JmfQsyVR3_A@mail.gmail.com>
On Fri, Apr 12, 2019@2:33 PM Andy Lutomirski <luto@kernel.org> wrote:
>
> Are you sure? I admit I'm not all that familiar with the innards of
> poll() on Linux, but I thought that the waitqueue only had to survive
> long enough to kick the polling thread and did *not* have to survive
> until poll() actually returned.
That is *not* true by default.
You can do that, but you need to make sure that your wakeup function
is one that removed itself from the wait queues. You can do that with
DEFINE_WAIT(name), which uses autoremove_wake_function(), or by using
your own auto-removing wakeup function together with
DEFINE_WAIT_FUNC() or init_waitqueue_func_entry().
But the default wake function does not remove on wakeup, and you'll
have to be around until poll() itself tears down all the tables.
In particular, the normal "poll_wait()" will use __pollwait, which does:
init_waitqueue_func_entry(&entry->wait, pollwake);
and pollwake() (which is thus what gets called at wake time) will not
remove anything from the wait queue.
So no, by default your wait queue has to stay around for the duration
of poll() (ie the duration of the file descriptor, since poll() gets a
reference to it).
You *can* play games with pollwait functions (and with wait functions
in general), but by default you should consider the wait function to
stay around.
Linus
next prev parent reply other threads:[~2019-04-14 18:19 UTC|newest]
Thread overview: 198+ 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 ` Joel Fernandes (Google)
2019-04-11 17:50 ` joel
2019-04-11 17:50 ` [PATCH RFC 2/2] Add selftests for pidfd polling Joel Fernandes (Google)
2019-04-11 17:50 ` Joel Fernandes (Google)
2019-04-11 17:50 ` joel
2019-04-12 14:51 ` Tycho Andersen
2019-04-12 14:51 ` Tycho Andersen
2019-04-12 14:51 ` tycho
2019-04-11 20:00 ` [PATCH RFC 1/2] Add polling support to pidfd Joel Fernandes
2019-04-11 20:00 ` Joel Fernandes
2019-04-11 20:00 ` joel
2019-04-11 20:02 ` Christian Brauner
2019-04-11 20:02 ` Christian Brauner
2019-04-11 20:02 ` christian
2019-04-11 20:20 ` Joel Fernandes
2019-04-11 20:20 ` Joel Fernandes
2019-04-11 20:20 ` joel
2019-04-12 21:32 ` Andy Lutomirski
2019-04-12 21:32 ` Andy Lutomirski
2019-04-12 21:32 ` luto
2019-04-13 0:09 ` Joel Fernandes
2019-04-13 0:09 ` Joel Fernandes
2019-04-13 0:09 ` joel
[not found] ` <CAKOZuetX4jMPDtDqAvGgSNo4BHf9BOnu79ufEiULfM5X5nDyyQ@mail.gmail.com>
2019-04-13 0:56 ` Daniel Colascione
2019-04-13 0:56 ` Daniel Colascione
2019-04-13 0:56 ` dancol
2019-04-14 18:19 ` Linus Torvalds [this message]
2019-04-14 18:19 ` Linus Torvalds
2019-04-14 18:19 ` torvalds
2019-04-16 12:04 ` Oleg Nesterov
2019-04-16 12:04 ` Oleg Nesterov
2019-04-16 12:04 ` oleg
2019-04-16 12:43 ` Oleg Nesterov
2019-04-16 12:43 ` Oleg Nesterov
2019-04-16 12:43 ` oleg
2019-04-16 19:20 ` Joel Fernandes
2019-04-16 19:20 ` Joel Fernandes
2019-04-16 19:20 ` joel
2019-04-16 19:32 ` Joel Fernandes
2019-04-16 19:32 ` Joel Fernandes
2019-04-16 19:32 ` joel
2019-04-17 13:09 ` Oleg Nesterov
2019-04-17 13:09 ` Oleg Nesterov
2019-04-17 13:09 ` oleg
2019-04-18 17:23 ` Jann Horn
2019-04-18 17:23 ` Jann Horn
2019-04-18 17:23 ` jannh
2019-04-18 17:26 ` Christian Brauner
2019-04-18 17:26 ` Christian Brauner
2019-04-18 17:26 ` christian
2019-04-18 17:53 ` Daniel Colascione
2019-04-18 17:53 ` Daniel Colascione
2019-04-18 17:53 ` dancol
2019-04-19 19:02 ` Joel Fernandes
2019-04-19 19:02 ` Joel Fernandes
2019-04-19 19:02 ` joel
2019-04-19 19:18 ` Christian Brauner
2019-04-19 19:18 ` Christian Brauner
2019-04-19 19:18 ` christian
2019-04-19 19:22 ` Christian Brauner
2019-04-19 19:22 ` Christian Brauner
2019-04-19 19:22 ` christian
2019-04-19 19:42 ` Christian Brauner
2019-04-19 19:42 ` Christian Brauner
2019-04-19 19:42 ` christian
2019-04-19 19:49 ` Joel Fernandes
2019-04-19 19:49 ` Joel Fernandes
2019-04-19 19:49 ` joel
2019-04-19 20:01 ` Christian Brauner
2019-04-19 20:01 ` Christian Brauner
2019-04-19 20:01 ` christian
2019-04-19 21:13 ` Joel Fernandes
2019-04-19 21:13 ` Joel Fernandes
2019-04-19 21:13 ` joel
2019-04-19 20:34 ` Daniel Colascione
2019-04-19 20:34 ` Daniel Colascione
2019-04-19 20:34 ` dancol
2019-04-19 20:57 ` Christian Brauner
2019-04-19 20:57 ` Christian Brauner
2019-04-19 20:57 ` christian
2019-04-19 21:20 ` Joel Fernandes
2019-04-19 21:20 ` Joel Fernandes
2019-04-19 21:20 ` joel
2019-04-19 21:24 ` Daniel Colascione
2019-04-19 21:24 ` Daniel Colascione
2019-04-19 21:24 ` dancol
2019-04-19 21:45 ` Joel Fernandes
2019-04-19 21:45 ` Joel Fernandes
2019-04-19 21:45 ` joel
2019-04-19 22:08 ` Daniel Colascione
2019-04-19 22:08 ` Daniel Colascione
2019-04-19 22:08 ` dancol
2019-04-19 22:17 ` Christian Brauner
2019-04-19 22:17 ` Christian Brauner
2019-04-19 22:17 ` christian
2019-04-19 22:37 ` Daniel Colascione
2019-04-19 22:37 ` Daniel Colascione
2019-04-19 22:37 ` dancol
2019-04-24 8:04 ` Enrico Weigelt, metux IT consult
2019-04-24 8:04 ` Enrico Weigelt, metux IT consult
2019-04-24 8:04 ` lkml
2019-04-19 21:59 ` Christian Brauner
2019-04-19 21:59 ` Christian Brauner
2019-04-19 21:59 ` christian
2019-04-20 11:51 ` Oleg Nesterov
2019-04-20 11:51 ` Oleg Nesterov
2019-04-20 11:51 ` oleg
2019-04-20 12:26 ` Oleg Nesterov
2019-04-20 12:26 ` Oleg Nesterov
2019-04-20 12:26 ` oleg
2019-04-20 12:35 ` Christian Brauner
2019-04-20 12:35 ` Christian Brauner
2019-04-20 12:35 ` christian
2019-04-19 23:11 ` Linus Torvalds
2019-04-19 23:11 ` Linus Torvalds
2019-04-19 23:11 ` torvalds
2019-04-19 23:20 ` Christian Brauner
2019-04-19 23:20 ` Christian Brauner
2019-04-19 23:20 ` christian
2019-04-19 23:32 ` Linus Torvalds
2019-04-19 23:32 ` Linus Torvalds
2019-04-19 23:32 ` torvalds
2019-04-19 23:36 ` Daniel Colascione
2019-04-19 23:36 ` Daniel Colascione
2019-04-19 23:36 ` dancol
2019-04-20 0:46 ` Joel Fernandes
2019-04-20 0:46 ` Joel Fernandes
2019-04-20 0:46 ` joel
2019-04-19 21:21 ` Daniel Colascione
2019-04-19 21:21 ` Daniel Colascione
2019-04-19 21:21 ` dancol
2019-04-19 21:48 ` Christian Brauner
2019-04-19 21:48 ` Christian Brauner
2019-04-19 21:48 ` christian
2019-04-19 22:02 ` Christian Brauner
2019-04-19 22:02 ` Christian Brauner
2019-04-19 22:02 ` christian
2019-04-19 22:46 ` Daniel Colascione
2019-04-19 22:46 ` Daniel Colascione
2019-04-19 22:46 ` dancol
2019-04-19 23:12 ` Christian Brauner
2019-04-19 23:12 ` Christian Brauner
2019-04-19 23:12 ` christian
2019-04-19 23:46 ` Daniel Colascione
2019-04-19 23:46 ` Daniel Colascione
2019-04-19 23:46 ` dancol
2019-04-20 0:17 ` Christian Brauner
2019-04-20 0:17 ` Christian Brauner
2019-04-20 0:17 ` christian
2019-04-24 9:05 ` Enrico Weigelt, metux IT consult
2019-04-24 9:05 ` Enrico Weigelt, metux IT consult
2019-04-24 9:05 ` lkml
2019-04-24 9:03 ` Enrico Weigelt, metux IT consult
2019-04-24 9:03 ` Enrico Weigelt, metux IT consult
2019-04-24 9:03 ` lkml
2019-04-19 22:35 ` Daniel Colascione
2019-04-19 22:35 ` Daniel Colascione
2019-04-19 22:35 ` dancol
2019-04-19 23:02 ` Christian Brauner
2019-04-19 23:02 ` Christian Brauner
2019-04-19 23:02 ` christian
2019-04-19 23:29 ` Daniel Colascione
2019-04-19 23:29 ` Daniel Colascione
2019-04-19 23:29 ` dancol
2019-04-20 0:02 ` Christian Brauner
2019-04-20 0:02 ` Christian Brauner
2019-04-20 0:02 ` christian
2019-04-24 9:17 ` Enrico Weigelt, metux IT consult
2019-04-24 9:17 ` Enrico Weigelt, metux IT consult
2019-04-24 9:17 ` lkml
2019-04-24 9:11 ` Enrico Weigelt, metux IT consult
2019-04-24 9:11 ` Enrico Weigelt, metux IT consult
2019-04-24 9:11 ` lkml
2019-04-24 8:56 ` Enrico Weigelt, metux IT consult
2019-04-24 8:56 ` Enrico Weigelt, metux IT consult
2019-04-24 8:56 ` lkml
2019-04-24 8:20 ` Enrico Weigelt, metux IT consult
2019-04-24 8:20 ` Enrico Weigelt, metux IT consult
2019-04-24 8:20 ` lkml
2019-04-19 15:43 ` Oleg Nesterov
2019-04-19 15:43 ` Oleg Nesterov
2019-04-19 15:43 ` oleg
2019-04-19 18:12 ` Joel Fernandes
2019-04-19 18:12 ` Joel Fernandes
2019-04-19 18:12 ` joel
2019-04-18 18:44 ` Jonathan Kowalski
2019-04-18 18:44 ` Jonathan Kowalski
2019-04-18 18:44 ` bl0pbl33p
2019-04-18 18:57 ` Daniel Colascione
2019-04-18 18:57 ` Daniel Colascione
2019-04-18 18:57 ` dancol
2019-04-18 19:14 ` Linus Torvalds
2019-04-18 19:14 ` Linus Torvalds
2019-04-18 19:14 ` torvalds
2019-04-19 19:05 ` Joel Fernandes
2019-04-19 19:05 ` Joel Fernandes
2019-04-19 19:05 ` joel
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='CAHk-=wiL0GZn+kOyxzaS0igMRs95sipcc9r0ZgU2rRf=CR+fpw@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--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=jannh@google.com \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@kernel.org \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.