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 wa
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 awa
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, 2
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 P
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 w
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 09:48:
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 9
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 ident
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 nea
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() sys
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 g
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 /pro
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 co
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 qu
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
> > > a
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 sugg
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 "p
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 Ko
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
> > picke
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 fu
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 patchs
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, IIR
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. Mu
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. Multiple people have asked when this patchset will be sent in
for me
28 matches
Mail list logo
