Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
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
>
> ping, please?
>
> sparse build is still noisy like hell :/
/me goes to dig it out in the pile
Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
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
Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
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
x86 folks, any objections to merging this? Without it, the sparse build is
currently totally unreadable mess.
Thanks,
--
Jiri Kosina
SUSE Labs
Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
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
Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
On Mon, Apr 16, 2018 at 09:43:02AM +, 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
Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
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
Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs
On Thu, Apr 12, 2018 at 02:39:10PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina
>
> 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
