[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180813124014.iivbtjrsdv5odnuu@mwanda>
Date: Mon, 13 Aug 2018 15:40:14 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Gao Xiang <gaoxiang25@...wei.com>
Cc: Chao Yu <chao@...nel.org>, devel@...verdev.osuosl.org,
gregkh@...uxfoundation.org, Chao Yu <yuchao0@...wei.com>,
linux-erofs@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/8] staging: erofs: add error handling for xattr
submodule
On Mon, Aug 13, 2018 at 08:17:27PM +0800, Gao Xiang wrote:
> >> @@ -294,8 +322,11 @@ static int inline_getxattr(struct inode *inode, struct getxattr_iter *it)
> >> ret = xattr_foreach(&it->it, &find_xattr_handlers, &remaining);
> >> if (ret >= 0)
> >> break;
> >> +
> >> + if (unlikely(ret != -ENOATTR)) /* -ENOMEM, -EIO, etc. */
> >
> > I have held off commenting on all the likely/unlikely annotations we
> > are adding because I don't know what the fast paths are in this code.
> > However, this is clearly an error path here, not on a fast path.
> >
> > Generally the rule on likely/unlikely is that they hurt readability so
> > we should only add them if it makes a difference in benchmarking.
> >
>
> In my opinion, return values other than 0 and ENOATTR(ENODATA) rarely happens,
> it should be in the slow path...
>
What I'm trying to say is please stop adding so many likely/unlikely
annotations. You should only add them if you have the benchmark data to
show the it really is required.
regards,
dan carpenter
Powered by blists - more mailing lists