From patchwork Tue Oct 9 13:07:19 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 1570011 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork1.kernel.org (Postfix) with ESMTP id 38B063FE80 for ; Tue, 9 Oct 2012 13:09:21 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TLZXF-0004LL-VO; Tue, 09 Oct 2012 13:07:46 +0000 Received: from moutng.kundenserver.de ([212.227.126.186]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1TLZXB-0004K3-O3 for linux-arm-kernel@lists.infradead.org; Tue, 09 Oct 2012 13:07:42 +0000 Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com [195.212.29.180]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0LeM29-1Tj4r92Oh3-00qmGD; Tue, 09 Oct 2012 15:07:23 +0200 From: Arnd Bergmann To: Jan Kara Subject: Re: [PATCH 05/16] vfs: bogus warnings in fs/namei.c Date: Tue, 9 Oct 2012 13:07:19 +0000 User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; ) References: <1349448930-23976-1-git-send-email-arnd@arndb.de> <20121008115116.GA9243@quack.suse.cz> <201210091227.46324.arnd@arndb.de> In-Reply-To: <201210091227.46324.arnd@arndb.de> MIME-Version: 1.0 Message-Id: <201210091307.19225.arnd@arndb.de> X-Provags-ID: V02:K0:0vrz4LyCeChq4+BJnm0QCtriXJfw++qGzFq2K57+L2M 5HTT1NRDmXi8PlvgQ0QsbJmaVvOz3iW3pVz9PBfuQNzPEaoSIl mUPhHO+txa3HHrGI5gnYrOFCNSbkeAtw0ihmKx8AGzaUlQ/FRG Nrh9OWEvYqHJ77pv+Tk8EQdAY63M/0oYYkzHaMT1P7U+I1rbIX B/DZNHLCDFplowEYWS9K+1+gvUR4DlijJYCl/H3O5KEphcZm3C P0e5EbXmq0NHEosbU+f/p55Prfs56m/O9Rtn6+5VQ02Hbv8Rr9 3BfGWOoQV66AD3OUW+IpL9Ut2MPsFuGhIwoMeVKCRKvegmZmzm SZymz+uVa/7Itc40AWdE= X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.126.186 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: linux-fsdevel@vger.kernel.org, arm@kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Al Viro X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Tuesday 09 October 2012, Arnd Bergmann wrote: > On Monday 08 October 2012, Jan Kara wrote: > > On Fri 05-10-12 16:55:19, Arnd Bergmann wrote: > > > The follow_link() function always initializes its *p argument, > > > or returns an error, but not all versions of gcc figure this > > > out, so we have to work around this using the uninitialized_var() > > > macro. > > Well, I'm somewhat sceptical to this approach. I agree that bogus > > warnings are not nice but later when the code is changed and possibly real > > use without initialization is added, we won't notice it. Without changing > > anything, we'd at least have a chance of catching it with gcc versions > > which were clever enough to not warn with the original code. Or > > alternatively if we unconditionally initialized the variable that would get > > rid of the warning and made the code more future-proof (that's what I > > usually end up doing)... I don't really care that much about the chosen > > solution, Al is the one to decide. But I wanted to point out there are > > downsides to your solution. > > I'll drop the patch for now and won't send it from my tree then. I agree > that uninitialized_var() is not ideal, but none of the alternatives seemed > better. > > With my latest compiler, I don't actually see the warnings any more, so > maybe someone fixed gcc instead, or this went away after another change. > I'll let you know if it comes back so we can discuss about a better fix then. > Update: I could actually reproduce the problem now, but it only happens when building with 'gcc -s' (i.e. CONFIG_CC_OPTIMIZE_FOR_SIZE). It does happen with both gcc-4.6 and with gcc-4.8, and on both x86-64 and ARM. An alternative patch that would also make it go away is the variant below, but I think that's even worse than the first version I suggested because it makes the binary output slightly worse by adding an unnecessary initialization when building with 'make -s'. Arnd diff --git a/fs/namei.c b/fs/namei.c index aa30d19..c3612a5 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -810,6 +810,7 @@ follow_link(struct path *link, struct nameidata *nd, void **p) return error; out_put_nd_path: + *p = NULL; path_put(&nd->path); path_put(link); return error;