[PATCH] ARM: NOMMU: work around maybe-uninitialized warning

[PATCH] ARM: NOMMU: work around maybe-uninitialized warning

[Arnd Bergmann]

The reworked MPU code produces a new warning in some configurations,
presumably starting with the code move after the compiler now makes
different inlining decisions:

arch/arm/mm/pmsa-v7.c: In function 'adjust_lowmem_bounds_mpu':
arch/arm/mm/pmsa-v7.c:310:5: error: 'specified_mem_size' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This appears to be harmless, as we know that there is always at
least one memblock, and the only way this could get triggered is
if the for_each_memblock() loop was never entered.

I could not come up with a better workaround than initializing
the specified_mem_size to zero, but at least that is the value
that the variable would have in the hypothetical case of no
memblocks.

Fixes: 877ec119dbbf ("ARM: 8706/1: NOMMU: Move out MPU setup in separate module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Vladimir, if this looks good to you, can you forward it to Russell's
patch tracker, or otherwise suggest a different fix?
---
 arch/arm/mm/pmsa-v7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/pmsa-v7.c b/arch/arm/mm/pmsa-v7.c
index 106ae1c435a3..976df60ac426 100644
--- a/arch/arm/mm/pmsa-v7.c
+++ b/arch/arm/mm/pmsa-v7.c
@@ -234,7 +234,7 @@ static int __init allocate_region(phys_addr_t base, phys_addr_t size,
 /* MPU initialisation functions */
 void __init adjust_lowmem_bounds_mpu(void)
 {
-	phys_addr_t  specified_mem_size, total_mem_size = 0;
+	phys_addr_t  specified_mem_size = 0, total_mem_size = 0;
 	struct memblock_region *reg;
 	bool first = true;
 	phys_addr_t mem_start;
-- 
2.9.0

[PATCH] ARM: NOMMU: work around maybe-uninitialized warning

[Vladimir Murzin]

On 02/11/17 09:21, Arnd Bergmann wrote:
> The reworked MPU code produces a new warning in some configurations,
> presumably starting with the code move after the compiler now makes
> different inlining decisions:
> 
> arch/arm/mm/pmsa-v7.c: In function 'adjust_lowmem_bounds_mpu':
> arch/arm/mm/pmsa-v7.c:310:5: error: 'specified_mem_size' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This appears to be harmless, as we know that there is always at
> least one memblock, and the only way this could get triggered is
> if the for_each_memblock() loop was never entered.
> 
> I could not come up with a better workaround than initializing
> the specified_mem_size to zero, but at least that is the value
> that the variable would have in the hypothetical case of no
> memblocks.
> 
> Fixes: 877ec119dbbf ("ARM: 8706/1: NOMMU: Move out MPU setup in separate module")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Vladimir, if this looks good to you, can you forward it to Russell's
> patch tracker, or otherwise suggest a different fix?

Accepted as patch 8719/1. Not sure if Russell will pick it up or not... anyway,
thanks for the patch!

Vladimir

> ---
>  arch/arm/mm/pmsa-v7.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mm/pmsa-v7.c b/arch/arm/mm/pmsa-v7.c
> index 106ae1c435a3..976df60ac426 100644
> --- a/arch/arm/mm/pmsa-v7.c
> +++ b/arch/arm/mm/pmsa-v7.c
> @@ -234,7 +234,7 @@ static int __init allocate_region(phys_addr_t base, phys_addr_t size,
>  /* MPU initialisation functions */
>  void __init adjust_lowmem_bounds_mpu(void)
>  {
> -	phys_addr_t  specified_mem_size, total_mem_size = 0;
> +	phys_addr_t  specified_mem_size = 0, total_mem_size = 0;
>  	struct memblock_region *reg;
>  	bool first = true;
>  	phys_addr_t mem_start;
> 

[PATCH] ARM: NOMMU: work around maybe-uninitialized warning

[Russell King - ARM Linux]

On Thu, Nov 02, 2017 at 12:25:47PM +0000, Vladimir Murzin wrote:
> On 02/11/17 09:21, Arnd Bergmann wrote:
> > The reworked MPU code produces a new warning in some configurations,
> > presumably starting with the code move after the compiler now makes
> > different inlining decisions:
> > 
> > arch/arm/mm/pmsa-v7.c: In function 'adjust_lowmem_bounds_mpu':
> > arch/arm/mm/pmsa-v7.c:310:5: error: 'specified_mem_size' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > 
> > This appears to be harmless, as we know that there is always at
> > least one memblock, and the only way this could get triggered is
> > if the for_each_memblock() loop was never entered.
> > 
> > I could not come up with a better workaround than initializing
> > the specified_mem_size to zero, but at least that is the value
> > that the variable would have in the hypothetical case of no
> > memblocks.
> > 
> > Fixes: 877ec119dbbf ("ARM: 8706/1: NOMMU: Move out MPU setup in separate module")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > Vladimir, if this looks good to you, can you forward it to Russell's
> > patch tracker, or otherwise suggest a different fix?
> 
> Accepted as patch 8719/1. Not sure if Russell will pick it up or not... anyway,
> thanks for the patch!

I'd prefer not to at this stage.  Same things that apply that I said
in the "ARM: early_printk: use printascii() rather than printch()"
thread - I need to ensure that what I have is stable before 4.14 is
released, so I'm not accepting anything further unless it is _really_
urgent.

This isn't urgent.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH] ARM: NOMMU: work around maybe-uninitialized warning

[Vladimir Murzin]

On 02/11/17 13:07, Russell King - ARM Linux wrote:
> On Thu, Nov 02, 2017 at 12:25:47PM +0000, Vladimir Murzin wrote:
>> On 02/11/17 09:21, Arnd Bergmann wrote:
>>> The reworked MPU code produces a new warning in some configurations,
>>> presumably starting with the code move after the compiler now makes
>>> different inlining decisions:
>>>
>>> arch/arm/mm/pmsa-v7.c: In function 'adjust_lowmem_bounds_mpu':
>>> arch/arm/mm/pmsa-v7.c:310:5: error: 'specified_mem_size' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>>
>>> This appears to be harmless, as we know that there is always at
>>> least one memblock, and the only way this could get triggered is
>>> if the for_each_memblock() loop was never entered.
>>>
>>> I could not come up with a better workaround than initializing
>>> the specified_mem_size to zero, but at least that is the value
>>> that the variable would have in the hypothetical case of no
>>> memblocks.
>>>
>>> Fixes: 877ec119dbbf ("ARM: 8706/1: NOMMU: Move out MPU setup in separate module")
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> Vladimir, if this looks good to you, can you forward it to Russell's
>>> patch tracker, or otherwise suggest a different fix?
>>
>> Accepted as patch 8719/1. Not sure if Russell will pick it up or not... anyway,
>> thanks for the patch!
> 
> I'd prefer not to at this stage.  Same things that apply that I said
> in the "ARM: early_printk: use printascii() rather than printch()"
> thread - I need to ensure that what I have is stable before 4.14 is
> released, so I'm not accepting anything further unless it is _really_
> urgent.

Yes, I saw that thread, it is why that "not sure" thing.

> 
> This isn't urgent.
> 

Should I resubmit after -rc1 or you'll apply it directly from patch tracker?

Thanks
Vladimir

[PATCH] ARM: NOMMU: work around maybe-uninitialized warning

[Russell King - ARM Linux]

On Thu, Nov 02, 2017 at 01:11:23PM +0000, Vladimir Murzin wrote:
> On 02/11/17 13:07, Russell King - ARM Linux wrote:
> > I'd prefer not to at this stage.  Same things that apply that I said
> > in the "ARM: early_printk: use printascii() rather than printch()"
> > thread - I need to ensure that what I have is stable before 4.14 is
> > released, so I'm not accepting anything further unless it is _really_
> > urgent.
> 
> Yes, I saw that thread, it is why that "not sure" thing.
> 
> > 
> > This isn't urgent.
> > 
> 
> Should I resubmit after -rc1 or you'll apply it directly from patch tracker?

If you put it in the patch tracker now, I'll apply it when appropriate.

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up