From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B12631714A for ; Tue, 16 Jun 2026 12:53:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781614424; cv=none; b=qf/COkA8+waPVQs0EU8GbZwr3WLAYF8gizCjVB8EoBpN43TZqWxP9KG5CjnBpVPqA2qvovVcPmMvHciDHwhvp8G34cEEfsTsPCiSHpG5Mcha3Hr4CJn6GqPgppnfrbXYgxIc75xcg12oW/7sBLfh7eyoN0lVcLl0SvuhWF0hsOU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781614424; c=relaxed/simple; bh=VMKqBwLbBcPZCb63KltukbwE8OfPJ/5Dp9lMySerd4Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l3ixE/UEOXW9eljMbQ6SOW4uqW0HGQArQubOu0aXMFUjQ4mwu8eVzHlFQEnFulHiZOjrG5b/5pS7Hv+1vpX6sfsbkhaxH4mcEMjke5fzdHvkOLKj9eQWSKmUNf4n1gHRczcWosGu0GbOJe+LyoZCyrmXqi7hOll+yv5tPQqMFv0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eyoXxas/; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eyoXxas/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8F7F1F00A3A; Tue, 16 Jun 2026 12:53:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781614423; bh=83z/zeh3Belfje80//e/skXWIKxF2DIMZ1Ndw+l0M6k=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=eyoXxas/GznfBa6u6XoxAep0IZISJVe1PkBB6XWp/uYMZonS8wp63MzTdsPVOs0Nl d+VnWbcwTipAf76AHPtf++7LED/nhkfDZsGTcTxmY8wCcSaGSiCcuIh6td+aiOpGqE APxVq/VXKuiUkKzIJ3sywI5GsX4muwFOm+cjmAE/W3uksPSkMfivwA4IA1CJk9xQTS BICQ8W+clLGpVERBsiKSGcKkkrU1cxpGEGUhPlnRF0JFBC7Z0N4Ec80hmCrDRo2ohg zdy3q/5KOxyCSImepmHpCKq32EAsbxBh4Eaj5ymZWbheLyBZ1HCtt+MeEa52LYZebK Q7RHXaGS7+H9g== Date: Tue, 16 Jun 2026 14:53:39 +0200 From: Ingo Molnar To: Zhan Xusheng Cc: Thomas Gleixner , Anna-Maria Behnsen , Frederic Weisbecker , linux-kernel@vger.kernel.org, Zhan Xusheng Subject: Re: [PATCH] posix-cpu-timers: use u64 multiplication in update_rlimit_cpu() Message-ID: References: <20260616112017.1681372-1-zhanxusheng@xiaomi.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260616112017.1681372-1-zhanxusheng@xiaomi.com> * Zhan Xusheng wrote: > update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with > > u64 nsecs = rlim_new * NSEC_PER_SEC; > > On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC > (1000000000L) are 32-bit, so the multiplication is performed in > unsigned long and truncated for rlim_new > 4 before being widened to > u64. > > The same file already casts to u64 for the matching computation in > check_process_timers(): > > u64 softns = (u64)soft * NSEC_PER_SEC; > > As a result, the truncated value is installed into the CPUCLOCK_PROF > expiry cache (nextevt), causing the process CPU timer to be programmed > to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The > actual SIGXCPU/SIGKILL decision in check_process_timers() already casts > to u64 and is therefore correct, so limit enforcement is not broken; > only the expiry-cache programming is wrong. Apply the same cast here so > both paths convert rlim_cur identically. > > 64-bit kernels are unaffected. > > Fixes: 858cf3a8c599 ("timers/itimer: Convert internal cputime_t units to nsec") > Signed-off-by: Zhan Xusheng > --- > kernel/time/posix-cpu-timers.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c > index 74775b94d11b..5e633d8750d1 100644 > --- a/kernel/time/posix-cpu-timers.c > +++ b/kernel/time/posix-cpu-timers.c > @@ -41,7 +41,7 @@ void posix_cputimers_group_init(struct posix_cputimers *pct, u64 cpu_limit) > */ > int update_rlimit_cpu(struct task_struct *task, unsigned long rlim_new) > { > - u64 nsecs = rlim_new * NSEC_PER_SEC; > + u64 nsecs = (u64)rlim_new * NSEC_PER_SEC; Wouldn't it be more robust to define NSEC_PER_SEC not as 1000000000L, but 1000000000LL? (Together with sorting out the inevitable side effects.) Ie. in any logic that uses NSEC_PER_SEC multiplication we should default to 64-bit arithmetics and not silent truncation to 32-bit width. With that we could remove a number of '(u64)' forced type conversions as well. Thanks, Ingo