From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21FCB37C11C for ; Wed, 17 Jun 2026 21:50:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781733046; cv=none; b=YupW3/+Gz2HtwYgBmTth/cLkuoYLMp6oInZ0+EBAvXCMtjEFQIvI5I2fYOcOVsdXp0v1nwGzGad+OdrKVZn0EN1+0NzAz577xfuPBWTmV20aQQ5nPc4YbUwCr2o8avUCt+6Q4GJSBMEZ4nBXCBiiQKdpAyEmJb3x2Fc/7/C+jtU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781733046; c=relaxed/simple; bh=rPqn3LZx1BYHnAZCjsfH7aW3Uwid3/xrbfg8Av7nv6s=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pEwG/FvEvn/7vZDsbva2/SLvjY1dzAdbC+YjyGSJbhGxhRAwPCVlY0PeCQ49/dMbE6iDw2LtgZsmG6HpWCwOfAcQqo1H2j5ZUL7CoB8Sa3Pwfr3E6YNoaZgmrX9Sw2Lni8+tJG/8IaIRGklFpakuN8hCLtj/4Em0oPlWhrt/Bi8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=RNw1ktgE; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RNw1ktgE" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-490afc47455so609795e9.2 for ; Wed, 17 Jun 2026 14:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781733043; x=1782337843; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=c08Vye2gtiRPCCznnh7BgjR1PnSidPmm1VF5dhIhPBw=; b=RNw1ktgEZHbEggPiYaFeU7+CpqZLbD1Q6FELCPK9N4kC9AD4CWZzhXhyUCwWSlf0TZ V5tj1aHDoCdZpS+2A1QLdhSZxwx2Yv3rEEcFncKuwmVrA/wa1WFU5/z+g7UYI4x1p/f2 Fxoqae6Zb76meqtQJrqHCbBKMmAecKcSaN+sNrD6LQOFsWfVzExNbTtP1gozOb65BVD9 83j4qyPZYcjTh7i+OQswBRUrBoS+UJoUM1rCkg+rcxsswhEgpKDhgDMDfdO8YzFuZ/IT np91n4MULiMmjYk+KuPMEUD0VnmtE8Xqr4rT9XPPJur4B7wt8EAqVR2+8xp0/XpFYqWA AkNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781733043; x=1782337843; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=c08Vye2gtiRPCCznnh7BgjR1PnSidPmm1VF5dhIhPBw=; b=N6/2HEr+b3XyvBxrMqxzBqa41DfQKRCm32eDfvAHZG1tzToNZ1qJLUDQy7aAhzGzv+ JPLK5CY26C5c0DRfAXC9Nq/bGLuDQosMXBTyI9BzmhmcyHofL/2dy9Q9f4cpdu0y2BEh FPW3Fsj/t2MKGovTZBzhFwKESyeNxjTB2HigMfEiYIFWIcbTr5BaQk2Ni2EclufaB0Lo pkV5fpjmS/tk7zeG5hFyi9rEy4SYOtq1YKts8J9NQPkX/fFfqd42PcrmNddebJQQK6v8 uDbiDCarlAjuCbixipa6u/0dD1Ts5MVhN03XxjJ4HZf5IDzQD+IaFVi1TJPCSdmVeQgk 0zDg== X-Forwarded-Encrypted: i=1; AFNElJ93Tgkrd1A6kc6AYrgv8YPba4J+fK+PjXDa3N6ZizILAYCvep88s7pua+ymDO+bAAHS0VFr7GD6hJq8Mfk=@vger.kernel.org X-Gm-Message-State: AOJu0YwlHwvVTC4Xk1FnXl/FYYxVvrTqx2BGtTWgFWaNsG2UAwbHTr5u fSRHPvepLtGMz4rOsRdVNBh3SJ6FBq+SXovxYUTBWsHsQFkzWTLnu+Zb X-Gm-Gg: Acq92OFFYrMOSWN5NqaLJHfJuGFfLeOYqc1V7iPFKWjsN2Ym/snIfqGbeDqjrtv7alx GGuepHlimjLylXodStSl37Q0OidVw5sJ4/CZbbrtuQu/04cwH5tYMBcTO3gnlbDpczhz7FnnSDY QSN9vy2d7dxespT2BEClnWCFW836Bi+ZiRJ+7At3K8uWjR2WbSFBOYq5sHbkmWaUwOPnTQDCOOd IzRlqEKVZki9wPEhy1PtUIVaMQSWFwP7Mfj9MR/wbIlNu6J+cuipBlcrak8aDXKuVqT9IDJG1ib PoOWkTdi0MgErbwVP1sInOKa2WSRnMnPeuppg7l7JiakSV5v6z4KPl4PMSDDUqgOZ9f8edQDIr7 hxSpuFPFtTgtz7ZrF2tLpoiguEYeZ0uj6KH32vTx21/CmGxtsMjiDCOJNR0e6T9Dp87rpXXodk6 f/9s3RE6/sFWKpt+kVKV5BnbXSXow70MRbrOvOWALrwbRk/Fppns9WnUmK/pqu X-Received: by 2002:a05:600c:8518:b0:490:b9c3:6c48 with SMTP id 5b1f17b1804b1-492333dd033mr89389625e9.29.1781733043440; Wed, 17 Jun 2026 14:50:43 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4922fa3a4easm214398285e9.3.2026.06.17.14.50.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 14:50:43 -0700 (PDT) Date: Wed, 17 Jun 2026 22:50:42 +0100 From: David Laight To: Thomas Gleixner Cc: Ingo Molnar , Zhan Xusheng , 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: <20260617225042.7ee15d30@pumpkin> In-Reply-To: <87v7bhcij3.ffs@fw13> References: <20260616112017.1681372-1-zhanxusheng@xiaomi.com> <87v7bhcij3.ffs@fw13> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: 7bit On Wed, 17 Jun 2026 17:07:28 +0200 Thomas Gleixner wrote: > 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. > If the result is assigned to a 32bit variable (and must be max 4 seconds) the the compiler shouldn't bother to calculate the high 32 bits. But, thinking, if you want the 64bit product of two 32bit values you are much better off using an asm block. clang is not to bad, but gcc has a nasty habit of zero-extending both values and doing a full 64x64 multiply. x86 then runs out of registers and spills everything to stack. When I was doing the 64x64/64 code I found it both spilling constant zeros and doing multiplies by constant zero. Thinks more, maybe it is ok when the constant is small but u64. (Too late in the day to check) Possibly a SECS_TO_NSECS(seconds) that generates a 64bit product from the two 32bit values might be the best solution. After all you are pretty much going to need 64bits for the result. David