From: Boaz Harrosh <bharrosh@panasas.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>,
linux-nfs@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR()
Date: Tue, 15 May 2012 14:18:04 +0000 [thread overview]
Message-ID: <4FB2659C.5090005@panasas.com> (raw)
In-Reply-To: <20120515135733.GJ16984@mwanda>
On 05/15/2012 04:57 PM, Dan Carpenter wrote:
> On Tue, May 15, 2012 at 04:48:23PM +0300, Boaz Harrosh wrote:
>> On 05/14/2012 10:45 PM, Dan Carpenter wrote:
>>
>>> Obviously we should check for NULL here instead of IS_ERR().
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>>
>>> diff --git a/fs/nfs/idmap.c b/fs/nfs/idmap.c
>>> index ba3019f..233beea 100644
>>> --- a/fs/nfs/idmap.c
>>> +++ b/fs/nfs/idmap.c
>>> @@ -644,14 +644,14 @@ static int nfs_idmap_legacy_upcall(struct key_construction *cons,
>>>
>>> /* msg and im are freed in idmap_pipe_destroy_msg */
>>> msg = kmalloc(sizeof(*msg), GFP_KERNEL);
>>> - if (IS_ERR(msg)) {
>>> - ret = PTR_ERR(msg);
>>> + if (!msg) {
>>
>>
>> While at it please put an unlikely()
>>
>
> Normally we wouldn't put an unlikely() here. It makes the code
> less readable and it's not going to affect benchmarks. But I can
> add one if people prefer.
>
Personally It makes it more readable for me. It's like a statement:
"error, always slow-path case here". I have brain parsers set
for these.
Specifically here the if () is very small but if it is more code
it is exactly where it counts. But as a general rule I like the
error/slow-path case to be in an unlikely(). Later someone
might add more code which will matter.
> regards,
> dan carpenter
>
Thanks
Boaz
next prev parent reply other threads:[~2012-05-15 14:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 19:45 [patch] NFS: kmalloc() doesn't return an ERR_PTR() Dan Carpenter
2012-05-15 13:48 ` Boaz Harrosh
2012-05-15 13:57 ` Dan Carpenter
2012-05-15 14:18 ` Boaz Harrosh [this message]
2012-05-15 15:27 ` Jim Rees
2012-05-15 16:06 ` Boaz Harrosh
2012-05-15 16:49 ` walter harms
2012-05-16 0:38 ` Peng Tao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB2659C.5090005@panasas.com \
--to=bharrosh@panasas.com \
--cc=Trond.Myklebust@netapp.com \
--cc=dan.carpenter@oracle.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox