[PATCH] shmem: avoid maybe-uninitialized warning

[PATCH] shmem: avoid maybe-uninitialized warning

[Arnd Bergmann]

After enabling -Wmaybe-uninitialized warnings, we get a false-postive
warning for shmem:

mm/shmem.c: In function ‘shmem_getpage_gfp’:
include/linux/spinlock.h:332:21: error: ‘info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

This can be easily avoided, since the correct 'info' pointer is known
at the time we first enter the function, so we can simply move the
initialization up. Moving it before the first label avoids the
warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 mm/shmem.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index ad7813d73ea7..69e6777096a3 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1537,7 +1537,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
 	struct mm_struct *fault_mm, int *fault_type)
 {
 	struct address_space *mapping = inode->i_mapping;
-	struct shmem_inode_info *info;
+	struct shmem_inode_info *info = SHMEM_I(inode);
 	struct shmem_sb_info *sbinfo;
 	struct mm_struct *charge_mm;
 	struct mem_cgroup *memcg;
@@ -1587,7 +1587,6 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
 	 * Fast cache lookup did not find it:
 	 * bring it back from swap or allocate.
 	 */
-	info = SHMEM_I(inode);
 	sbinfo = SHMEM_SB(inode->i_sb);
 	charge_mm = fault_mm ? : current->mm;
 
-- 
2.9.0

Re: [PATCH] shmem: avoid maybe-uninitialized warning

[Michal Hocko]

On Mon 24-10-16 17:25:03, Arnd Bergmann wrote:
> After enabling -Wmaybe-uninitialized warnings, we get a false-postive
> warning for shmem:
> 
> mm/shmem.c: In function ‘shmem_getpage_gfp’:
> include/linux/spinlock.h:332:21: error: ‘info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

Is this really a false positive? If we goto clear and then 
        if (sgp <= SGP_CACHE &&
            ((loff_t)index << PAGE_SHIFT) >= i_size_read(inode)) {
                if (alloced) {

we could really take a spinlock on an unitialized variable. But maybe
there is something that prevents from that... Anyway the whole
shmem_getpage_gfp is really hard to follow due to gotos and labels
proliferation.

> This can be easily avoided, since the correct 'info' pointer is known
> at the time we first enter the function, so we can simply move the
> initialization up. Moving it before the first label avoids the
> warning.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Looks good to me.
Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  mm/shmem.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index ad7813d73ea7..69e6777096a3 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1537,7 +1537,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
>  	struct mm_struct *fault_mm, int *fault_type)
>  {
>  	struct address_space *mapping = inode->i_mapping;
> -	struct shmem_inode_info *info;
> +	struct shmem_inode_info *info = SHMEM_I(inode);
>  	struct shmem_sb_info *sbinfo;
>  	struct mm_struct *charge_mm;
>  	struct mem_cgroup *memcg;
> @@ -1587,7 +1587,6 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
>  	 * Fast cache lookup did not find it:
>  	 * bring it back from swap or allocate.
>  	 */
> -	info = SHMEM_I(inode);
>  	sbinfo = SHMEM_SB(inode->i_sb);
>  	charge_mm = fault_mm ? : current->mm;
>  
> -- 
> 2.9.0
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] shmem: avoid maybe-uninitialized warning

[Arnd Bergmann]

On Monday, October 24, 2016 6:22:44 PM CEST Michal Hocko wrote:
> On Mon 24-10-16 17:25:03, Arnd Bergmann wrote:
> > After enabling -Wmaybe-uninitialized warnings, we get a false-postive
> > warning for shmem:
> > 
> > mm/shmem.c: In function ‘shmem_getpage_gfp’:
> > include/linux/spinlock.h:332:21: error: ‘info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> Is this really a false positive? If we goto clear and then 
>         if (sgp <= SGP_CACHE &&
>             ((loff_t)index << PAGE_SHIFT) >= i_size_read(inode)) {
>                 if (alloced) {
> 
> we could really take a spinlock on an unitialized variable. But maybe
> there is something that prevents from that...

I did the patch a few weeks ago (I sent the more important
ones out first) and I think I concluded then that 'alloced'
would be false in that case.

> Anyway the whole shmem_getpage_gfp is really hard to follow due to gotos
> and labels proliferation.

Exactly. Maybe we should mark the patch for -stable backports after all
just to be sure.

Andreas also pointed out on IRC that there is another assignment
that can be removed in the function when the variable is initialized
upfront, so I'll resend anyway.

	Arnd

Re: [PATCH] shmem: avoid maybe-uninitialized warning

[Michal Hocko]

On Mon 24-10-16 21:42:36, Arnd Bergmann wrote:
> On Monday, October 24, 2016 6:22:44 PM CEST Michal Hocko wrote:
> > On Mon 24-10-16 17:25:03, Arnd Bergmann wrote:
> > > After enabling -Wmaybe-uninitialized warnings, we get a false-postive
> > > warning for shmem:
> > > 
> > > mm/shmem.c: In function ‘shmem_getpage_gfp’:
> > > include/linux/spinlock.h:332:21: error: ‘info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > 
> > Is this really a false positive? If we goto clear and then 
> >         if (sgp <= SGP_CACHE &&
> >             ((loff_t)index << PAGE_SHIFT) >= i_size_read(inode)) {
> >                 if (alloced) {
> > 
> > we could really take a spinlock on an unitialized variable. But maybe
> > there is something that prevents from that...
> 
> I did the patch a few weeks ago (I sent the more important
> ones out first) and I think I concluded then that 'alloced'
> would be false in that case.

OK, I guess you are right and alloced is set only after info has been
already initialized. So this really looks like a false positive.

> 
> > Anyway the whole shmem_getpage_gfp is really hard to follow due to gotos
> > and labels proliferation.
> 
> Exactly. Maybe we should mark the patch for -stable backports after all
> just to be sure.

I am not really sure a stable backport is really necessary but a cleanup
in this area would be more than welcome. At least from me ;)
-- 
Michal Hocko
SUSE Labs