On Mon, Mar 25, 2019 at 09:54:58PM +, 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 wrote:
> > > On Mon, Mar 25, 2019 at 10:11 PM Joel Fernandes
> > > wrote:
> > >
> > > But often you don't just
On Mon, Mar 25, 2019 at 9:56 AM David Howells wrote:
>
> Daniel Colascione wrote:
>
> > System calls are cheap.
>
> Only to a point. x86_64 will have an issue when we hit syscall 512. We're
> currently at 427.
>
I don't consider this to be a problem. I have patches to make this
problem go
On Mon, Mar 25, 2019 at 3:37 PM Jonathan Kowalski wrote:
>
> 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,
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 wrote:
> > > > On Mon, Mar 25, 2019 at 10:11
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 wrote:
> > > On Mon, Mar 25, 2019 at 10:11 PM Joel Fernandes
> > > wrote:
> > >
> > > But often you don't just want to
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
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:
> > On Mon, Mar 25, 2019 at 09:15:45PM +0100, Christian Brauner wrote:
> > > On Mon, Mar 25, 2019 at 01:36:14PM -0400, Joel Fernandes wrote:
> > > > On Mon, Mar 25, 2019 at
On Mon, Mar 25, 2019 at 10:11 PM Joel Fernandes wrote:
> On Mon, Mar 25, 2019 at 09:15:45PM +0100, Christian Brauner wrote:
> > On Mon, Mar 25, 2019 at 01:36:14PM -0400, Joel Fernandes wrote:
> > > On Mon, Mar 25, 2019 at 09:48:43AM -0700, Daniel Colascione wrote:
> > > > On Mon, Mar 25, 2019 at
On Mon, Mar 25, 2019 at 9:40 PM Jonathan Kowalski wrote:
> 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
On Mon, Mar 25, 2019 at 2:11 PM Joel Fernandes wrote:
>
> On Mon, Mar 25, 2019 at 09:15:45PM +0100, Christian Brauner wrote:
> > On Mon, Mar 25, 2019 at 01:36:14PM -0400, Joel Fernandes wrote:
> > > On Mon, Mar 25, 2019 at 09:48:43AM -0700, Daniel Colascione wrote:
> > > > On Mon, Mar 25, 2019 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 09:15:45PM +0100, Christian Brauner wrote:
> On Mon, Mar 25, 2019 at 01:36:14PM -0400, Joel Fernandes wrote:
> > On Mon, Mar 25, 2019 at 09:48:43AM -0700, Daniel Colascione wrote:
> > > On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner
> > > wrote:
> > > > The pidctl()
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 09:34:00PM +0100, Jann Horn wrote:
> On Mon, Mar 25, 2019 at 9:15 PM Daniel Colascione wrote:
> > On Mon, Mar 25, 2019 at 12:42 PM Jonathan Kowalski
> > wrote:
> > > On Mon, Mar 25, 2019 at 6:57 PM Daniel Colascione
> > > wrote:
> [...]
> > > Yes, but everything in
On Mon, Mar 25, 2019 at 9:15 PM Daniel Colascione wrote:
> On Mon, Mar 25, 2019 at 12:42 PM Jonathan Kowalski
> wrote:
> > On Mon, Mar 25, 2019 at 6:57 PM Daniel Colascione wrote:
[...]
> > Yes, but everything in /proc is not equivalent to an attribute, or an
> > option, and depending on its
On Mon, Mar 25, 2019 at 12:42 PM Jonathan Kowalski wrote:
>
> 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..]
>
On Mon, Mar 25, 2019 at 01:36:14PM -0400, Joel Fernandes wrote:
> On Mon, Mar 25, 2019 at 09:48:43AM -0700, Daniel Colascione wrote:
> > On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner
> > wrote:
> > > The pidctl() syscalls builds on, extends, and improves translate_pid()
> > > [4].
> > > I
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't like the idea of having one kind of pollfd be pollable and
> > >
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'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
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
On Mon, Mar 25, 2019 at 10:36 AM Joel Fernandes wrote:
>
> On Mon, Mar 25, 2019 at 09:48:43AM -0700, Daniel Colascione wrote:
> > On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner
> > wrote:
> > > The pidctl() syscalls builds on, extends, and improves translate_pid()
> > > [4].
> > > I quote
On Mon, Mar 25, 2019 at 09:48:43AM -0700, Daniel Colascione wrote:
> On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner
> wrote:
> > The pidctl() syscalls builds on, extends, and improves translate_pid() [4].
> > I quote Konstantins original patchset first that has already been acked and
> >
On 25.03.2019 19:48, Daniel Colascione wrote:
On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner wrote:
The pidctl() syscalls builds on, extends, and improves translate_pid() [4].
I quote Konstantins original patchset first that has already been acked and
picked up by Eric before and whose
On Mon, Mar 25, 2019 at 10:05 AM Konstantin Khlebnikov
wrote:
> On 25.03.2019 19:48, Daniel Colascione wrote:
> > On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner
> > wrote:
> >> The pidctl() syscalls builds on, extends, and improves translate_pid() [4].
> >> I quote Konstantins original
On Mon, Mar 25, 2019 at 9:56 AM David Howells wrote:
> Daniel Colascione wrote:
>
> > System calls are cheap.
>
> Only to a point. x86_64 will have an issue when we hit syscall 512. We're
> currently at 427.
IIRC, a while ago, someone proposed restarting system call numbering
above (again,
Daniel Colascione wrote:
> System calls are cheap.
Only to a point. x86_64 will have an issue when we hit syscall 512. We're
currently at 427.
David
On Mon, Mar 25, 2019 at 9:21 AM Christian Brauner wrote:
> The pidctl() syscalls builds on, extends, and improves translate_pid() [4].
> I quote Konstantins original patchset first that has already been acked and
> picked up by Eric before and whose functionality is preserved in this
> syscall.
27 matches
Mail list logo
