NetBSD Problem Report #59127

From www@netbsd.org  Tue Mar  4 13:02:27 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 68CB21A923D
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  4 Mar 2025 13:02:27 +0000 (UTC)
Message-Id: <20250304130226.2DF731A923F@mollari.NetBSD.org>
Date: Tue,  4 Mar 2025 13:02:26 +0000 (UTC)
From: pho@cielonegro.org
Reply-To: pho@cielonegro.org
To: gnats-bugs@NetBSD.org
Subject: clock_getres(2) returns EINVAL for CLOCK_{PROCESS,THREAD}_CPUTIME_ID
X-Send-Pr-Version: www-1.0

>Number:         59127
>Category:       kern
>Synopsis:       clock_getres(2) returns EINVAL for CLOCK_{PROCESS,THREAD}_CPUTIME_ID
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 04 13:05:00 +0000 2025
>Closed-Date:    
>Last-Modified:  Thu Mar 27 08:10:01 +0000 2025
>Originator:     PHO
>Release:        10 and CURRENT
>Organization:
TNF
>Environment:
NetBSD yukari.cielonegro.org 10.0 NetBSD 10.0 (GENERIC64) #0: Thu Mar 28 08:33:33 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm
>Description:
clock_getres(2) returns EINVAL for CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID instead of returning resolutions. The syscall should support these clocks too, as clock_gettime(2) supports them.
>How-To-Repeat:
#include <time.h>
#include <stdio.h>

int main() {
    struct timespec ts;
    int ret = clock_getres(CLOCK_PROCESS_CPUTIME_ID, &ts);
    printf("clock_getres() returned %d\n", ret);
    return 0;
}

>Fix:
A patch is here:
https://github.com/depressed-pho/netbsd-src/commit/ebf335048a3a4684b05c4efd07acaeae2b8c0cf0

I believe the patch is correct, because the time values that clock_gettime(2) obtains ultimately come from timecounter(9) through calcru() or addrulwp(). But correct me if I'm wrong, as I'm not familiar with these things.

>Release-Note:

>Audit-Trail:
From: "Masatake Daimon" <pho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59127 CVS commit: pkgsrc/lang/ghc910
Date: Wed, 5 Mar 2025 03:33:59 +0000

 Module Name:	pkgsrc
 Committed By:	pho
 Date:		Wed Mar  5 03:33:59 UTC 2025

 Modified Files:
 	pkgsrc/lang/ghc910: Makefile buildlink3.mk distinfo
 Added Files:
 	pkgsrc/lang/ghc910/patches: patch-libraries_base_src_System_CPUTime.hsc
 	    patch-libraries_ghc-internal_configure.ac

 Log Message:
 lang/ghc910: Work around PR kern/59127

 This causes a behaviour change in the library "base". A recursive revbump
 will be needed.


 To generate a diff of this commit:
 cvs rdiff -u -r1.3 -r1.4 pkgsrc/lang/ghc910/Makefile \
     pkgsrc/lang/ghc910/buildlink3.mk
 cvs rdiff -u -r1.7 -r1.8 pkgsrc/lang/ghc910/distinfo
 cvs rdiff -u -r0 -r1.1 \
     pkgsrc/lang/ghc910/patches/patch-libraries_base_src_System_CPUTime.hsc
 cvs rdiff -u -r0 -r1.3 \
     pkgsrc/lang/ghc910/patches/patch-libraries_ghc-internal_configure.ac

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Masatake Daimon" <pho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59127 CVS commit: src
Date: Wed, 19 Mar 2025 14:27:05 +0000

 Module Name:	src
 Committed By:	pho
 Date:		Wed Mar 19 14:27:05 UTC 2025

 Modified Files:
 	src/doc: CHANGES
 	src/sys/kern: kern_time.c
 	src/tests/lib/libc/sys: t_clock_gettime.c

 Log Message:
 clock_getres(2): Support CLOCK_{PROCESS,THREAD}_CPUTIME_ID

 The syscall previously returned EINVAL for these two clocks. It still has
 no support for CLOCK_VIRTUAL and CLOCK_PROF but clock_gettime(2) doesn't
 either.

 Fixes PR kern/59127


 To generate a diff of this commit:
 cvs rdiff -u -r1.3144 -r1.3145 src/doc/CHANGES
 cvs rdiff -u -r1.227 -r1.228 src/sys/kern/kern_time.c
 cvs rdiff -u -r1.6 -r1.7 src/tests/lib/libc/sys/t_clock_gettime.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: pho@NetBSD.org
State-Changed-When: Mon, 24 Mar 2025 17:28:38 +0000
State-Changed-Why:
The change has been committed now.


State-Changed-From-To: closed->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Tue, 25 Mar 2025 19:49:38 +0000
State-Changed-Why:
Does this need pullup-9, pullup-10?


State-Changed-From-To: needs-pullups->open
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Tue, 25 Mar 2025 19:53:10 +0000
State-Changed-Why:
The test case still has an atf_tc_expect_fail.  Why is that?  If the
bug is fixed, there should be no atf_tc_expect_fail left.  If the bug
is still there, there should be an open PR for it, cited in the
atf_tc_expect_fail message.


From: PHO <pho@cielonegro.org>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
 netbsd-bugs@netbsd.org, riastradh@NetBSD.org
Cc: 
Subject: Re: kern/59127 (clock_getres(2) returns EINVAL for
 CLOCK_{PROCESS,THREAD}_CPUTIME_ID)
Date: Thu, 27 Mar 2025 17:09:44 +0900

 > Does this need pullup-9, pullup-10?

 I don't think so, because it was just a missing feature and wasn't 
 really a bug.

 > The test case still has an atf_tc_expect_fail.  Why is that?  If the
 > bug is fixed, there should be no atf_tc_expect_fail left.  If the bug
 > is still there, there should be an open PR for it, cited in the
 > atf_tc_expect_fail message.

 Because I don't know what to do. Our clock_settime.2 lists two 
 additional clocks CLOCK_VIRTUAL and CLOCK_PROF which neither 
 clock_gettime(2) nor clock_getres(2) support. These syscalls both return 
 EINVAL for these clocks. Do you have any idea why they are listed at all?

>Unformatted:

Home	PR Database Search