LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
@ 2018-04-12 12:39 Jiri Kosina
  2018-04-12 14:28 ` Kirill A. Shutemov
  2018-04-26 13:00 ` [tip:x86/urgent] x86/mm: Make vmemmap and vmalloc base address constants unsigned long tip-bot for Jiri Kosina
  0 siblings, 2 replies; 9+ messages in thread
From: Jiri Kosina @ 2018-04-12 12:39 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Kirill A. Shutemov; +Cc: linux-kernel, x86

From: Jiri Kosina <jkosina@suse.cz>

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.

Fixes: 9b46a051e4 ("x86/mm: Initialize vmemmap_base at boot-time")
Fixes: a7412546d8 ("x86/mm: Adjust vmalloc base and size at boot-time")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 arch/x86/include/asm/pgtable_64_types.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index d5c21a3..adb4755 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -105,14 +105,14 @@
 #define LDT_PGD_ENTRY		(pgtable_l5_enabled ? LDT_PGD_ENTRY_L5 : LDT_PGD_ENTRY_L4)
 #define LDT_BASE_ADDR		(LDT_PGD_ENTRY << PGDIR_SHIFT)
 
-#define __VMALLOC_BASE_L4	0xffffc90000000000
-#define __VMALLOC_BASE_L5 	0xffa0000000000000
+#define __VMALLOC_BASE_L4	0xffffc90000000000UL
+#define __VMALLOC_BASE_L5 	0xffa0000000000000UL
 
 #define VMALLOC_SIZE_TB_L4	32UL
 #define VMALLOC_SIZE_TB_L5	12800UL
 
