Q: do_notify_parent/do_notify_parent_cldstop && info.si_xtime

Q: do_notify_parent/do_notify_parent_cldstop && info.si_xtime

[Oleg Nesterov]

do_notify_parent() reports .si_Xtime = tsk->Xtime + signal->Xtime,
but do_notify_parent_cldstop() uses .si_Xtime =  tsk->Xtime.

Is this right?

Yes, tsk->Xtime + signal->Xtime does not make much sense for
do_notify_parent_cldstop(), but reporting group_leader->Xtime
(if not traced) doesn't look very right too. IOW, perhaps we
need thread_group_cputime() here?

Ole.

Re: Q: do_notify_parent/do_notify_parent_cldstop && info.si_xtime

[Roland McGrath]

> do_notify_parent() reports .si_Xtime = tsk->Xtime + signal->Xtime,
> but do_notify_parent_cldstop() uses .si_Xtime =  tsk->Xtime.
> 
> Is this right?

si_utime and si_stime are not standardized fields, so there is no
completely clear definition of "right" for these.

> Yes, tsk->Xtime + signal->Xtime does not make much sense for
> do_notify_parent_cldstop(), but reporting group_leader->Xtime
> (if not traced) doesn't look very right too. IOW, perhaps we
> need thread_group_cputime() here?

Solaris also has these fields, and a simple test on Solaris 10 indicates
that it does use the cumulative totals including dead threads for its
CLD_STOPPED SIGCHLDs.  That indeed makes sense to me for process job
control stop reports.

However, I think it makes sense to use just task->?time (as we do now) for
ptrace'd stops.  These notifications are per-thread.  Moreover, this is a
hot path in the context of a ptrace'd process.  thread_group_cputime() is
O(n) in the number of threads, so that would be a bad idea for anything
frequent.  (Real non-ptrace job control stops are not frequent like that.)

The caveats are that probably nobody cares about these values anyway but
any application that does care might already have adapted to the manifest
Linux behavior and be expecting leader-only (it doesn't seem likely to me).


Thanks,
Roland