Message ID | 20231101153237.2214698-1-colin.i.king@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:abcd:0:b0:403:3b70:6f57 with SMTP id f13csp505283vqx; Wed, 1 Nov 2023 08:33:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFGR6MPPMCSx+vx52aCKlWz9+WpImho9XSL32L9C3SS17VA/N9zDHhHF6WuhZJROJkUTkXr X-Received: by 2002:a17:906:c112:b0:9c7:5a01:ffec with SMTP id do18-20020a170906c11200b009c75a01ffecmr2381737ejc.0.1698852789284; Wed, 01 Nov 2023 08:33:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698852789; cv=none; d=google.com; s=arc-20160816; b=zc445lHWD6zicdnfEl8uKGph1YEkET/sDmmVorYQtkRYmY+eUIR6ZL6alXkcaIgWXE ZpUjzH28QqxmAXIA+deurgGc4MTVO+LOJGD0lwHAdarIvYRDaRjpy+GUtf74/cwo3uTN 9CoHP7vqDgJbz5s8Jz+muK17FjyzwfYVsvMjWaD/vxdLZVz2eKOQXVccn63ItDVQYFmb R2w4jaM0w/oAnSeADFlC3S+h0cg5tjbFTGVjF0H83fLGlHznFfMMqUq733MClft5tPvP 4QYSi7c2t5H3CnJBx/U+WVHvf+be4yzfv4rS6cCAPt+CuVdw5RLZlkkuTx03+PIv8dVP 289g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=FskWsrQJNJdVJ7FWmgRoYhcAsvNJ7ClQAxHmsraKq6Q=; fh=pudc4Lu2+vLctiyrRyPxfwEWJfCWFw26dnwj3O3+qqE=; b=l4oxaQbNqbD8LHOiboWzImhX7bT6DivIQG43Ax5fbUvn5QbDj5n5r0AX43Dda3fijH BlpdGPVbjuLjVdtiGfXV5Q7SeAFG18H6iEW/z4sLZmADDuiHqbrOnlKVNZsmeGaqw4g4 Hn5fnbzqLJ7to681Xnho2zZcLt+fEJw0gh2+VmYYy5RAhnPGnxOa84bSlSgkn/na4yFQ 1wHo9LrHYjqIq+TUg5biVYlgHMwh0OhX2HAPaX0qOU+3Bz6zzCALCGVfpqEVp7kFk7Sb kqfAxfYiXUzzQxC7ygSaMCXI1UhYlIw+KuS5BsaUbJz6lbGq/don89WwSSIBeZ00YX3B 1zNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=mD6EUGWQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id j20-20020a170906535400b009c4866f7a58si39685ejo.577.2023.11.01.08.33.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Nov 2023 08:33:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=mD6EUGWQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 5CF9B80CD738; Wed, 1 Nov 2023 08:33:02 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233227AbjKAPco (ORCPT <rfc822;rbbytesnap@gmail.com> + 35 others); Wed, 1 Nov 2023 11:32:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233321AbjKAPcm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Nov 2023 11:32:42 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73363A6; Wed, 1 Nov 2023 08:32:40 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-32f7c44f6a7so2765566f8f.1; Wed, 01 Nov 2023 08:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698852759; x=1699457559; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=FskWsrQJNJdVJ7FWmgRoYhcAsvNJ7ClQAxHmsraKq6Q=; b=mD6EUGWQtP/yvrP3kI4+oepuCKmI/l59dp+h+lRAqXm+9t5INc8yhCc5FkwGhKNpyT jb+d4xs/YFyZN5DiuIFvsc4xpcGcbbRrrfBnA8loqP0c/xlpPgVW8Ra6ofUmcyevSZz6 KpU3vGTA59IJVSwV2OR/gsTyTo1dBscMPQkIhmgbtrIgIgpcp6KL3Qz+LakXzKxYxr7u 8qEOQEtCC1NLO7nh6rhzy0EyubUIW8DWidrN00lSElbuTmBBPQSL5LxHbm5cDbBriH6Q 47mPmLqsa/C/quqJJtd+/TlTQW3X6fuyyw8jzLib3K1433c3WdkZKpk0xCJwfXpYWkE2 uYGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698852759; x=1699457559; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FskWsrQJNJdVJ7FWmgRoYhcAsvNJ7ClQAxHmsraKq6Q=; b=hMHxr/lbE6bgS5uu4z7r6GpcLdBW31BDISDkdCAaI80eVoU1/FQZxcYWIo2NyBofkd Bo6Get9g9elWrIEGzkNHyjHGkvDe1cwFhDpgpAR9ykjXIIfj0yo/ZqNv96oJOW7M+Gfs BW5Y2t0/7ShV2L9xrNr2v6Yi1Gqm6R/zEsQzHaJQHsL/UYE0IKccWbTdedW6hiGfyDAu LkdHc07XQMWmzrs6eWwsidist0IyXw0wddFEcxCvcX0LxBrbCzq6e8j+9iwpOn4tWnxM Fkijwai2/6oBYGTjKSXWvToquux6h/Xixt64nRhBluJQQwObwM2YAlD6YJIVMoWtMQN2 h0JQ== X-Gm-Message-State: AOJu0YzXHv6URbb8UCfgqgj9bhQDLO7REqwWFyutQCZPfJTwwGrxO7At 8Jf948+C5INDr26kea6sBX9LG73CaY0= X-Received: by 2002:a5d:6c61:0:b0:32f:7d50:62ef with SMTP id r1-20020a5d6c61000000b0032f7d5062efmr10448784wrz.13.1698852758575; Wed, 01 Nov 2023 08:32:38 -0700 (PDT) Received: from localhost (cpc154979-craw9-2-0-cust193.16-3.cable.virginm.net. [80.193.200.194]) by smtp.gmail.com with ESMTPSA id d2-20020adffd82000000b003296b488961sm128146wrr.31.2023.11.01.08.32.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Nov 2023 08:32:37 -0700 (PDT) From: Colin Ian King <colin.i.king@gmail.com> To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com> Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] x86/lib: Fix overflow of variable m when val >= 1410065408 Date: Wed, 1 Nov 2023 15:32:37 +0000 Message-Id: <20231101153237.2214698-1-colin.i.king@gmail.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Wed, 01 Nov 2023 08:33:02 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781376262846752303 X-GMAIL-MSGID: 1781376262846752303 |
Series |
x86/lib: Fix overflow of variable m when val >= 1410065408
|
|
Commit Message
Colin Ian King
Nov. 1, 2023, 3:32 p.m. UTC
There is an overflow in variable m in function num_digits when val
is >= 1410065408 which leads to the digit calculation loop to
iterate more times than required. This results in either more
digits being counted or in some cases (for example where val is
1932683193) the value of m eventually overflows to zero and the
while loop spins forever).
Currently the function num_digits is currently only being used for
small values of val in the SMP boot stage for digit counting on the
number of cpus and NUMA nodes, so the overflow is never encounterd.
However it is useful to fix the overflow issue in case the function
is used for other purposes in the future. (The issue was discovered
while investigating the digit counting performance in various
kernel helper functions rather than any real-world use-case).
The simplest fix is to make m a long int, the overhead in
multiplication speed for a long is very minor for small values
of val less than 10000 on modern processors. The alternative
fix is to replace the multiplication with a constant division
by 10 loop (this compiles down to an multiplication and shift)
without needing to make m a long int, but this is slightly slower
than the fix in this commit when measured on a range of x86
processors).
Fixes: 646e29a1789a ("x86: Improve the printout of the SMP bootup CPU table")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
---
arch/x86/lib/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 11/1/23 08:32, Colin Ian King wrote: > There is an overflow in variable m in function num_digits when val > is >= 1410065408 which leads to the digit calculation loop to > iterate more times than required. This results in either more > digits being counted or in some cases (for example where val is > 1932683193) the value of m eventually overflows to zero and the > while loop spins forever). > > Currently the function num_digits is currently only being used for > small values of val in the SMP boot stage for digit counting on the > number of cpus and NUMA nodes, so the overflow is never encounterd. encountered. > However it is useful to fix the overflow issue in case the function > is used for other purposes in the future. (The issue was discovered > while investigating the digit counting performance in various > kernel helper functions rather than any real-world use-case). > > The simplest fix is to make m a long int, the overhead in > multiplication speed for a long is very minor for small values > of val less than 10000 on modern processors. The alternative > fix is to replace the multiplication with a constant division > by 10 loop (this compiles down to an multiplication and shift) > without needing to make m a long int, but this is slightly slower > than the fix in this commit when measured on a range of x86 > processors). > > Fixes: 646e29a1789a ("x86: Improve the printout of the SMP bootup CPU table") > Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> num_digits() now works for all int values. Thanks. > --- > arch/x86/lib/misc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/lib/misc.c b/arch/x86/lib/misc.c > index 92cd8ecc3a2c..41e26e246d8f 100644 > --- a/arch/x86/lib/misc.c > +++ b/arch/x86/lib/misc.c > @@ -8,7 +8,7 @@ > */ > int num_digits(int val) > { > - int m = 10; > + long m = 10; > int d = 1; > > if (val < 0) {
On 11/1/23 08:32, Colin Ian King wrote: ... > int num_digits(int val) > { > - int m = 10; > + long m = 10; > int d = 1; > > if (val < 0) { Isn't this still broken on 32-bit where sizeof(long) == sizeof(int)? Seems like we need 'm' to be able to hold values that are ~10x larger than 'val' if we need this to work for the entire int range. Also, performance doesn't matter here at *all* with the current use in a couple of printk()'s. Just making 'm' 'long long' or u64 probably be just fine.
On 02/11/2023 16:38, Dave Hansen wrote: > On 11/1/23 08:32, Colin Ian King wrote: > ... >> int num_digits(int val) >> { >> - int m = 10; >> + long m = 10; >> int d = 1; >> >> if (val < 0) { > > Isn't this still broken on 32-bit where sizeof(long) == sizeof(int)? > Seems like we need 'm' to be able to hold values that are ~10x larger > than 'val' if we need this to work for the entire int range. Good point, long long is required for 32 bit, sizes: arch int long long long i386 4 4 8 x86_64 4 8 8 I'll send a V2. > > Also, performance doesn't matter here at *all* with the current use in > a couple of printk()'s. Just making 'm' 'long long' or u64 probably be > just fine.
diff --git a/arch/x86/lib/misc.c b/arch/x86/lib/misc.c index 92cd8ecc3a2c..41e26e246d8f 100644 --- a/arch/x86/lib/misc.c +++ b/arch/x86/lib/misc.c @@ -8,7 +8,7 @@ */ int num_digits(int val) { - int m = 10; + long m = 10; int d = 1; if (val < 0) {