-#define __VMEMMAP_BASE_L4	0xffffea0000000000
-#define __VMEMMAP_BASE_L5	0xffd4000000000000
+#define __VMEMMAP_BASE_L4	0xffffea0000000000UL
+#define __VMEMMAP_BASE_L5	0xffd4000000000000UL
 
 #ifdef CONFIG_DYNAMIC_MEMORY_LAYOUT
 # define VMALLOC_START		vmalloc_base

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
  2018-04-12 12:39 [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs Jiri Kosina
@ 2018-04-12 14:28 ` Kirill A. Shutemov
  2018-04-16  9:43   ` Jiri Kosina
  2018-04-26 13:00 ` [tip:x86/urgent] x86/mm: Make vmemmap and vmalloc base address constants unsigned long tip-bot for Jiri Kosina
  1 sibling, 1 reply; 9+ messages in thread
From: Kirill A. Shutemov @ 2018-04-12 14:28 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Thomas Gleixner, Ingo Molnar, Kirill A. Shutemov, linux-kernel, x86

On Thu, Apr 12, 2018 at 02:39:10PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina <jkosina@suse.cz>
> 
> 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.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
  2018-04-12 14:28 ` Kirill A. Shutemov
@ 2018-04-16  9:43   ` Jiri Kosina
  2018-04-16  9:46     ` Kirill A. Shutemov
  2018-04-16 11:57     ` Luc Van Oostenryck
  0 siblings, 2 replies; 9+ messages in thread
From: Jiri Kosina @ 2018-04-16  9:43 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Thomas Gleixner, Ingo Molnar, Kirill A. Shutemov, linux-kernel, x86

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.

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
  2018-04-16  9:43   ` Jiri Kosina
@ 2018-04-16  9:46     ` Kirill A. Shutemov
  2018-04-19  6:35       ` Jiri Kosina
  2018-04-26 12:16       ` Jiri Kosina
  2018-04-16 11:57     ` Luc Van Oostenryck
  1 sibling, 2 replies; 9+ messages in thread
From: Kirill A. Shutemov @ 2018-04-16  9:46 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Kirill A. Shutemov, Thomas Gleixner, Ingo Molnar, linux-kernel, x86

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.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
  2018-04-16  9:43   ` Jiri Kosina
  2018-04-16  9:46     ` Kirill A. Shutemov
@ 2018-04-16 11:57     ` Luc Van Oostenryck
  1 sibling, 0 replies; 9+ messages in thread
From: Luc Van Oostenryck @ 2018-04-16 11:57 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Kirill A. Shutemov, Thomas Gleixner, Ingo Molnar,
	Kirill A. Shutemov, linux-kernel, x86

On Mon, Apr 16, 2018 at 11:43:02AM +0200, 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.

Hi,

If you're talking about sparse's 'constant ... is so big it is ...',
there is nothing to teach sparse about as it knows perfectly the
(correct) type of the constant (which is printed at the end).
The warning is there on purpose.

Cheers,
-- Luc Van Oostenryck

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
  2018-04-16  9:46     ` Kirill A. Shutemov
@ 2018-04-19  6:35       ` Jiri Kosina
  2018-04-26 12:16       ` Jiri Kosina
  1 sibling, 0 replies; 9+ messages in thread
From: Jiri Kosina @ 2018-04-19  6:35 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Kirill A. Shutemov, Thomas Gleixner, Ingo Molnar, linux-kernel, x86

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 <kirill.shutemov@linux.intel.com>

x86 folks, any objections to merging this? Without it, the sparse build is 
currently totally unreadable mess.

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
  2018-04-16  9:46     ` Kirill A. Shutemov
  2018-04-19  6:35       ` Jiri Kosina
@ 2018-04-26 12:16       ` Jiri Kosina
  2018-04-26 12:50         ` Thomas Gleixner
  1 sibling, 1 reply; 9+ messages in thread
From: Jiri Kosina @ 2018-04-26 12:16 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Kirill A. Shutemov, Thomas Gleixner, Ingo Molnar, linux-kernel, x86

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 <kirill.shutemov@linux.intel.com>

ping, please?

sparse build is still noisy like hell :/

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
  2018-04-26 12:16       ` Jiri Kosina
@ 2018-04-26 12:50         ` Thomas Gleixner
  0 siblings, 0 replies; 9+ messages in thread
From: Thomas Gleixner @ 2018-04-26 12:50 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Kirill A. Shutemov, Kirill A. Shutemov, Ingo Molnar, linux-kernel, x86

On Thu, 26 Apr 2018, Jiri Kosina wrote:
> 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 <kirill.shutemov@linux.intel.com>
> 
> ping, please?
> 
> sparse build is still noisy like hell :/

/me goes to dig it out in the pile ....

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [tip:x86/urgent] x86/mm: Make vmemmap and vmalloc base address constants unsigned long
  2018-04-12 12:39 [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs Jiri Kosina
  2018-04-12 14:28 ` Kirill A. Shutemov
@ 2018-04-26 13:00 ` tip-bot for Jiri Kosina
  1 sibling, 0 replies; 9+ messages in thread
From: tip-bot for Jiri Kosina @ 2018-04-26 13:00 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: mingo, jkosina, tglx, linux-kernel, kirill.shutemov, hpa

Commit-ID:  14d12bb8582e158006c35cce0f8ae1706094f9a4
Gitweb:     https://git.kernel.org/tip/14d12bb8582e158006c35cce0f8ae1706094f9a4
Author:     Jiri Kosina <jkosina@suse.cz>
AuthorDate: Thu, 12 Apr 2018 14:39:10 +0200
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Thu, 26 Apr 2018 14:56:24 +0200

x86/mm: Make vmemmap and vmalloc base address constants unsigned long

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.

Declare them explicitly unsigned long again.

Fixes: 9b46a051e4 ("x86/mm: Initialize vmemmap_base at boot-time")
Fixes: a7412546d8 ("x86/mm: Adjust vmalloc base and size at boot-time")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.1804121437350.28129@cbobk.fhfr.pm

---
 arch/x86/include/asm/pgtable_64_types.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index d5c21a382475..adb47552e6bb 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -105,14 +105,14 @@ extern unsigned int ptrs_per_p4d;
 #define LDT_PGD_ENTRY		(pgtable_l5_enabled ? LDT_PGD_ENTRY_L5 : LDT_PGD_ENTRY_L4)
 #define LDT_BASE_ADDR		(LDT_PGD_ENTRY << PGDIR_SHIFT)
 
-#define __VMALLOC_BASE_L4	0xffffc90000000000
-#define __VMALLOC_BASE_L5 	0xffa0000000000000
+#define __VMALLOC_BASE_L4	0xffffc90000000000UL
+#define __VMALLOC_BASE_L5 	0xffa0000000000000UL
 
 #define VMALLOC_SIZE_TB_L4	32UL
 #define VMALLOC_SIZE_TB_L5	12800UL
 
-#define __VMEMMAP_BASE_L4	0xffffea0000000000
-#define __VMEMMAP_BASE_L5	0xffd4000000000000
+#define __VMEMMAP_BASE_L4	0xffffea0000000000UL
+#define __VMEMMAP_BASE_L5	0xffd4000000000000UL
 
 #ifdef CONFIG_DYNAMIC_MEMORY_LAYOUT
 # define VMALLOC_START		vmalloc_base

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2018-04-26 13:00 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-12 12:39 [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs Jiri Kosina
2018-04-12 14:28 ` Kirill A. Shutemov
2018-04-16  9:43   ` Jiri Kosina
2018-04-16  9:46     ` Kirill A. Shutemov
2018-04-19  6:35       ` Jiri Kosina
2018-04-26 12:16       ` Jiri Kosina
2018-04-26 12:50         ` Thomas Gleixner
2018-04-16 11:57     ` Luc Van Oostenryck
2018-04-26 13:00 ` [tip:x86/urgent] x86/mm: Make vmemmap and vmalloc base address constants unsigned long tip-bot for Jiri Kosina

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).