From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S941274AbcJXTnA convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Mon, 24 Oct 2016 15:43:00 -0400
Received: from mout.kundenserver.de ([212.227.126.133]:61090 "EHLO
        mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S941104AbcJXTm4 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 24 Oct 2016 15:42:56 -0400
From: Arnd Bergmann <arnd@arndb.de>
To: Michal Hocko <mhocko@kernel.org>
Cc: Hugh Dickins <hughd@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Andreas Gruenbacher <agruenba@redhat.com>,
        Vlastimil Babka <vbabka@suse.cz>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] shmem: avoid maybe-uninitialized warning
Date: Mon, 24 Oct 2016 21:42:36 +0200
Message-ID: <4142781.4gMiS9Brv9@wuerfel>
User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; )
In-Reply-To: <20161024162243.GA13148@dhcp22.suse.cz>
References: <20161024152511.2597880-1-arnd@arndb.de> <20161024162243.GA13148@dhcp22.suse.cz>
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Content-Type: text/plain; charset="UTF-8"
X-Provags-ID: V03:K0:bxPy3ftspwK+lqKkAl0Gn9818N78Epm0FTpMIPOpjlj42c7CQRv
 wOGgI8/0L0I5vUrQV4w6DtotUC47XD8ozhgbWMrMoCc7FtPRUmDmIxRknyWjIEkFZCWkl2/
 wurFUx3qDwBci6wC1vT50Q+xVuzV6c0tJV0OUuB7msQVcFJFYUbBvr9YXsG9IaFHHn5h9Z5
 ssC7Veque0H9xJMae9+pA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:E4O9ngZrGQo=:hqR7Fhc8WMRYq7SMzY5m0Z
 7kBAo1oEua9DKiuN+cYDqtfwmlkbBZ4EWs79XMX9PG0pSiiAOwo/dVSO+tF2z8o+1O2FiQN2u
 eAWIPtV43J7Brrk2MfXspHNlDGdbZPebvsjSdEHhRQidPCdnCwb7zcVAI+jau2fQoNSukJbo9
 +cuulRh7kNOd9bDJUpeKZaoGl/l5cMbeNaLb+5CFa33veIbkb4MGjXLSLG9xX3mTcpZqLkDJN
 +N5iCv8KGqYWA8sMo/nNZrYyj683BWWb8IWYv7R9cZgzf43Cv1UjCsQ1KFfm6D7dMhXouOkR3
 EGfIj7YBv24+Ai9HaNl2pBED7Vjx4GxymoUv+3wjr9fEu3L6StWGa3Y/jsEytp9KHNptRShrz
 63zPIgMGLIPRv5WtRJ6Z7yUGb44dzd6bYTCu6K+w7KYrkwo8/+FORTs7oPechqX9wNfPki87q
 4/29QbciKe/CyByeoP25dAlTZCG/MpVw6EZDC9TUeAAfXcbN4XIBoAr5y1AMznjruFeQLegLM
 KOmyEG/gQzmUIzlmFGrxA/APXdzkXMLr/BeJBeNBLeVdDu8KuLDF9q33KzVVfAQruuBL1Ne8+
 JHpEKd3WjxdWRfSI2iYiaSmqiqW9T+Lpgo6RGrSYc+TFLZxhk17XWztHFw0sNPFvNEsyv2/dV
 eAZ8vv+LjcRqV8PbY9iLSB380DaC8V4vYwPcrLabu5zetHSxl2xYvW9drqlYODpr9qfvYpGEF
 KmcRPZWaMtXo9k6/
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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