On Saturday 14 March 2015 15:03:08 Josh Triplett wrote:
> I had to think about this for a while, but I think it makes sense now.
> wait should *not* ever return the PID of an autoreaped process, because
> that would introduce a race condition (the caller cannot safely do
> *anything* with the PID o
On Sat, Mar 14, 2015 at 09:30:29PM +0100, Oleg Nesterov wrote:
> On 03/14, Josh Triplett wrote:
> >
> > What I was proposing was that a task that isn't yet dead, but that is
> > going to be autoreaped, is not eligible for waiting either. All the
> > various wait* familiy of system calls should pre
On Sat, Mar 14, 2015 at 03:14:14PM +0100, Oleg Nesterov wrote:
> Again, again, I didn't read this series yet. But the proper solution (afaics)
> should move this "autoreap" check in release_task/__ptrace_detach(). If the
> task is traced. Debugger should check ->autoreap and skip another
> do_notif
On Sat, Mar 14, 2015 at 07:54:24PM +0100, Oleg Nesterov wrote:
> On 03/14, Thiago Macieira wrote:
> > On Saturday 14 March 2015 15:32:35 Oleg Nesterov wrote:
> > > It is not clear to me what do_wait() should do with ->autoreap child, even
> > > ignoring ptrace.
> > >
> > > Just suppose that real_pa
On 03/14, Josh Triplett wrote:
>
> What I was proposing was that a task that isn't yet dead, but that is
> going to be autoreaped, is not eligible for waiting either. All the
> various wait* familiy of system calls should pretend it doesn't exist at
> all, because returning an autoreaped task from
On 03/14, Josh Triplett wrote:
>
> On Sat, Mar 14, 2015 at 08:18:36PM +0100, Oleg Nesterov wrote:
>
> Is there any information somewhere on how this state machine of doom is
> *supposed* to work? :)
This looks as if you think that other parts of this kernel differ ;)
> Why would "p->task_state ==
On Sat, Mar 14, 2015 at 08:47:21PM +0100, Oleg Nesterov wrote:
> On 03/14, Oleg Nesterov wrote:
> >
> > On 03/14, Josh Triplett wrote:
> > >
> > > On Sat, Mar 14, 2015 at 11:38:29AM -0700, Thiago Macieira wrote:
> > > > On Saturday 14 March 2015 15:32:35 Oleg Nesterov wrote:
> > > > > It is not cle
On Sat, Mar 14, 2015 at 08:18:36PM +0100, Oleg Nesterov wrote:
> On 03/14, Josh Triplett wrote:
> >
> > On Sat, Mar 14, 2015 at 11:38:29AM -0700, Thiago Macieira wrote:
> > > On Saturday 14 March 2015 15:32:35 Oleg Nesterov wrote:
> > > > It is not clear to me what do_wait() should do with ->autore
On 03/14, Oleg Nesterov wrote:
>
> On 03/14, Josh Triplett wrote:
> >
> > On Sat, Mar 14, 2015 at 11:38:29AM -0700, Thiago Macieira wrote:
> > > On Saturday 14 March 2015 15:32:35 Oleg Nesterov wrote:
> > > > It is not clear to me what do_wait() should do with ->autoreap child,
> > > > even
> > >
On Sat, Mar 14, 2015 at 08:24:56PM +0100, Oleg Nesterov wrote:
> On 03/14, Josh Triplett wrote:
> >
> > On Sat, Mar 14, 2015 at 03:35:58PM +0100, Oleg Nesterov wrote:
> > > On 03/12, Josh Triplett wrote:
> > > >
> > > > @@ -598,7 +600,9 @@ static void exit_notify(struct task_struct *tsk,
> > > > i
On 03/14, Josh Triplett wrote:
>
> On Sat, Mar 14, 2015 at 03:35:58PM +0100, Oleg Nesterov wrote:
> > On 03/12, Josh Triplett wrote:
> > >
> > > @@ -598,7 +600,9 @@ static void exit_notify(struct task_struct *tsk, int
> > > group_dead)
> > > if (group_dead)
> > > kill_orphaned_pgrp(tsk
On 03/14, Josh Triplett wrote:
>
> On Sat, Mar 14, 2015 at 11:38:29AM -0700, Thiago Macieira wrote:
> > On Saturday 14 March 2015 15:32:35 Oleg Nesterov wrote:
> > > It is not clear to me what do_wait() should do with ->autoreap child, even
> > > ignoring ptrace.
> > >
> > > Just suppose that real_
On Sat, Mar 14, 2015 at 03:35:58PM +0100, Oleg Nesterov wrote:
> On 03/12, Josh Triplett wrote:
> >
> > @@ -598,7 +600,9 @@ static void exit_notify(struct task_struct *tsk, int
> > group_dead)
> > if (group_dead)
> > kill_orphaned_pgrp(tsk->group_leader, NULL);
> >
> > - if (un
On Sat, Mar 14, 2015 at 11:38:29AM -0700, Thiago Macieira wrote:
> On Saturday 14 March 2015 15:32:35 Oleg Nesterov wrote:
> > It is not clear to me what do_wait() should do with ->autoreap child, even
> > ignoring ptrace.
> >
> > Just suppose that real_parent has a single "autoreap" child. Should
On 03/14, Thiago Macieira wrote:
>
> On Saturday 14 March 2015 15:32:35 Oleg Nesterov wrote:
> > It is not clear to me what do_wait() should do with ->autoreap child, even
> > ignoring ptrace.
> >
> > Just suppose that real_parent has a single "autoreap" child. Should
> > wait(NULL) hanf then?
>
>
On Saturday 14 March 2015 15:32:35 Oleg Nesterov wrote:
> It is not clear to me what do_wait() should do with ->autoreap child, even
> ignoring ptrace.
>
> Just suppose that real_parent has a single "autoreap" child. Should
> wait(NULL) hanf then?
It should ignore the child that is set to autorea
On 03/12, Josh Triplett wrote:
>
> @@ -598,7 +600,9 @@ static void exit_notify(struct task_struct *tsk, int
> group_dead)
> if (group_dead)
> kill_orphaned_pgrp(tsk->group_leader, NULL);
>
> - if (unlikely(tsk->ptrace)) {
> + if (tsk->autoreap) {
> + autor
And let me add another note before I forget...
On 03/14, Oleg Nesterov wrote:
>
> On 03/13, j...@joshtriplett.org wrote:
> >
> >
> > A process launching a new process with CLONE_FD is explicitly requesting
> > that the process be automatically reaped without any other process
> > having to wait on
On 03/13, j...@joshtriplett.org wrote:
>
> On Fri, Mar 13, 2015 at 05:21:13PM +0100, Oleg Nesterov wrote:
> >
> > Again, I simply do not know what this code does at all. But I bet the usage
> > of EXIT_DEAD is wrong ;)
> >
> > OK, OK, I can be wrong. But I simply do not see what protects this
> >
On Fri, Mar 13, 2015 at 3:34 PM, wrote:
> On Fri, Mar 13, 2015 at 03:28:26PM -0700, Andy Lutomirski wrote:
>> On Fri, Mar 13, 2015 at 3:20 PM, wrote:
>> > On Fri, Mar 13, 2015 at 02:34:58PM -0700, Andy Lutomirski wrote:
>> >> On Fri, Mar 13, 2015 at 12:57 PM, wrote:
>> >> > A process launchin
On Fri, Mar 13, 2015 at 03:28:26PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 13, 2015 at 3:20 PM, wrote:
> > On Fri, Mar 13, 2015 at 02:34:58PM -0700, Andy Lutomirski wrote:
> >> On Fri, Mar 13, 2015 at 12:57 PM, wrote:
> >> > A process launching a new process with CLONE_FD is explicitly requ
On Fri, Mar 13, 2015 at 3:20 PM, wrote:
> On Fri, Mar 13, 2015 at 02:34:58PM -0700, Andy Lutomirski wrote:
>> On Fri, Mar 13, 2015 at 12:57 PM, wrote:
>> > A process launching a new process with CLONE_FD is explicitly requesting
>> > that the process be automatically reaped without any other pr
On Fri, Mar 13, 2015 at 02:34:58PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 13, 2015 at 12:57 PM, wrote:
> > A process launching a new process with CLONE_FD is explicitly requesting
> > that the process be automatically reaped without any other process
> > having to wait on it. The task needs
On Fri, Mar 13, 2015 at 12:57 PM, wrote:
> On Fri, Mar 13, 2015 at 05:21:13PM +0100, Oleg Nesterov wrote:
>> Josh,
>>
>> I'll certainly try to read this series, but not before next week.
>
> Thanks for looking at it.
>
>> but a couple of nits right now.
>>
>> On 03/12, Josh Triplett wrote:
>> >
>
On Fri, Mar 13, 2015 at 05:21:13PM +0100, Oleg Nesterov wrote:
> Josh,
>
> I'll certainly try to read this series, but not before next week.
Thanks for looking at it.
> but a couple of nits right now.
>
> On 03/12, Josh Triplett wrote:
> >
> > When passed CLONE_FD, clone4 will return a file des
Josh,
I'll certainly try to read this series, but not before next week.
but a couple of nits right now.
On 03/12, Josh Triplett wrote:
>
> When passed CLONE_FD, clone4 will return a file descriptor rather than a
> PID. When the child process exits, it gets automatically reaped,
And even I have
When passed CLONE_FD, clone4 will return a file descriptor rather than a
PID. When the child process exits, it gets automatically reaped, and
the file descriptor becomes readable, producing a structure containing
the exit code and user/system time. The file descriptor also works in
epoll, poll, o
27 matches
Mail list logo
