From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> To: Tycho Andersen <tycho@tycho.pizza> Cc: linux-man <linux-man@vger.kernel.org>, Song Liu <songliubraving@fb.com>, wad@chromium.org, Kees Cook <keescook@chromium.org>, Daniel Borkmann <daniel@iogearbox.net>, Jann Horn <jannh@google.com>, Robert Sesek <rsesek@google.com>, Linux Containers <containers@lists.linux-foundation.org>, lkml <linux-kernel@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>, mtk.manpages@gmail.com, Giuseppe Scrivano <gscrivan@redhat.com>, bpf@vger.kernel.org, Andy Lutomirski <luto@amacapital.net>, Christian Brauner <christian@brauner.io> Subject: Re: For review: seccomp_user_notif(2) manual page Date: Thu, 1 Oct 2020 09:45:19 +0200 [thread overview] Message-ID: <8f20d586-9609-ef83-c85a-272e37e684d8@gmail.com> (raw) In-Reply-To: <20200930230327.GA1260245@cisco> On 10/1/20 1:03 AM, Tycho Andersen wrote: > On Wed, Sep 30, 2020 at 10:34:51PM +0200, Michael Kerrisk (man-pages) wrote: >> Hi Tycho, >> >> Thanks for taking time to look at the page! >> >> On 9/30/20 5:03 PM, Tycho Andersen wrote: >>> On Wed, Sep 30, 2020 at 01:07:38PM +0200, Michael Kerrisk (man-pages) wrote: [...] >>>> ┌─────────────────────────────────────────────────────┐ >>>> │FIXME │ >>>> ├─────────────────────────────────────────────────────┤ >>>> │Interestingly, after the event had been received, │ >>>> │the file descriptor indicates as writable (verified │ >>>> │from the source code and by experiment). How is this │ >>>> │useful? │ >>> >>> You're saying it should just do EPOLLOUT and not EPOLLWRNORM? Seems >>> reasonable. >> >> No, I'm saying something more fundamental: why is the FD indicating as >> writable? Can you write something to it? If yes, what? If not, then >> why do these APIs want to say that the FD is writable? > > You can't via read(2) or write(2), but conceptually NOTIFY_RECV and > NOTIFY_SEND are reading and writing events from the fd. I don't know > that much about the poll interface though -- is it possible to > indicate "here's a pseudo-read event"? It didn't look like it, so I > just (ab-)used POLLIN and POLLOUT, but probably that's wrong. I think the POLLIN thing is fine. So, I think maybe I now understand what you intended with setting POLLOUT: the notification has been received ("read") and now the FD can be used to NOTIFY_SEND ("write") a response. Right? If that's correct, I don't have a problem with it. I just wonder: is it useful? IOW: are there situations where the process doing the NOTIFY_SEND might want to test for POLLOUT because the it doesn't know whether a NOTIFY_RECV has occurred? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> To: Tycho Andersen <tycho@tycho.pizza> Cc: mtk.manpages@gmail.com, Sargun Dhillon <sargun@sargun.me>, Kees Cook <keescook@chromium.org>, Christian Brauner <christian@brauner.io>, linux-man <linux-man@vger.kernel.org>, lkml <linux-kernel@vger.kernel.org>, Aleksa Sarai <cyphar@cyphar.com>, Jann Horn <jannh@google.com>, Alexei Starovoitov <ast@kernel.org>, wad@chromium.org, bpf@vger.kernel.org, Song Liu <songliubraving@fb.com>, Daniel Borkmann <daniel@iogearbox.net>, Andy Lutomirski <luto@amacapital.net>, Linux Containers <containers@lists.linux-foundation.org>, Giuseppe Scrivano <gscrivan@redhat.com>, Robert Sesek <rsesek@google.com> Subject: Re: For review: seccomp_user_notif(2) manual page Date: Thu, 1 Oct 2020 09:45:19 +0200 [thread overview] Message-ID: <8f20d586-9609-ef83-c85a-272e37e684d8@gmail.com> (raw) In-Reply-To: <20200930230327.GA1260245@cisco> On 10/1/20 1:03 AM, Tycho Andersen wrote: > On Wed, Sep 30, 2020 at 10:34:51PM +0200, Michael Kerrisk (man-pages) wrote: >> Hi Tycho, >> >> Thanks for taking time to look at the page! >> >> On 9/30/20 5:03 PM, Tycho Andersen wrote: >>> On Wed, Sep 30, 2020 at 01:07:38PM +0200, Michael Kerrisk (man-pages) wrote: [...] >>>> ┌─────────────────────────────────────────────────────┐ >>>> │FIXME │ >>>> ├─────────────────────────────────────────────────────┤ >>>> │Interestingly, after the event had been received, │ >>>> │the file descriptor indicates as writable (verified │ >>>> │from the source code and by experiment). How is this │ >>>> │useful? │ >>> >>> You're saying it should just do EPOLLOUT and not EPOLLWRNORM? Seems >>> reasonable. >> >> No, I'm saying something more fundamental: why is the FD indicating as >> writable? Can you write something to it? If yes, what? If not, then >> why do these APIs want to say that the FD is writable? > > You can't via read(2) or write(2), but conceptually NOTIFY_RECV and > NOTIFY_SEND are reading and writing events from the fd. I don't know > that much about the poll interface though -- is it possible to > indicate "here's a pseudo-read event"? It didn't look like it, so I > just (ab-)used POLLIN and POLLOUT, but probably that's wrong. I think the POLLIN thing is fine. So, I think maybe I now understand what you intended with setting POLLOUT: the notification has been received ("read") and now the FD can be used to NOTIFY_SEND ("write") a response. Right? If that's correct, I don't have a problem with it. I just wonder: is it useful? IOW: are there situations where the process doing the NOTIFY_SEND might want to test for POLLOUT because the it doesn't know whether a NOTIFY_RECV has occurred? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2020-10-01 7:45 UTC|newest] Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-30 11:07 For review: seccomp_user_notif(2) manual page Michael Kerrisk (man-pages) 2020-09-30 11:07 ` Michael Kerrisk (man-pages) 2020-09-30 15:03 ` Tycho Andersen 2020-09-30 15:03 ` Tycho Andersen 2020-09-30 15:11 ` Tycho Andersen 2020-09-30 15:11 ` Tycho Andersen 2020-09-30 20:34 ` Michael Kerrisk (man-pages) 2020-09-30 20:34 ` Michael Kerrisk (man-pages) 2020-09-30 23:03 ` Tycho Andersen 2020-09-30 23:03 ` Tycho Andersen 2020-09-30 23:11 ` Jann Horn via Containers 2020-09-30 23:11 ` Jann Horn 2020-09-30 23:24 ` Tycho Andersen 2020-09-30 23:24 ` Tycho Andersen 2020-10-01 1:52 ` Jann Horn via Containers 2020-10-01 1:52 ` Jann Horn 2020-10-01 2:14 ` Jann Horn via Containers 2020-10-01 2:14 ` Jann Horn 2020-10-25 16:31 ` Michael Kerrisk (man-pages) 2020-10-25 16:31 ` Michael Kerrisk (man-pages) 2020-10-26 15:54 ` Jann Horn via Containers 2020-10-26 15:54 ` Jann Horn 2020-10-27 6:14 ` Michael Kerrisk (man-pages) 2020-10-27 6:14 ` Michael Kerrisk (man-pages) 2020-10-27 10:28 ` Jann Horn via Containers 2020-10-27 10:28 ` Jann Horn 2020-10-28 6:31 ` Sargun Dhillon 2020-10-28 6:31 ` Sargun Dhillon 2020-10-28 9:43 ` Jann Horn via Containers 2020-10-28 9:43 ` Jann Horn 2020-10-28 17:43 ` Sargun Dhillon 2020-10-28 17:43 ` Sargun Dhillon 2020-10-28 18:20 ` Jann Horn via Containers 2020-10-28 18:20 ` Jann Horn 2020-10-01 7:49 ` Michael Kerrisk (man-pages) 2020-10-01 7:49 ` Michael Kerrisk (man-pages) 2020-10-26 0:32 ` Kees Cook 2020-10-26 0:32 ` Kees Cook 2020-10-26 9:51 ` Jann Horn via Containers 2020-10-26 9:51 ` Jann Horn 2020-10-26 10:31 ` Jann Horn via Containers 2020-10-26 10:31 ` Jann Horn 2020-10-28 22:56 ` Kees Cook 2020-10-28 22:56 ` Kees Cook 2020-10-29 1:11 ` Jann Horn via Containers 2020-10-29 1:11 ` Jann Horn 2020-10-29 2:13 ` Tycho Andersen 2020-10-29 4:26 ` Jann Horn via Containers 2020-10-29 4:26 ` Jann Horn 2020-10-28 22:53 ` Kees Cook 2020-10-28 22:53 ` Kees Cook 2020-10-29 1:25 ` Jann Horn via Containers 2020-10-29 1:25 ` Jann Horn 2020-10-01 7:45 ` Michael Kerrisk (man-pages) [this message] 2020-10-01 7:45 ` Michael Kerrisk (man-pages) 2020-10-14 4:40 ` Michael Kerrisk (man-pages) 2020-10-14 4:40 ` Michael Kerrisk (man-pages) 2020-09-30 15:53 ` Jann Horn via Containers 2020-09-30 15:53 ` Jann Horn 2020-10-01 12:54 ` Christian Brauner 2020-10-01 12:54 ` Christian Brauner 2020-10-01 15:47 ` Jann Horn via Containers 2020-10-01 15:47 ` Jann Horn 2020-10-01 16:58 ` Tycho Andersen 2020-10-01 16:58 ` Tycho Andersen 2020-10-01 17:12 ` Christian Brauner 2020-10-01 17:12 ` Christian Brauner 2020-10-14 5:41 ` Michael Kerrisk (man-pages) 2020-10-14 5:41 ` Michael Kerrisk (man-pages) 2020-10-01 18:18 ` Jann Horn via Containers 2020-10-01 18:18 ` Jann Horn 2020-10-01 18:56 ` Tycho Andersen 2020-10-01 18:56 ` Tycho Andersen 2020-10-01 17:05 ` Christian Brauner 2020-10-01 17:05 ` Christian Brauner 2020-10-15 11:24 ` Michael Kerrisk (man-pages) 2020-10-15 11:24 ` Michael Kerrisk (man-pages) 2020-10-15 20:32 ` Jann Horn via Containers 2020-10-15 20:32 ` Jann Horn 2020-10-16 18:29 ` Michael Kerrisk (man-pages) 2020-10-16 18:29 ` Michael Kerrisk (man-pages) 2020-10-17 0:25 ` Jann Horn via Containers 2020-10-17 0:25 ` Jann Horn 2020-10-24 12:52 ` Michael Kerrisk (man-pages) 2020-10-24 12:52 ` Michael Kerrisk (man-pages) 2020-10-26 9:32 ` Jann Horn via Containers 2020-10-26 9:32 ` Jann Horn 2020-10-26 9:47 ` Michael Kerrisk (man-pages) 2020-10-26 9:47 ` Michael Kerrisk (man-pages) 2020-09-30 23:39 ` Kees Cook 2020-09-30 23:39 ` Kees Cook 2020-10-15 11:24 ` Michael Kerrisk (man-pages) 2020-10-15 11:24 ` Michael Kerrisk (man-pages) 2020-10-26 0:19 ` Kees Cook 2020-10-26 0:19 ` Kees Cook 2020-10-26 9:39 ` Michael Kerrisk (man-pages) 2020-10-26 9:39 ` Michael Kerrisk (man-pages) 2020-10-01 12:36 ` Christian Brauner 2020-10-01 12:36 ` Christian Brauner 2020-10-15 11:23 ` Michael Kerrisk (man-pages) 2020-10-15 11:23 ` Michael Kerrisk (man-pages) 2020-10-01 21:06 ` Sargun Dhillon 2020-10-01 21:06 ` Sargun Dhillon 2020-10-01 23:19 ` Tycho Andersen 2020-10-01 23:19 ` Tycho Andersen
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=8f20d586-9609-ef83-c85a-272e37e684d8@gmail.com \ --to=mtk.manpages@gmail.com \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=christian@brauner.io \ --cc=containers@lists.linux-foundation.org \ --cc=daniel@iogearbox.net \ --cc=gscrivan@redhat.com \ --cc=jannh@google.com \ --cc=keescook@chromium.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-man@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=rsesek@google.com \ --cc=songliubraving@fb.com \ --cc=tycho@tycho.pizza \ --cc=wad@chromium.org \ /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: linkBe 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.