Received: by 10.192.165.148 with SMTP id m20csp2009628imm; Thu, 26 Apr 2018 05:17:41 -0700 (PDT) X-Google-Smtp-Source: AIpwx48vKgoMnrubTN8Q4D8HnDpzqqxDhPQdq+vMIKGucT17w5qs5eInMqors+JazRDyLyJKUcxw X-Received: by 2002:a17:902:5801:: with SMTP id m1-v6mr34123451pli.325.1524745061196; Thu, 26 Apr 2018 05:17:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524745061; cv=none; d=google.com; s=arc-20160816; b=b+4UlJdVMnWqsNjbtbkJ7GOV6oV471TBny+UL/MVU7rCm2qoRhEldRWsyHZKBdqWLE gk3gnTcmCAMVvgUkYGcZUE7iGA/DQyzzFiH7uNMxzdokBi0H90EtNPDLpOID91E0yyNI ZBjBP94j5eQYE1dE+WlklIIPDe8Gmjp0UwLXUI7i5EI7EAQW+hMilYKNWer2OI8FgU+g nI5OSnfGPZlPKtLBtxpG87CAq7pkZgmQD0H3ZBuzVjazZURqbgrRD4+ws2YdfsXaE31W 8kr11Pt9kaqs9NzYiF9TSCIQe/D+yBUytFaO76LSwM1W4CMF3oSUpuoKrB0/G50fjPU8 /23A== 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=VBD4ty8Zh9UHl/XIA7ps3JKs5hP5JB5aUp3ro+vLEQM=; b=fsDyHZRQ/H+MYrAxEN9HmkOSGb0F2Mq6v8EA2jOKhOKu3juHAs8KpTJiXVR1yXXKRz vBJjHI63JbJO1j/56sV9T6/W9mLIccdpqhm1VUSUpRzhkFwdxDIOik/vmWRKEpuKsoAV ctvPWb/PTcXO7v4gxJ5DDiIXT5caJ/0MJzeqGllnXc/26gytiLMwL36ufyEpDz6fCshD GbnoiEtuwMwLq8ZFI2sXIsuSLdmMcirQDMtTnk5iOmRDB3H5dbZ3v1ZlykiXa1syHknc r/BsCVt2gNX1HCJk5giXcfSTnDCLHJksvMR9rM2KOvUxvW1ZZQVfHylhsFy2ikRyrrHu N2gQ== 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 65-v6si18711251plb.301.2018.04.26.05.17.27; Thu, 26 Apr 2018 05:17:41 -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 S1755880AbeDZMQR (ORCPT + 99 others); Thu, 26 Apr 2018 08:16:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:60104 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755821AbeDZMQN (ORCPT ); Thu, 26 Apr 2018 08:16:13 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 045F7AE3E; Thu, 26 Apr 2018 12:16:12 +0000 (UTC) Date: Thu, 26 Apr 2018 14:16:10 +0200 (CEST) From: Jiri Kosina To: "Kirill A. Shutemov" 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 In-Reply-To: <20180416094603.fj3wevho5j7wy7s6@black.fi.intel.com> Message-ID: References: <20180412142801.oi7bzju3frgkdskp@node.shutemov.name> <20180416094603.fj3wevho5j7wy7s6@black.fi.intel.com> User-Agent: Alpine 2.21 (LSU 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 Mon, 16 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 ping, please? sparse build is still noisy like hell :/ Thanks, -- Jiri Kosina SUSE Labs