On Tue, Apr 16, 2019 at 8:21 PM Joel Fernandes wrote:
>
> On Tue, Apr 16, 2019 at 02:04:31PM +0200, Oleg Nesterov wrote:
> > On 04/11, Joel Fernandes (Google) wrote:
> > >
> > > +static unsigned int proc_tgid_base_poll(struct file *file, struct
> > > poll_table_struct *pts)
> > > +{
> > > +
On Mon, Apr 15, 2019 at 9:34 PM Andy Lutomirski wrote:
>
> On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote:
> >
> > On 2019-04-15, Enrico Weigelt, metux IT consult wrote:
> > > > This patchset makes it possible to retrieve pid file descriptors at
> > > > process creation time by introducing
On Mon, Apr 15, 2019 at 2:25 PM Oleg Nesterov wrote:
>
> On 04/15, Christian Brauner wrote:
> >
> > > CLONE_PARENT_SETTID doesn't look very usefule, so what if we add
> > >
> > > if ((clone_flags & (CLONE_PIDFD|CLONE_PARENT_SETTID)) ==
> > >
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
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
&g
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
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
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
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
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:1
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
On Sat, Mar 30, 2019 at 2:37 PM Christian Brauner wrote:
>
> On Sat, Mar 30, 2019 at 12:53:57PM +0100, Jürg Billeter wrote:
> > On Fri, 2019-03-29 at 16:54 +0100, Christian Brauner wrote:
> > > diff --git a/include/uapi/linux/wait.h b/include/uapi/linux/wait.h
> > > index
On Sat, Mar 30, 2019 at 7:39 AM Daniel Colascione wrote:
>
> [SNIP]
>
> Thanks again.
>
> I agree that the operation we're discussing has a simple signature,
> but signature flexibility isn't the only reason to prefer a system
> call over an ioctl. There are other reasons for preferring system
>
On Sat, Mar 30, 2019 at 5:35 AM Daniel Colascione wrote:
>
> On Thu, Mar 28, 2019 at 3:38 AM Christian Brauner
> wrote:
> >
> > > All that said, thanks for the work on this once again. My intention is
> > > just that we don't end up with an API that could have been done better
> > > and be
pidfd_open is open pidfd for pid relative to pidns, so a better
analogy is that it is like openat for a relative pathname wrt dirfd.
O_DIRECTORY is analogous to what type of object, so a TIDFD flag in
the future which interprets pid (pathname) as thread id only and pins
that specific struct pid.
On Wed, Mar 27, 2019 at 9:34 PM Christian Brauner wrote:
>
> On Wed, Mar 27, 2019 at 07:38:13PM +, Jonathan Kowalski wrote:
> > Christian,
> >
> > Giving this some thought, it looks fine to me, but I am not convinced
> > this should take a pid argument. I mu
On Wed, Mar 27, 2019 at 7:38 PM Jonathan Kowalski wrote:
> ...
> ... the process cannot get it out
> of thin air on its own (and you already mentioned it has nothing to do
> with security). What I do worry about is one can use NS_GET_PARENT
disregard this, it works as it should.
&g
Christian,
Giving this some thought, it looks fine to me, but I am not convinced
this should take a pid argument. I much prefer if obtaining a pidfd
goes in the translation stuff, that has very real usecases, and you
would end up duplicating the same thing over in two places.
If the /proc/ dir
On Mon, Mar 25, 2019 at 10:07 PM Daniel Colascione wrote:
>
> On Mon, Mar 25, 2019 at 2:55 PM Jonathan Kowalski wrote:
> >
> > On Mon, Mar 25, 2019 at 9:43 PM Joel Fernandes
> > wrote:
> > >
> > > On Mon, Mar 25, 2019 at 10:19:26PM +0100, Jann Horn wr
On Mon, Mar 25, 2019 at 9:43 PM Joel Fernandes wrote:
>
> On Mon, Mar 25, 2019 at 10:19:26PM +0100, Jann Horn wrote:
> > On Mon, Mar 25, 2019 at 10:11 PM Joel Fernandes
> > wrote:
> >
> > But often you don't just want to wait for a single thing to happen;
> > you want to wait for many things at
Also, extending this further, instead of new ioctl flags over to
translate a tidfd one might introduce later for thread targetted
signals (which would still be a pidfd in the struct pid terms, but
with a bit set in its reference to target the selected TID in
particular), you could resolve this
On Mon, Mar 25, 2019 at 8:34 PM Jann Horn wrote:
>
> [...SNIP...]
>
> Please don't do that. /proc/$pid/fd refers to the set of file
> descriptors the process has open, and semantically doesn't have much
> to do with the identity of the process. If you want to have a procfs
> directory entry for
On Mon, Mar 25, 2019 at 6:57 PM Daniel Colascione wrote:
>
> On Mon, Mar 25, 2019 at 11:19 AM Jonathan Kowalski
> wrote:
> >
> > On Mon, Mar 25, 2019 at 5:53 PM Daniel Colascione wrote:
> > >
> > > [..snip..]
> > >
> > > I don
d Bergmann
> Cc: "Eric W. Biederman"
> Cc: Kees Cook
> Cc: Alexey Dobriyan
> Cc: Thomas Gleixner
> Cc: Jann Horn Cc: "Michael Kerrisk (man-pages)"
> Cc: Konstantin Khlebnikov
> Cc: Jonathan Kowalski
> Cc: "Dmitry V. Levin"
> Cc: Andy Lu
On Mon, Mar 25, 2019 at 5:53 PM Daniel Colascione wrote:
>
> [..snip..]
>
> I don't like the idea of having one kind of pollfd be pollable and
> another not. Such an interface would be confusing for users. If, as
> you suggest below, we instead make the procfs-less FD the only thing
> we call a
25 matches
Mail list logo
