Received: by 10.223.185.116 with SMTP id b49csp3877196wrg; Tue, 13 Feb 2018 09:04:40 -0800 (PST) X-Google-Smtp-Source: AH8x224eK/5+WfldW2QJPxyVRfOrzBQzXyBuLLSsdNSrxw9YuBSd/6vwYIZFobONUQ6t1oXHEcXm X-Received: by 10.99.44.22 with SMTP id s22mr346335pgs.111.1518541480595; Tue, 13 Feb 2018 09:04:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518541480; cv=none; d=google.com; s=arc-20160816; b=neniBVMWLhypYo2pGbALsacKg9gYwkzhnjHn7i3xNxD4IVRMxzB+bMdb8x1f88lYrl oKGiOfmQJIMATA7egGqLvk3+uNYouNRwDBvymBoK0F9PyGCxTpWF4X/8w9RTvo09Z7qU MZoUcxKj76f7YhPpw6gpBDfh16bsvcycqanKIWF/kbKT2zzxGKFrODwCMCvKvx7iVoJQ uDoSHarqfHMDRntD0XxmvjBXlO3y2ergFeio6ktmXdhFpSCwQGBBjkOwJhXMkVMGhkXS qfiZ6pFkjrTBtxmMdZb2a02bspYANbl0gfbHMae8dOmDkp2TksgV1OxnJBASc6e8k8zS +apQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=1wg7B3G/SYUHYwdxxAcRaTWRQHPMFwei757drMdqsSs=; b=EpKHrdY7B1+4V3TaHwwlaArCj5XuVPKngbjJWYott22ctZZKOV/IWU1cbakoghhtED U35TtjundV7BximQpFQ6EZNjOB5xZQkNPFgpjAfSkDvMrWHM8Dvj7ZMV5zb3OCchovbN 6z2IygA6v8S958Nqq72RcZGl8c6MDZJEaGdcolIJ7EkCBIpMgKzRlxTN14zTl1t5BxMu 2IcR6P8Vt1rd6Ob8FISV6XjYBL3yDy8P2WVdOzWAw1CX6Ya8cdrz6cg4tBAn75Z399/P f0UoWHwtGAVwdIhOT2IAnikqGT+TGGrNV3fVS6WFUClabMT4Qu+KFg7sNLWlj4jR4I48 bjGw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t64si1529352pgd.435.2018.02.13.09.04.05; Tue, 13 Feb 2018 09:04:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965562AbeBMRCm (ORCPT + 99 others); Tue, 13 Feb 2018 12:02:42 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:51114 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965057AbeBMRCl (ORCPT ); Tue, 13 Feb 2018 12:02:41 -0500 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eldvD-0005kw-3H; Tue, 13 Feb 2018 17:59:11 +0100 Date: Tue, 13 Feb 2018 18:02:31 +0100 (CET) From: Thomas Gleixner To: "Gustavo A. R. Silva" cc: Borislav Petkov , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/microcode/intel: Use 64-bit arithmetic instead of 32-bit In-Reply-To: <20180213164404.GA11664@embeddedor.com> Message-ID: References: <20180213164404.GA11664@embeddedor.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Feb 2018, Gustavo A. R. Silva wrote: > Add suffix ULL to constant 1024 in order to give the compiler complete > information about the proper arithmetic to use. Notice that this > constant is used in a context that expects an expression of type > u64 (64 bits, unsigned). > > The expression c->x86_cache_size * 1024 is currently being evaluated > using 32-bit arithmetic. > > Addresses-Coverity-ID: 1464429 > Signed-off-by: Gustavo A. R. Silva > --- > arch/x86/kernel/cpu/microcode/intel.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c > index f7c55b0..e5edb92 100644 > --- a/arch/x86/kernel/cpu/microcode/intel.c > +++ b/arch/x86/kernel/cpu/microcode/intel.c > @@ -982,7 +982,7 @@ static struct microcode_ops microcode_intel_ops = { > > static int __init calc_llc_size_per_core(struct cpuinfo_x86 *c) > { > - u64 llc_size = c->x86_cache_size * 1024; > + u64 llc_size = c->x86_cache_size * 1024ULL; x86_cache_size is 'int', so you really want to cast c->x86_cache_size to (u64) for correctness sake. Aside of that the patch is really purely cosmetic at the moment because the largest LLC sizes are still below the 3 digit MB range which fits into 32bit quite well. You'd need to have a CPU with >= 2G LLC to create a problem. But looking at c->x86_cache_size again. It's int because it's set to -1 initially which is then changed if CPUid or general CPU info gives real information about the cache size. The only place where that matters is the /proc/cpuinfo output: if (c->x86_cache_size >= 0) seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size); which is silly, because that really can be done with: if (c->x86_cache_size) as there is no point in printing 'cache size 0KB', which means x86_cache_size can be made unsigned int, which makes sense because cache size < 0 does not at all. So instead of doing this purely mechanical cosmetic change to make a static checker shut up, I'd like to see a proper cleanup of that thing. Thanks, tglx