Messages in this thread | | | Date | Sat, 15 Sep 2007 20:51:24 +0200 | From | Guillaume Chazarain <> | Subject | Re: + taskstats-add-all-thread-stats-for-taskstats_cmd_attr_tgid.patch added to -mm tree |
| |
Le Thu, 13 Sep 2007 16:41:41 +0400, Oleg Nesterov <oleg@tv-sign.ru> a écrit :
> (sorry, have no time to read the patch carefully, just a couple of > minor random "unless I misread this patch" nits)
Thank you Oleg, hopefully I addressed all your comments in v4.
> > + do > > + if (!tsk->exit_state) > > + add_tsk(stats, tsk); > > + while_each_thread(first, tsk); > > This reminds me. The "!tsk->exit_state" is not good and racy, it > can't prevent the double accounting (of course, I don't blame this > patch).
I documented this in v4, but I was wondering if always setting tsk->exit_state under the protection of lock_task_sighand() would fix the race.
> > + if (thread_group_leader(task)) { > > + stats->ac_exitcode = task->exit_code; > > + if (task->flags & PF_FORKNOEXEC) > > stats->ac_flag |= AFORK; > > Actually, I can't understand this "thread_group_leader()" check, but
Seems like this code was copied from kernel/acct.c:acct_collect(): if (thread_group_leader(current)) { pacct->ac_exitcode = exitcode; if (current->flags & PF_FORKNOEXEC) pacct->ac_flag |= AFORK; }
> I don't know what ->ac_exitcode and AFORK means to the user-space.
From include/linux/acct.h: executed fork, but did not exec
Except that it talks about fork(2), not do_fork() hence the thread_group_leader() test to avoid flagging threads.
> But it looks a bit suspicious. Perhaps we need > ->signal->group_exit_code, not task->exit_code?
I put ->signal->group_exit_code if not null, otherwise leader->exit_code.
Thank again to you and Andrew for the review.
-- Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |