linux-kernel - Re: Q: do_notify_parent/do_notify_parent_cldstop && info.si

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] [day] [month] [year] [list]

Date:	Tue, 26 May 2009 18:40:19 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Q: do_notify_parent/do_notify_parent_cldstop && info.si_xtime

> 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
--
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/