Received: by 10.192.165.156 with SMTP id m28csp504890imm; Mon, 16 Apr 2018 04:14:24 -0700 (PDT) X-Google-Smtp-Source: AIpwx49xnUGVeCcBHrHRyl2uyspC8ym24ywGja6p9olag10RX43x2gAZgZAbdvS34od6Ob1z2WEz X-Received: by 10.101.66.70 with SMTP id d6mr12447184pgq.234.1523877264214; Mon, 16 Apr 2018 04:14:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523877264; cv=none; d=google.com; s=arc-20160816; b=x86dshqeeqF2vE+/Ai4QQRyAmLtlAP0F4vvNLvTbJfaN6HkLbt8WexemP22nOQlZ0t ipqWniAHKwF+AClUFnAIWsVbcNtWvx4ybiBwJS2f7sE/GJzbqx9y9Y+3HKx06T6WRGLm bIa/dc8hd26/gDfVT1JpRMROO0MHI4EG+QglLr92Rj3kDKTFHn/5FX60Bh5N4b3GoCGv 6AJHKyozBT8XHfhmLz+RLNVBJR9+XAYjmC98YmKLQg4sglZ0tTugt5ffv9vme/FapDuy MFLw7XMUWl2mKv9nprbdddkdwZKRguLxkxviZgh+zgqNsI1qfhgDA+OSbwf7vrLc/iBl AQDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=UjcDFsOqIzzXfXFFwscs9wacBOLvlYuVWnSNbG5yHdI=; b=khv4vyFZXognA25N/efw4tPRp63lkTmlvBBVD+pys8iRWq7CcdyH4RBAewlFsV4yC/ G/JX2psroBJf3iQUC9Z7KILSkZiuwsvOqChKxcX7z828C03MuJMOmMFmgUb/2lD45/Yv rfgS9w9SnLGmQornQ9zUPjFai1lqt8X8ILuX9Ws+gtzCMx9h1GCmSlSsbh5yrG1yX4C3 2Er8lFCvNmLddTa29M/zr61i6mj3tkz/RVDcdUY/sRUQi/M4Qcte06LM7FPtWIiozYty 3HUwkIZlkJoi2VyCZOgmUFMaptfN9wYiH23hOQeN/JPeQ1jeJxNlZbwmzRA1Ffy6MtXU XJlg== 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 s6-v6si1271286plp.18.2018.04.16.04.14.10; Mon, 16 Apr 2018 04:14:24 -0700 (PDT) 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 S1754827AbeDPJqK (ORCPT + 99 others); Mon, 16 Apr 2018 05:46:10 -0400 Received: from mga03.intel.com ([134.134.136.65]:24654 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754042AbeDPJqI (ORCPT ); Mon, 16 Apr 2018 05:46:08 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2018 02:46:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,459,1517904000"; d="scan'208";a="43642434" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga003.jf.intel.com with ESMTP; 16 Apr 2018 02:46:05 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 19986264; Mon, 16 Apr 2018 12:46:03 +0300 (EEST) Date: Mon, 16 Apr 2018 12:46:03 +0300 From: "Kirill A. Shutemov" To: Jiri Kosina Cc: "Kirill A. Shutemov" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs Message-ID: <20180416094603.fj3wevho5j7wy7s6@black.fi.intel.com> References: <20180412142801.oi7bzju3frgkdskp@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714-126-deb55f (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 16, 2018 at 09:43:02AM +0000, Jiri Kosina wrote: > On Thu, 12 Apr 2018, Kirill A. Shutemov wrote: > > > > Commits 9b46a051e4 ("x86/mm: Initialize vmemmap_base at boot-time") and > > > a7412546d8 ("x86/mm: Adjust vmalloc base and size at boot-time") lost the > > > type information for __VMALLOC_BASE_L4, __VMALLOC_BASE_L5, > > > __VMEMMAP_BASE_L4 and __VMEMMAP_BASE_L5 constants. > > > > > > Let's declare them explicitly unsigned long again. > > > > It is just cosmetics, right? I mean these literals are 'unsigned long' > > anyway. > > Yeah, I can't imagine this particular case leading to any overflow > scenario, as the literal is big enough to be automatically treated as > unsigned long by the compiler, but it shuts up sparse which treats this as > a generic case (where the missing UL might be a problem), and totally > pollutes the build output. > > Either we put the 'UL' there, or teach sparse about figuring out the > 'closer bigger fitting type' for hexadecimal literals, which might be more > tricky. I don't have a problem with the patch: Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov