linux-kernel - Re: [PATCH] ceph: remove unnecessary return in switch statement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 16 Aug 2020 10:00:46 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Luis Henriques <lhenriques@...e.de>,
        David Laight <David.Laight@...LAB.COM>
Cc:     Ilya Dryomov <idryomov@...il.com>,
        "ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ceph: remove unnecessary return in switch statement

On Fri, 2020-08-14 at 11:03 +0100, Luis Henriques wrote:
> David Laight <David.Laight@...LAB.COM> writes:
> 
> > From: Luis Henriques
> > > Sent: 14 August 2020 10:38
> > > 
> > > Since there's a return immediately after the 'break', there's no need for
> > > this extra 'return' in the S_IFDIR case.
> > > 
> > > Signed-off-by: Luis Henriques <lhenriques@...e.de>
> > > ---
> > >  fs/ceph/file.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> > > index d51c3f2fdca0..04ab99c0223a 100644
> > > --- a/fs/ceph/file.c
> > > +++ b/fs/ceph/file.c
> > > @@ -256,8 +256,6 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> > >  	case S_IFDIR:
> > >  		ret = ceph_init_file_info(inode, file, fmode,
> > >  						S_ISDIR(inode->i_mode));
> > > -		if (ret)
> > > -			return ret;
> > >  		break;
> > > 
> > >  	case S_IFLNK:
> > 
> > I'd move the other way and just do:
> > 		return ceph_init_file_info(...);
> 
> Sure, that would work too, although my preference would be to have a
> single function exit point.  But I'll leave that decision to Jeff :-)
> 

I think I agree with Luis here (though it's really a bit subjective). I
don't think it'll matter much to the compiled result either way, and
that will probably be better if this function grows in complexity.

I'll plan to merge this patch in the next day or so.

Thanks!
-- 
Jeff Layton <jlayton@...nel.org>