From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: linux-nfs-owner@vger.kernel.org Received: from mx2.netapp.com ([216.240.18.37]:48383 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751219Ab1KAC47 convert rfc822-to-8bit (ORCPT ); Mon, 31 Oct 2011 22:56:59 -0400 Subject: Re: [PATCH] Silence compiler warning From: Trond Myklebust To: Jim Rees Cc: linux-nfs@vger.kernel.org Date: Mon, 31 Oct 2011 22:56:57 -0400 In-Reply-To: <20111101024200.GA4382@umich.edu> References: <20111101013720.GA4237@umich.edu> <1320114622.10028.36.camel@lade.trondhjem.org> <20111101024200.GA4382@umich.edu> Content-Type: text/plain; charset="UTF-8" Message-ID: <1320116217.10028.44.camel@lade.trondhjem.org> Mime-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Mon, 2011-10-31 at 22:42 -0400, Jim Rees wrote: > Trond Myklebust wrote: > > On Mon, 2011-10-31 at 21:37 -0400, Jim Rees wrote: > > I think this is still needed, isn't it? I haven't tried compiling > > nfs-for-next but I don't see a fix for it in there. > > AFAICS, this is a bogus warning: if lo is uninitialised, we will > automatically exit with a return value of NFS4ERR_NOMATCHING_LAYOUT. > > Yes, the warning is bogus. I just want the damn compiler to shut up so I > can see if there are any real warnings. How about cleaning up the whole unnecessary "bool found" crap that has it confused? You can easily replace that with a test for 'ino != NULL'. We don't usually "fix" compiler bugs by changing valid kernel code, but cleanups are acceptable if they help to clarify what is going on. Oh, another thing: that code will currently race very nicely against 'umount', and looks capable of triggering the 'VFS: Busy inodes after unmount of foo. Self-destruct in 5 seconds. Have a nice day..." since it doesn't do anything to pin the super block while holding a reference to the inode. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com