On 11/29, Michael Holzheu wrote:
>
> * I left the struct signal locking in the patch, because I think
> that in order to get consistent data this is necessary.
OK, I guess you mean that we want to read utime/stime "atomically",
and thus we need ->siglock to prevent the race with __exit_signal().
> @@ -30,6 +30,7 @@ void bacct_add_tsk(struct taskstats *sta
> {
> const struct cred *tcred;
> struct timespec uptime, ts;
> + unsigned long flags;
> u64 ac_etime;
>
> BUILD_BUG_ON(TS_COMM_LEN < TASK_COMM_LEN);
> @@ -71,6 +72,12 @@ void bacct_add_tsk(struct taskstats *sta
> stats->ac_majflt = tsk->maj_flt;
>
> strncpy(stats->ac_comm, tsk->comm, sizeof(stats->ac_comm));
> + if (thread_group_leader(tsk) && lock_task_sighand(tsk, &flags)) {
> + struct cdata *cd = &tsk->signal->cdata_wait;
> + stats->ac_cutime = cputime_to_usecs(cd->utime);
> + stats->ac_cstime = cputime_to_usecs(cd->stime);
perhaps we need a small comment to explain ->siglock...
But in fact I don't really understand this anyway. This is called
before we reparent our children. This means that ac_cutime/ac_cstime
can be changed after that (multithreading, or full_cdata_enabled).
Say, taskstats_exit()->fill_stats()->bacct_add_tsk(). Every thread
does this, including the group_leader. But, it is possible that
group_leader exits first, before other threads. IOW, what
stats->ac_cXtime actually mean?
Nevermind, the whole series looks correct to me. Although I still
can't find the time to read it ;) But at first glance this version
addresses all concerns we discussed before.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
