From: Florian Weimer <fweimer@redhat.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Christian Brauner <christian@brauner.io>,
"Eric W. Biederman" <ebiederm@xmission.com>,
LKML <linux-kernel@vger.kernel.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Jann Horn <jannh@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>, Aleksa Sarai <cyphar@cyphar.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Daniel Colascione <dancol@google.com>,
Tim Murray <timmurray@google.com>,
linux-man <linux-man@vger.kernel.org>,
Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v2] signal: add procfd_signal() syscall
Date: Thu, 06 Dec 2018 19:56:44 +0100 [thread overview]
Message-ID: <87y392h4b7.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <CALCETrViXJ0gD34yVd8QpB-CSeKZzzncvkPHReycTiQin4r4WQ@mail.gmail.com> (Andy Lutomirski's message of "Thu, 6 Dec 2018 10:54:02 -0800")
* Andy Lutomirski:
>> I suppose that's fine. Or alternatively, when thread group support is
>> added, introduce a flag that applications have to use to enable it, so
>> that they can probe for support by checking support for the flag.
>>
>> I wouldn't be opposed to a new system call like this either:
>>
>> int procfd_open (pid_t thread_group, pid_t thread_id, unsigned flags);
>>
>> But I think this is frowned upon on the kernel side.
>
> I have no problem with it, except that I think it shouldn’t return an
> fd that can be used for proc filesystem access.
Oh no, my intention was that it would just be used with *_send_signal
and related functions.
Thanks,
Florian
next prev parent reply other threads:[~2018-12-06 18:56 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 10:51 [PATCH v2] signal: add procfd_signal() syscall Christian Brauner
2018-11-20 10:51 ` [PATCH v2] procfd_signal.2: document procfd_signal syscall Christian Brauner
2018-11-22 8:00 ` [PATCH v2] signal: add procfd_signal() syscall Serge E. Hallyn
2018-11-22 8:23 ` Aleksa Sarai
2018-11-28 14:05 ` Arnd Bergmann
2018-11-29 12:28 ` Florian Weimer
2018-11-29 16:54 ` Andy Lutomirski
2018-11-29 19:16 ` Christian Brauner
2018-11-29 19:22 ` Andy Lutomirski
2018-11-29 19:55 ` Christian Brauner
2018-11-29 20:14 ` Andy Lutomirski
2018-11-29 21:02 ` Arnd Bergmann
2018-11-29 21:35 ` Christian Brauner
2018-11-29 21:40 ` Arnd Bergmann
2018-11-30 2:40 ` Aleksa Sarai
2018-12-01 1:25 ` Christian Brauner
2018-11-30 5:13 ` Eric W. Biederman
2018-11-30 6:56 ` Christian Brauner
2018-11-30 11:41 ` Arnd Bergmann
2018-11-30 16:35 ` Andy Lutomirski
2018-11-30 21:57 ` Christian Brauner
2018-11-30 21:57 ` Christian Brauner
2018-11-30 22:09 ` Arnd Bergmann
2018-11-30 22:26 ` Christian Brauner
2018-11-30 23:05 ` Daniel Colascione
2018-11-30 23:12 ` Arnd Bergmann
2018-11-30 23:15 ` Arnd Bergmann
2018-11-30 23:37 ` Christian Brauner
2018-11-30 23:37 ` Christian Brauner
2018-11-30 23:46 ` Andy Lutomirski
2018-12-01 1:20 ` Christian Brauner
2018-12-01 1:20 ` Christian Brauner
2018-11-30 23:53 ` Andy Lutomirski
2018-12-01 8:51 ` Arnd Bergmann
2018-12-01 9:17 ` Christian Brauner
2018-12-01 9:17 ` Christian Brauner
2018-12-01 10:27 ` Arnd Bergmann
2018-12-01 13:41 ` Eric W. Biederman
2018-12-01 14:46 ` Eric W. Biederman
2018-12-01 15:28 ` Eric W. Biederman
2018-12-01 15:52 ` Andy Lutomirski
2018-12-01 16:27 ` Christian Brauner
2018-12-02 0:06 ` Eric W. Biederman
2018-12-02 1:14 ` Andy Lutomirski
2018-12-02 8:52 ` Christian Brauner
2018-11-30 23:52 ` Christian Brauner
2018-12-02 10:03 ` Christian Brauner
2018-12-03 16:57 ` Florian Weimer
2018-12-03 18:02 ` Christian Brauner
2018-12-04 6:03 ` Aleksa Sarai
2018-12-04 12:55 ` Florian Weimer
2018-12-04 13:26 ` Christian Brauner
2018-12-06 18:54 ` Andy Lutomirski
2018-12-06 18:56 ` Florian Weimer [this message]
2018-12-06 19:03 ` Christian Brauner
2018-12-25 5:32 ` Lai Jiangshan
2018-12-25 7:11 ` Lai Jiangshan
2018-12-25 12:07 ` Aleksa Sarai
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=87y392h4b7.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=christian@brauner.io \
--cc=cyphar@cyphar.com \
--cc=dancol@google.com \
--cc=ebiederm@xmission.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=luto@kernel.org \
--cc=oleg@redhat.com \
--cc=serge@hallyn.com \
--cc=timmurray@google.com \
--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.