[lkml]   [2018]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] signal: add procfd_signal() syscall
On December 7, 2018 7:56:44 AM GMT+13:00, Florian Weimer <> wrote:
>* Andy Lutomirski:
>>> I suppose that's fine. Or alternatively, when thread group support
>>> added, introduce a flag that applications have to use to enable it,
>>> 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
>>> 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.

Let's postpone that discussion a little.
I think we don't need a syscall to base this off of pids.
As I said I rather send my revived version of CLONE_NEWFD that would serve the same task.
The same way we could also just add a new open() flag that blocks fs access completely.
I just pitched that idea to Serge a few days back: O_NOCHDIR or similar.
That could even be part of Aleksa's path resolution patchset.


 \ /
  Last update: 2018-12-06 20:04    [W:0.043 / U:1.012 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site