linux-kernel - Re: [patch] make siginfo_t si_utime + si_sstime report times in USER

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080627163333.GB508@tv-sign.ru>
Date:	Fri, 27 Jun 2008 20:33:33 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Michael Kerrisk <mtk.manpages@...glemail.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bart Van Assche <bart.vanassche@...il.com>,
	Roland McGrath <roland@...hat.com>
Subject: Re: [patch] make siginfo_t si_utime + si_sstime report times in USER_HZ, not HZ

On 06/27, Michael Kerrisk wrote:
>
> On Thu, Jun 26, 2008 at 5:09 PM, Michael Kerrisk
> <mtk.manpages@...glemail.com> wrote:
> > On Wed, Jun 25, 2008 at 5:38 PM, Oleg Nesterov <oleg@...sign.ru> wrote:
> >> On 06/25, Michael Kerrisk wrote:
> >>>
> >>> --- /home/mtk/ARCHIVE/KERNEL/linux-2.6.26-rc7/kernel/signal.c.orig    2008-06-24
> >>> 16:20:39.000000000 +0200
> >>> +++ /home/mtk/ARCHIVE/KERNEL/linux-2.6.26-rc7/kernel/signal.c 2008-06-24
> >>> 16:22:17.000000000 +0200
> >>> @@ -1379,10 +1379,9 @@
> >>>
> >>>       info.si_uid = tsk->uid;
> >>>
> >>> -     /* FIXME: find out whether or not this is supposed to be c*time. */
> >>> -     info.si_utime = cputime_to_jiffies(cputime_add(tsk->utime,
> >>> +     info.si_utime = cputime_to_clock_t(cputime_add(tsk->utime,
> >>>                                                      tsk->signal->utime));
> >>> -     info.si_stime = cputime_to_jiffies(cputime_add(tsk->stime,
> >>> +     info.si_stime = cputime_to_clock_t(cputime_add(tsk->stime,
> >>>                                                      tsk->signal->stime));
> >>>
> >>>       info.si_status = tsk->exit_code & 0x7f;
> >>> @@ -1450,9 +1449,8 @@
> >>>
> >>>       info.si_uid = tsk->uid;
> >>>
> >>> -     /* FIXME: find out whether or not this is supposed to be c*time. */
> >>> -     info.si_utime = cputime_to_jiffies(tsk->utime);
> >>> -     info.si_stime = cputime_to_jiffies(tsk->stime);
> >>> +     info.si_utime = cputime_to_clock_t(tsk->utime);
> >>> +     info.si_stime = cputime_to_clock_t(tsk->stime);
> >>>
> >>>       info.si_code = why;
> >>>       switch (why) {
> >>
> >> This looks like the obviously good fix to me.
> >
> > Tested now, and it does what I expect.
> >
> >> The patch also deletes the comment about signal_struct->cXtime,
> >> this also looks right: why should we use cutime/cstime ?
> >
> > Hmmm -- maybe I was wrong to delete that comment.  I think the point
> > of the comment was: should the time returned vie these fields of the
> > signinfo structure also include the times for (grand)children of the
> > process that had terminated and been wait()ed for.  My first take on
> > that was "no".  But now I'm not 100% sure.  A quick test on Solaris 8
> > suggests that these fields *do* include the times of waited for
> > children.  (None of this is specified in POSIX.1, which doesn't
> > specify si_utime and si_stime.)  I've not yet tested FreeBSD (not sure
> > if it supports these fields or not).
> 
> So, FreeBSD doesn't implement these fields.  A more extensive test
> (see below) on Solaris (8) shows that it does indeed include the times
> of waited-for children in the si_utime and si_stime fields.
> 
> I'm not sure if we should emulate that behavior or not - it'd be easy
> enough to do so of course.  Thoughts, anyone?

Well, I don't know. But since POSIX says nothing, perhaps there is
no reason to change the historical behaviour?

Anyway, I think you were right to kill this comment, it is very old
(from 2.4.26 at least), and confusing. It looks as if it suggests
to use signal->cXtime _instead_ of utime/stime.


Hmm. do_notify_parent_cldstop() only uses tsk->xtime even if we report
CLD_STOPPED, but tsk is the "random" thread which does finish_stop().
I don't know what is the supposed behaviour in that case... but unlikely
we should use signal->cXtime, another reason to kill the comment ;)

Oleg.

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