linux-kernel - Re: [PATCH] gfs2: Set error on error path

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]

Message-ID: <f8e478c86bb80f37fbedc4f17b782918bc1c3607.camel@mailo.com>
Date:   Fri, 29 Sep 2023 13:02:51 +0530
From:   drv <drv@...lo.com>
To:     Dan Carpenter <dan.carpenter@...aro.org>
Cc:     Bob Peterson <rpeterso@...hat.com>,
        Andreas Gruenbacher <agruenba@...hat.com>,
        gfs2@...ts.linux.dev, linux-kernel@...r.kernel.org,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        Dan Carpenter <error27@...il.com>
Subject: Re: [PATCH] gfs2: Set error on error path

On Fri, 2023-09-29 at 10:14 +0300, Dan Carpenter wrote:
> On Fri, Sep 29, 2023 at 11:44:40AM +0530, Deepak R Varma wrote:
> > Set the error variable inside the error path on failure. Saves
> > unnecessary variable assignment during normal execution.
> > 
> > Signed-off-by: Deepak R Varma <drv@...lo.com>
> > ---
> >  fs/gfs2/bmap.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> > index ef7017fb6951..93bd8ea34444 100644
> > --- a/fs/gfs2/bmap.c
> > +++ b/fs/gfs2/bmap.c
> > @@ -162,9 +162,10 @@ int gfs2_unstuff_dinode(struct gfs2_inode *ip)
> >  
> >         down_write(&ip->i_rw_mutex);
> >         page = grab_cache_page(inode->i_mapping, 0);
> > -       error = -ENOMEM;
> > -       if (!page)
> > +       if (!page) {
> > +               error = -ENOMEM;
> >                 goto out;
> > +       }
> 
> It used to be that the other way was faster?  I'm pretty sure the
> compiler can figure it out these days.  Please don't randomly start
> changing people's prefered style unless it's drivers/staging/ code.
> 
Hi Dan,
Thank you for the feedback. I did not know about the compiler
optimization resulting in original code being faster.
I will let the maintainers comment on breaking the style.

regards,
deepak.

> regards,
> dan carpenter
>