threads/180496: clock_gettime() does not return CPU-time for zombie processes

[Konstantin Belousov]

The following reply was made to PR threads/180496; it has been noted by GNATS.

From: Konstantin Belousov <kostikbel at gmail.com>
To: Petr Salinger <Petr.Salinger at seznam.cz>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: threads/180496: clock_gettime() does not return CPU-time for
 zombie processes
Date: Sat, 13 Jul 2013 22:50:03 +0300

 --E/fwm3itKUspkPYj
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Jul 12, 2013 at 10:59:51PM +0200, Petr Salinger wrote:
 > > Please try this.  The clock_gettime() call on zombie clock worked
 > > for me.
 >=20
 > Perfect. Many thanks.
 >=20
 >=20
 > > Note that the check for clock_getres() on the reapped process clock
 > > failed since we do not check for pid validity, all processes has
 > > the same clock.  I do not see much sense in adding the useless check.
 >=20
 > I agree that such check is technically useless.
 > I cannot imagine usage of such restriction.
 >=20
 > The only reason of this check is wording of POSIX standard in
 > http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.ht=
 ml
 >=20
 > "The clock_getres(), clock_gettime(), and clock_settime() functions shall=
 =20
 > fail if:
 > [EINVAL]
 >      The clock_id argument does not specify a known clock."
 I could argue that the clock_id for the reapped pid is/was known.
 
 Anyway, due to our implementation of the clock ids, the id is not a handle,
 but rather a pid-like value.  The reused pid would suddenly revive the
 clock.
 
 >=20
 > But this behaviour can be easily added in userspace wrapper.
 > Similarly as
 > " The clock_settime() function shall fail if:
 > [EINVAL]
 >    The value of the clock_id argument is CLOCK_MONOTONIC."
 >=20
 > The kernel returns EPERM for ordinary user.
 >=20
 >=20
 > Would be possible to MFC SYS_clock_getcpuclockid2
 > and related kernel changes into STABLE-9 ?
 
 stable/9 is frozen for 9.2.  I do not think that re would approve merging
 of the non-critical new feature now.
 
 --E/fwm3itKUspkPYj
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.20 (FreeBSD)
 
 iQIcBAEBAgAGBQJR4a9qAAoJEJDCuSvBvK1BU+oP/iR4xBn66pOaVZ3hZU1W/FIJ
 jBp3X9yjI5XKxVoq/pke5A2nVxaojcIL4V7v8QE+Pb90POpQAJM6cVwZjPPQdRG4
 YGVQo8hXS9l2IuTbrsNy876ioQ9U3T1G530aJ7/h/tgZ1yJjn6eXDeBuAWaFyLfo
 nhoBgAV7PQOmaYvH3+qxuRXwZn/RyjorxrQww4eED+IkMuoL6/JFZTNpWuNwqsU2
 fcc6HVNM5XyheHUbaBn42R5alBkk7U3FwfS5hoqlRb1K+Ps8axTRveRjfcnS12+H
 PmXuliW4kgg4S0WX6TB57Jt7gN6SsjjB7ghCfd9dPt4U0XAUFFCbIza6uWuKhOSw
 f3CTcdTuT0psHIbfl0zucwBY5HJxQgPy0JjtMBuwtdcNizdV2igzl/KzvRzzmSXB
 udHb9gr7x/29RYSZyPD5Rt55ZT0x8Ll237T1Ea5FRk2Jb33A/VIWs12DLXnoWLF9
 xnzUY8VHIAlX0w5vOM3cVbFv0CaJi92oitygxb7Ss60Nv1FSzdQZEeK+gxiKL/EJ
 DX5NU2MYLlpW4ZYpsbgJE/Tu0qR9cl4Us8v43Ip+uWi/pBHBEJPvkdTJTCYlq63R
 oAkvi90GyNXbDxHArq2CKgzRG6MqKCIoN+XZOlporXbRXSD2OqRgY7zQ9KKveUH/
 lDLHDxHJLEIwE8NMF22v
 =WSnN
 -----END PGP SIGNATURE-----
 
 --E/fwm3itKUspkPYj--