Re: [PATCH 6/9] job control: make task_clear_jobctl_pending()clear TRAPPING automatically

[Tejun Heo]

Hello,

On Mon, May 16, 2011 at 02:25:35PM +0200, Oleg Nesterov wrote:
> On 05/13, Tejun Heo wrote:
> >
> > @@ -264,6 +267,9 @@ void task_clear_jobctl_pending(struct task_struct *task, unsigned int mask)
> >  		mask |= JOBCTL_STOP_CONSUME | JOBCTL_STOP_DEQUEUED;
> >
> >  	task->jobctl &= ~mask;
> > +
> > +	if (!(task->jobctl & JOBCTL_PENDING_MASK))
> > +		task_clear_jobctl_trapping(task);
> >  }
> 
> So, SIGCONT clears JOBCTL_TRAPPING and wakes up the tracer.

If JOBCTL_TRAPPING is set && JOBCTL_STOP_PENDING was the only pending
condition.

> I can't really understand this without seeing the next changes, but
> it seems this makes some things worse, although I am not sure.

It's a safety mechanism.  We shouldn't have TRAPPING set when no
stop/trap is pending and the above establishes that invariant and will
also be used to simplify exception cases where all pending conditions
are cleared (tracee being killed).  It's conceptually much easier to
grasp that way - you clear all pending conditions when the task dies
and the mechanism to wait for trap transition is cleared together.

> For example. PTRACE_SEIZE should guarantee the tracee will trap and
> report. However, if the tracee is stopped during attach, we can race
> with SIGCONT. The previous version had the similar problem afaics, but
> it was easy (I think) to fix. Now that SIGCONT clears JOBCTL_TRAPPING
> we need more complications.

This problem doesn't exist anymore.  SEIZE directly schedules
JOBCTL_TRAP_STOP instead of using JOBCTL_STOP_PENDING, so it actually
works exactly as it should.

1. If tracee was stopped and tracer attaches, tracee should re-trap
   and tracer should wait for TRAPPING.

2. If tracee was not stopped and tracer attaches, tracee traps to
   STOP.

3. If tracee was stopped and tracer attaches but SIGCONT is received
   before TRAPPING is done, TRAPPING is cleared and tracer and tracee
   are in the same conditions as #2, which is exactly how they should
   be.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/