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 A39213D8105 for ; Wed, 17 Jun 2026 15:07:31 +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=1781708852; cv=none; b=NFKiBy3r+GNkbqQurluh3LhesGM21MGyyJuITRku2zRjEwnutXD2NrKyKrlVEsoipFPlb49/crxKCi+/D0RPmtjcAc5thWPTPwQql7hGSfDaig0sZPqMJ9F3TwfzpLb5Ab+muA/WLhLX0tpZewtFfl7lbDPNrhpRpXn+oA6KAkY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781708852; c=relaxed/simple; bh=KXgCvi3g3EFtiG4TK9ufxP2XIiuznN6t5VBf0Qbfflc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=SwWrtDQ0CJRiJGlyx235uHPPFEpshsOCZTgMYKZPpsxre17RMRlfv9vEJeDMS4wE9wBwqwAFOXlCvZTxNMjxeWOV5X+JRsrI1jO2ngiMnf+Wz/dx9omsDCCEGeZBDyOXF5iktuT1up32eivjN97y5Jf2k8JKmt27vC1RuZnLAf0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IE9VxZKy; 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="IE9VxZKy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA06E1F000E9; Wed, 17 Jun 2026 15:07:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781708851; bh=DhqqcUA0DKtpyM4kEbT60i+0xUqNIzolAzzZiD2J/Ao=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=IE9VxZKyAjGIKNGTqiJu/2tOBd5aJlYSulzJQ88TQs6P8SLCO8jK/c5INFnwkdOha wc95kJ0t+ElXc2490X5+qb+R9edUPe6Pwxu29BieqfdJreA2K1eYsquEE7AOYp9vHI qx6IwaJCRxvFOWspFY91E6N2g3PyqICHhkxZhLZRp6PwMAxHO5S2eEX+WG8vFrSUOJ tV7VtVFNHQEKATLA2jZ9HRSOPnT5eDL6zPOLp8c41Zq348R6bkFHcVXva7Tn378IpY 9IbzsIpKWc6kh02pA9J3WwGdmKhnWgqZYk5C6OOQmLW6GlT35R9vHD2Qfih2x0jKCh OU4I4wuuHQBSg== From: Thomas Gleixner To: Ingo Molnar , Zhan Xusheng Cc: 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() In-Reply-To: References: <20260616112017.1681372-1-zhanxusheng@xiaomi.com> Date: Wed, 17 Jun 2026 17:07:28 +0200 Message-ID: <87v7bhcij3.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Jun 16 2026 at 14:53, Ingo Molnar wrote: > * 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.) There are a lot of them on 32bit builds. IIRC correctly there was an attempt to do exactly that a few years ago and it didn't go well.