From nobody Sun Jan 12 16:20:39 2025 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YWLGs6jbgz5ktnt for ; Sun, 12 Jan 2025 16:20:53 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YWLGq3HV0z4tTy for ; Sun, 12 Jan 2025 16:20:51 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dec.sakura.ne.jp header.s=s2405 header.b=XjAFvGOK; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 50CGKexB048652 for ; Mon, 13 Jan 2025 01:20:40 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1736698840; bh=4GoTmhvVNG0hgXnrPMsjb+zNFj5z+UHwxBdrca6YNOc=; h=Date:From:To:Subject:In-Reply-To:References; b=XjAFvGOKewoV75JPiWq9UsVyuA0PTdRMuqNXc/6hDFLfOe/rgxfeDMa/Zl3zTOObE 6w3D6ovToO1+v6pUzp46OSoJ//JjnD+EsS6qgV0lTz9iNmCOOrRW0MwLFLQiqgvrhY p7X+2ZPV3a0PjNInW+Ofyop9GyUN2jyI8aP1ih/o= Date: Mon, 13 Jan 2025 01:20:39 +0900 From: Tomoaki AOKI To: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-Id: <20250113012039.d476e10859c00f7b55f78280@dec.sakura.ne.jp> In-Reply-To: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> <20250112075038.4cd7fc680400e07a32a13f1a@dec.sakura.ne.jp> <20250112111651.e76aea0843ac8f85043c7f10@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4YWLGq3HV0z4tTy X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.21 / 15.00]; URIBL_RED(3.50)[dec.sakura.ne.jp:dkim]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; MV_CASE(0.50)[]; HAS_ANON_DOMAIN(0.10)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; GREYLIST(0.00)[pass,meta]; R_DKIM_ALLOW(0.00)[dec.sakura.ne.jp:s=s2405]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:153.125.133.16/28]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; ARC_NA(0.00)[] On Sun, 12 Jan 2025 10:27:37 -0500 Mark Johnston wrote: > On Sun, Jan 12, 2025 at 11:16:51AM +0900, Tomoaki AOKI wrote: > > Replying to ML only, as Mark's gmail address seems to block previous > > one. > > > > On Sat, 11 Jan 2025 18:00:12 -0500 > > Mark Johnston wrote: > > > > > On Sun, Jan 12, 2025 at 07:50:38AM +0900, Tomoaki AOKI wrote: > > > > On Sat, 11 Jan 2025 17:35:36 -0500 > > > > Mark Johnston wrote: > > > > > > > > > On Sun, Jan 12, 2025 at 04:35:43AM +0900, Tomoaki AOKI wrote: > > > > > > Not an example of code, but for example, when ticksl is at > > > > > > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff > > > > > > (negative value), if I read the diff correctly. > > > > > > The same thing starts happening ticksl is at 0x0000000080000000 throug > > > > > > 0x00000000ffffffff and values alike. So signs (carry bits, usually the > > > > > > leftmost bit of each) should be checked separately for ticksl and ticks. > > > > > > > > > > That's true, but I can't see why any code would care about this? > > > > > > > > While ticks is defined as (signed) int, it shoule be turnaround when it > > > > reaches at 0x7fffffff (as incrementing it causes overflow). > > > > Is ticks allowed to be minus value? My guess is that it is monotonic > > > > counter. > > > > > > Yes, INT_MAX ticks elapse in approximately 25 days at 1000Hz. In fact, > > > ticks is initialized to INT_MAX - in subr_param.c so that > > > it wraps around shortly after boot, after which it is negative. > > > > > > Kernel code should not care about the sign of ticks. > > > > Thanks! I've overlooked it. > > > > BTW, does tickl restricted with INT_MAX, too? (In detail, although tickl > > has the type long, but actually the range of the values used are > > restricted with INT_MAX?) > > No, that's the point of the change: the kernel now increments a counter > of type long, so it will eventually reach LONG_MAX. Existing code which > references ticks will still get a 32-bit value that behaves the same as > before. Thanks. Will read related codes more deeper to understand once I can take long enough time. -- Tomoaki AOKI