* Daniel Colascione:
> But doesn't the CSIGNAL approach still require that libraries somehow
> coordinate which non-SIGCHLD signal they use? (Signal coordination a
> separate problem, unfortunately.)
There's already an allocation mechanism for realtime signals in glibc,
via __libc_allocate_rtsig.
On Mon, Apr 1, 2019 at 3:13 PM Linus Torvalds
wrote:
>
> On Mon, Apr 1, 2019 at 2:58 PM Jonathan Kowalski wrote:
> >
> > You mention the race about learning the PID, PID being recycled, and
> > pidfd_open getting the wrong reference.
> >
> > This exists with the /proc model to way. How do you pro
On Mon, Apr 1, 2019 at 2:58 PM Jonathan Kowalski wrote:
>
> You mention the race about learning the PID, PID being recycled, and
> pidfd_open getting the wrong reference.
>
> This exists with the /proc model to way. How do you propose to address this?
Note that that race exists _regardless_ of an
On Mon, Apr 1, 2019 at 10:35 PM Linus Torvalds
wrote:
>
> On Mon, Apr 1, 2019 at 12:42 PM Christian Brauner
> wrote:
> >
> > From what I gather from this thread we are still best of with using fds
> > to /proc/ as pidfds. Linus, do you agree or have I misunderstood?
You mention the race about l
On Mon, Apr 1, 2019 at 12:42 PM Christian Brauner wrote:
>
> From what I gather from this thread we are still best of with using fds
> to /proc/ as pidfds. Linus, do you agree or have I misunderstood?
That does seem to be the most flexible option.
> Yes, we can have an internal mount option to r
On Mon, Apr 01, 2019 at 09:01:29AM -0700, Linus Torvalds wrote:
> On Mon, Apr 1, 2019 at 8:55 AM Daniel Colascione wrote:
> >
> >
> > > I wonder if we really want a fill procfs2, or maybe we could just make
> > > the pidfd readable (yes, it's a directory file descriptor, but we
> > > could allow r
On Mon, Apr 1, 2019 at 9:45 AM Daniel Colascione wrote:
>
> But doesn't the CSIGNAL approach still require that libraries somehow
> coordinate which non-SIGCHLD signal they use?
Yes. As mentioned, this was seldom used.
In some cases it's ok, eg aio would just specify the signal in
sigev_signo (e
From: Daniel Colascione
> Sent: 01 April 2019 17:45
...
> > Now, none of this was ever really used. The people who wanted AIO
> > wanted the brain-damaged POSIX kind of AIO, not something cool and
> > clever. So I suspect the whole exit-signal thing was just used for
> > random small per-project th
On Mon, Apr 1, 2019 at 9:30 AM Linus Torvalds
wrote:
>
> On Mon, Apr 1, 2019 at 9:22 AM Daniel Colascione wrote:
> >
> > There's a subtlety: suppose I'm a library and I want to create a
> > private subprocess. I use the new clone facility, whatever it is, and
> > get a pidfd back. I need to be ab
On Mon, Apr 1, 2019 at 9:22 AM Daniel Colascione wrote:
>
> There's a subtlety: suppose I'm a library and I want to create a
> private subprocess. I use the new clone facility, whatever it is, and
> get a pidfd back. I need to be able to read the child's exit status
> even if the child exits befor
On Mon, Apr 1, 2019 at 5:15 PM Linus Torvalds
wrote:
>
> On Mon, Apr 1, 2019 at 9:07 AM Jonathan Kowalski wrote:
> >
> > With the POLLHUP model on a simple pidfd, you'd know when the process
> > you were referring to is dead (and one can map POLLPRI to dead and
> > POLLHUP to zombie, etc).
>
> Ad
On Mon, Apr 1, 2019 at 9:07 AM Jonathan Kowalski wrote:
>
> On Mon, Apr 1, 2019 at 4:55 PM Daniel Colascione wrote:
> >
> > On Mon, Apr 1, 2019 at 8:36 AM Linus Torvalds
> > wrote:
> > >
> > > On Mon, Apr 1, 2019 at 4:41 AM Aleksa Sarai wrote:
> > > >
> > > > Eric pitched a procfs2 which would
On Mon, Apr 1, 2019 at 9:07 AM Jonathan Kowalski wrote:
>
> With the POLLHUP model on a simple pidfd, you'd know when the process
> you were referring to is dead (and one can map POLLPRI to dead and
> POLLHUP to zombie, etc).
Adding ->poll() to the pidfd should be easy. Again, it would be
trivial
> On Apr 1, 2019, at 9:36 AM, Linus Torvalds
> wrote:
>
>> On Mon, Apr 1, 2019 at 4:41 AM Aleksa Sarai wrote:
>>
>> Eric pitched a procfs2 which would *just* be the PIDs some time ago (in
>> an attempt to make it possible one day to mount /proc inside a container
>> without adding a bunch o
On Mon, Apr 1, 2019 at 9:01 AM Linus Torvalds
wrote:
>
> On Mon, Apr 1, 2019 at 8:55 AM Daniel Colascione wrote:
> >
> >
> > > I wonder if we really want a fill procfs2, or maybe we could just make
> > > the pidfd readable (yes, it's a directory file descriptor, but we
> > > could allow reading).
On Mon, Apr 1, 2019 at 4:55 PM Daniel Colascione wrote:
>
> On Mon, Apr 1, 2019 at 8:36 AM Linus Torvalds
> wrote:
> >
> > On Mon, Apr 1, 2019 at 4:41 AM Aleksa Sarai wrote:
> > >
> > > Eric pitched a procfs2 which would *just* be the PIDs some time ago (in
> > > an attempt to make it possible o
On Mon, Apr 1, 2019 at 8:55 AM Daniel Colascione wrote:
>
>
> > I wonder if we really want a fill procfs2, or maybe we could just make
> > the pidfd readable (yes, it's a directory file descriptor, but we
> > could allow reading).
>
> What would read(2) read?
We could make it read anything, but i
On Mon, Apr 1, 2019 at 8:36 AM Linus Torvalds
wrote:
>
> On Mon, Apr 1, 2019 at 4:41 AM Aleksa Sarai wrote:
> >
> > Eric pitched a procfs2 which would *just* be the PIDs some time ago (in
> > an attempt to make it possible one day to mount /proc inside a container
> > without adding a bunch of ma
On Mon, Apr 01, 2019 at 08:36:26AM -0700, Linus Torvalds wrote:
> On Mon, Apr 1, 2019 at 4:41 AM Aleksa Sarai wrote:
> >
> > Eric pitched a procfs2 which would *just* be the PIDs some time ago (in
> > an attempt to make it possible one day to mount /proc inside a container
> > without adding a bun
On Mon, Apr 1, 2019 at 4:41 AM Aleksa Sarai wrote:
>
> Eric pitched a procfs2 which would *just* be the PIDs some time ago (in
> an attempt to make it possible one day to mount /proc inside a container
> without adding a bunch of masked paths), though it was just an idea and
> I don't know if he e
On Mon, Apr 1, 2019 at 2:04 PM Christian Brauner wrote:
> On Sun, Mar 31, 2019 at 08:13:38PM -0600, Andy Lutomirski wrote:
> > > On Mar 31, 2019, at 3:17 PM, Linus Torvalds
> > > wrote:
> > >> On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner
> > >> wrote:
> > >>
> > >> I don't think that we w
On Sun, Mar 31, 2019 at 08:13:38PM -0600, Andy Lutomirski wrote:
>
>
> > On Mar 31, 2019, at 3:17 PM, Linus Torvalds
> > wrote:
> >
> >> On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner
> >> wrote:
> >>
> >> I don't think that we want or can make them equivalent since that would
> >> mean
On 2019-03-31, Andy Lutomirski wrote:
> > On Mar 31, 2019, at 3:17 PM, Linus Torvalds
> > wrote:
> >> On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner
> >> wrote:
> >>
> >> I don't think that we want or can make them equivalent since that would
> >> mean we depend on procfs.
> >
> > Sure we
On Mon, Apr 1, 2019 at 1:53 AM Jann Horn wrote:
>
> On Mon, Apr 1, 2019 at 12:33 AM Christian Brauner
> wrote:
> > On Sun, Mar 31, 2019 at 03:16:47PM -0700, Linus Torvalds wrote:
> > > On Sun, Mar 31, 2019 at 3:03 PM Christian Brauner
> > > wrote:
> > > > Thanks for the input. The problem Jann
Hi,
Le lundi 01 avril 2019 à 02:52 +0200, Jann Horn a écrit :
> One minor detail to keep in mind for the future is that in a
> straightforward implementation of this concept, if a non-capable
> process is running in a mount namespace, but in the initial network
> namespace, without any reachable
On Mon, Apr 01, 2019 at 07:37:42AM +0100, Al Viro wrote:
> On Sun, Mar 31, 2019 at 05:18:10PM -0700, Linus Torvalds wrote:
>
> > Yeah, I would like to see the actual aio.c pull request and the
> > use-after-free fixes. All the patches look fine, I just don't have the
> > final end result..
>
> us
On Sun, Mar 31, 2019 at 05:18:10PM -0700, Linus Torvalds wrote:
> Yeah, I would like to see the actual aio.c pull request and the
> use-after-free fixes. All the patches look fine, I just don't have the
> final end result..
use-after-free fixes: ceph is already in mainline, Daniel's bpf fix is in
> On Mar 31, 2019, at 3:17 PM, Linus Torvalds
> wrote:
>
>> On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner
>> wrote:
>>
>> I don't think that we want or can make them equivalent since that would
>> mean we depend on procfs.
>
> Sure we can.
>
> If /proc is enabled, then you always do
On Mon, Apr 1, 2019 at 12:33 AM Christian Brauner wrote:
> On Sun, Mar 31, 2019 at 03:16:47PM -0700, Linus Torvalds wrote:
> > On Sun, Mar 31, 2019 at 3:03 PM Christian Brauner
> > wrote:
> > > Thanks for the input. The problem Jann and I saw with this is that it
> > > would be awkward to have t
On Sun, Mar 31, 2019 at 5:09 PM Al Viro wrote:
>
> Ugh... Which vfsmount would you have to go with it?
I'd literally just do a lookup of "/proc" in the current root
directory in the lookup() function for that special pseudo-dentry.
If it's not mounted, or not a /proc filesystem, screw it.
> Ex
On Sun, Mar 31, 2019 at 05:18:10PM -0700, Linus Torvalds wrote:
> On Sun, Mar 31, 2019 at 5:09 PM Al Viro wrote:
> >
> > Ugh... Which vfsmount would you have to go with it?
>
> I'd literally just do a lookup of "/proc" in the current root
> directory in the lookup() function for that special pse
On Sun, Mar 31, 2019 at 04:40:15PM -0700, Linus Torvalds wrote:
> The clever alternative, which might be the RightWay(tm) is to just
> create a completely unattached dentry, and basically tie it into the
> actual /proc filesystem hierarchy at lookup() time when somebody does
> the openat() using i
On Sun, Mar 31, 2019 at 3:16 PM Linus Torvalds
wrote:
>
> I would actually suggest we just make the rules be that the
> pidfd_open() always return the internal /proc entry regardless of any
> mount-point (or any "hidepid")
The clever alternative, which might be the RightWay(tm) is to just
create
On Sun, Mar 31, 2019 at 03:16:47PM -0700, Linus Torvalds wrote:
> On Sun, Mar 31, 2019 at 3:03 PM Christian Brauner
> wrote:
> >
> > Thanks for the input. The problem Jann and I saw with this is that it
> > would be awkward to have the kernel open a file in some procfs instance,
> > since then us
On Sun, Mar 31, 2019 at 3:03 PM Christian Brauner wrote:
>
> Thanks for the input. The problem Jann and I saw with this is that it
> would be awkward to have the kernel open a file in some procfs instance,
> since then userspace would have to specify which procfs instance the fd
> should come from
On Sun, Mar 31, 2019 at 10:18 PM Linus Torvalds
wrote:
>
> On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner
> wrote:
> >
> > I don't think that we want or can make them equivalent since that would
> > mean we depend on procfs.
>
> Sure we can.
>
> If /proc is enabled, then you always do that da
On Sun, Mar 31, 2019 at 02:17:48PM -0700, Linus Torvalds wrote:
> On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner
> wrote:
> >
> > I don't think that we want or can make them equivalent since that would
> > mean we depend on procfs.
>
> Sure we can.
>
> If /proc is enabled, then you always do
On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner wrote:
>
> I don't think that we want or can make them equivalent since that would
> mean we depend on procfs.
Sure we can.
If /proc is enabled, then you always do that dance YOU ALREADY WROTE
THE CODE FOR to do the stupid ioctl.
And if /procfs
On Sun, Mar 31, 2019 at 02:09:03PM -0600, Andy Lutomirski wrote:
>
>
> > On Mar 30, 2019, at 11:24 AM, Linus Torvalds
> > wrote:
> >
> >> On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> >> wrote:
> >>
> >>
> >> To clarify, what the Android guys really wanted to be part of the api is
>
On Sun, Mar 31, 2019 at 02:03:25PM -0700, Linus Torvalds wrote:
> On Sun, Mar 31, 2019 at 1:38 PM Andy Lutomirski wrote:
> >
> > openat(fd to pidfd’s proc directory, “status”, ...);
> >
> > And we want a non-utterly-crappy way to do this. The ioctl is certainly
> > ugly, but it *works*.
>
> It'
On Sun, Mar 31, 2019 at 1:38 PM Andy Lutomirski wrote:
>
> openat(fd to pidfd’s proc directory, “status”, ...);
>
> And we want a non-utterly-crappy way to do this. The ioctl is certainly
> ugly, but it *works*.
It's beyond clunky. It's a disgrace.
If people really want equivalency between ope
> On Mar 30, 2019, at 11:24 AM, Linus Torvalds
> wrote:
>
>> On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
>> wrote:
>>
>>
>> To clarify, what the Android guys really wanted to be part of the api is
>> a way to get race-free access to metadata associated with a given pidfd.
>> And th
On Sun, Mar 31, 2019 at 3:59 PM Linus Torvalds
wrote:
>
> On Sat, Mar 30, 2019 at 9:47 PM Jann Horn wrote:
> >
> > Sure, given a pidfd_clone() syscall, as long as the parent of the
> > process is giving you a pidfd for it and you don't have to deal with
> > grandchildren created by fork() calls o
On Sun, Mar 31, 2019 at 8:05 AM Christian Brauner wrote:
>
> On Sun, Mar 31, 2019 at 07:52:28AM -0700, Linus Torvalds wrote:
> > On Sat, Mar 30, 2019 at 9:47 PM Jann Horn wrote:
> > >
> > > Sure, given a pidfd_clone() syscall, as long as the parent of the
> > > process is giving you a pidfd for i
On Sun, Mar 31, 2019 at 07:52:28AM -0700, Linus Torvalds wrote:
> On Sat, Mar 30, 2019 at 9:47 PM Jann Horn wrote:
> >
> > Sure, given a pidfd_clone() syscall, as long as the parent of the
> > process is giving you a pidfd for it and you don't have to deal with
> > grandchildren created by fork()
On Sat, Mar 30, 2019 at 9:47 PM Jann Horn wrote:
>
> Sure, given a pidfd_clone() syscall, as long as the parent of the
> process is giving you a pidfd for it and you don't have to deal with
> grandchildren created by fork() calls outside your control, that
> works.
Don't do pidfd_clone() and pidf
On Sun, Mar 31, 2019 at 6:08 AM Joel Fernandes wrote:
> On Sun, Mar 31, 2019 at 04:34:57AM +0200, Jann Horn wrote:
> > On Sun, Mar 31, 2019 at 3:07 AM Joel Fernandes
> > wrote:
> > > As I said I don't really care about "pidfd" solving any racing issues with
> > > /proc//* accesses - because I st
On Sun, Mar 31, 2019 at 04:34:57AM +0200, Jann Horn wrote:
> On Sun, Mar 31, 2019 at 3:07 AM Joel Fernandes wrote:
> > As I said I don't really care about "pidfd" solving any racing issues with
> > /proc//* accesses - because I still find it hard to imagine that the
> > pid
> > number can be reus
On Sun, Mar 31, 2019 at 3:07 AM Joel Fernandes wrote:
> As I said I don't really care about "pidfd" solving any racing issues with
> /proc//* accesses - because I still find it hard to imagine that the pid
> number can be reused easily from the time you know which to deal with,
> to the time when
On Sat, Mar 30, 2019 at 09:18:12AM -0700, Linus Torvalds wrote:
> On Sat, Mar 30, 2019 at 9:16 AM Linus Torvalds
> wrote:
> >
> > And no, we are *NOT* making pidfd_open() into some "let's expose /proc
> > even when it's not mounted" horror. Seriously. That's disgusting,
> > wrong, insecure and stu
On Sat, Mar 30, 2019 at 05:59:34PM +, Jonathan Kowalski wrote:
> On Sat, Mar 30, 2019 at 5:52 PM Christian Brauner
> wrote:
> >
> > On Sat, Mar 30, 2019 at 05:50:20PM +, Jonathan Kowalski wrote:
> > > On Sat, Mar 30, 2019 at 5:24 PM Linus Torvalds
> > > wrote:
> > > >
> > > > On Sat, Mar
On Sat, Mar 30, 2019 at 6:24 PM Linus Torvalds
wrote:
> On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> wrote:
> > To clarify, what the Android guys really wanted to be part of the api is
> > a way to get race-free access to metadata associated with a given pidfd.
> > And the idea was that
On Sat, Mar 30, 2019 at 5:52 PM Christian Brauner wrote:
>
> On Sat, Mar 30, 2019 at 05:50:20PM +, Jonathan Kowalski wrote:
> > On Sat, Mar 30, 2019 at 5:24 PM Linus Torvalds
> > wrote:
> > >
> > > On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> > > wrote:
> > > >
> > > >
> > > > To cl
On Sat, Mar 30, 2019 at 05:50:20PM +, Jonathan Kowalski wrote:
> On Sat, Mar 30, 2019 at 5:24 PM Linus Torvalds
> wrote:
> >
> > On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> > wrote:
> > >
> > >
> > > To clarify, what the Android guys really wanted to be part of the api is
> > > a wa
On Sat, Mar 30, 2019 at 5:24 PM Linus Torvalds
wrote:
>
> On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> wrote:
> >
> >
> > To clarify, what the Android guys really wanted to be part of the api is
> > a way to get race-free access to metadata associated with a given pidfd.
> > And the idea
On Sat, Mar 30, 2019 at 10:24:19AM -0700, Linus Torvalds wrote:
> On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner
> wrote:
> >
> >
> > To clarify, what the Android guys really wanted to be part of the api is
> > a way to get race-free access to metadata associated with a given pidfd.
> > And t
On Sat, Mar 30, 2019 at 10:12 AM Christian Brauner wrote:
>
>
> To clarify, what the Android guys really wanted to be part of the api is
> a way to get race-free access to metadata associated with a given pidfd.
> And the idea was that *if and only if procfs is mounted* you could do:
>
> int pidfd
On Sat, Mar 30, 2019 at 10:04:33AM -0700, Linus Torvalds wrote:
> On Sat, Mar 30, 2019 at 9:34 AM Daniel Colascione wrote:
> >
> > Just to be clear, I'm not proposing granting secret access to procfs,
> > and as far as I can see, nobody else is either. We've been talking
> > about making it easier
On Sat, Mar 30, 2019 at 9:34 AM Daniel Colascione wrote:
>
> Just to be clear, I'm not proposing granting secret access to procfs,
> and as far as I can see, nobody else is either. We've been talking
> about making it easier to avoid races when you happen to want a pidfd
> and a procfs fd that poi
On Sat, Mar 30, 2019 at 09:34:02AM -0700, Daniel Colascione wrote:
> On Sat, Mar 30, 2019 at 9:24 AM Linus Torvalds
> wrote:
> >
> > On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner
> > wrote:
> > >
> > > From pure API perspective that's all I care about: independence of procfs.
> > > Once we h
On Sat, Mar 30, 2019 at 09:24:23AM -0700, Linus Torvalds wrote:
> On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner
> wrote:
> >
> > From pure API perspective that's all I care about: independence of procfs.
> > Once we have pidfd_open() we can cleanly signal threads etc.
>
> But "independence f
On Sat, Mar 30, 2019 at 9:24 AM Linus Torvalds
wrote:
>
> On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner
> wrote:
> >
> > From pure API perspective that's all I care about: independence of procfs.
> > Once we have pidfd_open() we can cleanly signal threads etc.
>
> But "independence from proc
On Sat, Mar 30, 2019 at 9:19 AM Christian Brauner wrote:
>
> From pure API perspective that's all I care about: independence of procfs.
> Once we have pidfd_open() we can cleanly signal threads etc.
But "independence from procfs" means that you damn well don't then do
"oh, now I have a pidfd, I w
On March 30, 2019 5:09:10 PM GMT+01:00, Linus Torvalds
wrote:
>On Fri, Mar 29, 2019 at 8:54 AM Christian Brauner
> wrote:
>>
>> /* Introduction */
>> This adds the pidfd_open() syscall.
>> pidfd_open() allows to retrieve file descriptors for a given pid.
>This
>> includes both file descriptors fo
On Sat, Mar 30, 2019 at 9:16 AM Linus Torvalds
wrote:
>
> And no, we are *NOT* making pidfd_open() into some "let's expose /proc
> even when it's not mounted" horror. Seriously. That's disgusting,
> wrong, insecure and stupid.
And btw, this is not debatable. In fact, this whole discussion is
maki
On Sat, Mar 30, 2019 at 9:11 AM Daniel Colascione wrote:
>
> How do you propose that someone open the /proc//status file in a
> race-free manner starting with the result of calling pidfd_open?
CXhrist.
If you want to open a /proc file, then open a /proc file. Don't use
pidfd_open().
Just open /
On Sat, Mar 30, 2019 at 9:09 AM Linus Torvalds
wrote:
>
> On Fri, Mar 29, 2019 at 8:54 AM Christian Brauner
> wrote:
> >
> > /* Introduction */
> > This adds the pidfd_open() syscall.
> > pidfd_open() allows to retrieve file descriptors for a given pid. This
> > includes both file descriptors fo
On Fri, Mar 29, 2019 at 8:54 AM Christian Brauner wrote:
>
> /* Introduction */
> This adds the pidfd_open() syscall.
> pidfd_open() allows to retrieve file descriptors for a given pid. This
> includes both file descriptors for processes and file descriptors for
> threads.
I'm ok with the pidfd_o
/* Introduction */
This adds the pidfd_open() syscall.
pidfd_open() allows to retrieve file descriptors for a given pid. This
includes both file descriptors for processes and file descriptors for
threads.
With the addition of this syscalls pidfds become independent of procfs just
as pids are. Of c
69 matches
Mail list logo
