* [patch] NFS: kmalloc() doesn't return an ERR_PTR() @ 2012-05-14 19:45 ` Dan Carpenter 0 siblings, 0 replies; 16+ messages in thread From: Dan Carpenter @ 2012-05-14 19:45 UTC (permalink / raw) To: Trond Myklebust; +Cc: linux-nfs, kernel-janitors 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) { + ret = -ENOMEM; goto out0; } im = kmalloc(sizeof(*im), GFP_KERNEL); - if (IS_ERR(im)) { - ret = PTR_ERR(im); + if (!im) { + ret = -ENOMEM; goto out1; } ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [patch] NFS: kmalloc() doesn't return an ERR_PTR() @ 2012-05-14 19:45 ` Dan Carpenter 0 siblings, 0 replies; 16+ messages in thread From: Dan Carpenter @ 2012-05-14 19:45 UTC (permalink / raw) To: Trond Myklebust; +Cc: linux-nfs, kernel-janitors 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) { + ret = -ENOMEM; goto out0; } im = kmalloc(sizeof(*im), GFP_KERNEL); - if (IS_ERR(im)) { - ret = PTR_ERR(im); + if (!im) { + ret = -ENOMEM; goto out1; } ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() 2012-05-14 19:45 ` Dan Carpenter @ 2012-05-15 13:48 ` Boaz Harrosh -1 siblings, 0 replies; 16+ messages in thread From: Boaz Harrosh @ 2012-05-15 13:48 UTC (permalink / raw) To: Dan Carpenter; +Cc: Trond Myklebust, linux-nfs, kernel-janitors 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() Thanks Boaz > + ret = -ENOMEM; > goto out0; > } > > im = kmalloc(sizeof(*im), GFP_KERNEL); > - if (IS_ERR(im)) { > - ret = PTR_ERR(im); > + if (!im) { > + ret = -ENOMEM; > goto out1; > } > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() @ 2012-05-15 13:48 ` Boaz Harrosh 0 siblings, 0 replies; 16+ messages in thread From: Boaz Harrosh @ 2012-05-15 13:48 UTC (permalink / raw) To: Dan Carpenter; +Cc: Trond Myklebust, linux-nfs, kernel-janitors 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() Thanks Boaz > + ret = -ENOMEM; > goto out0; > } > > im = kmalloc(sizeof(*im), GFP_KERNEL); > - if (IS_ERR(im)) { > - ret = PTR_ERR(im); > + if (!im) { > + ret = -ENOMEM; > goto out1; > } > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() 2012-05-15 13:48 ` Boaz Harrosh @ 2012-05-15 13:57 ` Dan Carpenter -1 siblings, 0 replies; 16+ messages in thread From: Dan Carpenter @ 2012-05-15 13:57 UTC (permalink / raw) To: Boaz Harrosh; +Cc: Trond Myklebust, linux-nfs, kernel-janitors 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. regards, dan carpenter ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() @ 2012-05-15 13:57 ` Dan Carpenter 0 siblings, 0 replies; 16+ messages in thread From: Dan Carpenter @ 2012-05-15 13:57 UTC (permalink / raw) To: Boaz Harrosh; +Cc: Trond Myklebust, linux-nfs, kernel-janitors 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. regards, dan carpenter ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() 2012-05-15 13:57 ` Dan Carpenter @ 2012-05-15 14:18 ` Boaz Harrosh -1 siblings, 0 replies; 16+ messages in thread From: Boaz Harrosh @ 2012-05-15 14:18 UTC (permalink / raw) To: Dan Carpenter; +Cc: Trond Myklebust, linux-nfs, kernel-janitors 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() @ 2012-05-15 14:18 ` Boaz Harrosh 0 siblings, 0 replies; 16+ messages in thread From: Boaz Harrosh @ 2012-05-15 14:18 UTC (permalink / raw) To: Dan Carpenter; +Cc: Trond Myklebust, linux-nfs, kernel-janitors 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() 2012-05-15 14:18 ` Boaz Harrosh @ 2012-05-15 15:27 ` Jim Rees -1 siblings, 0 replies; 16+ messages in thread From: Jim Rees @ 2012-05-15 15:27 UTC (permalink / raw) To: Boaz Harrosh; +Cc: Dan Carpenter, Trond Myklebust, linux-nfs, kernel-janitors Boaz Harrosh wrote: > 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. Personally I don't like it. It's a hint for the compiler. Remember when code was liberally sprinkled with "register" modifiers on local variables? Turned out the compiler was smarter than we were, and those modifiers were hurting performance. I'd rather let the compiler decide how to optimize. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() @ 2012-05-15 15:27 ` Jim Rees 0 siblings, 0 replies; 16+ messages in thread From: Jim Rees @ 2012-05-15 15:27 UTC (permalink / raw) To: Boaz Harrosh; +Cc: Dan Carpenter, Trond Myklebust, linux-nfs, kernel-janitors Boaz Harrosh wrote: > 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. Personally I don't like it. It's a hint for the compiler. Remember when code was liberally sprinkled with "register" modifiers on local variables? Turned out the compiler was smarter than we were, and those modifiers were hurting performance. I'd rather let the compiler decide how to optimize. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() 2012-05-15 15:27 ` Jim Rees @ 2012-05-15 16:06 ` Boaz Harrosh -1 siblings, 0 replies; 16+ messages in thread From: Boaz Harrosh @ 2012-05-15 16:06 UTC (permalink / raw) To: Jim Rees; +Cc: Dan Carpenter, Trond Myklebust, linux-nfs, kernel-janitors On 05/15/2012 06:27 PM, Jim Rees wrote: > Boaz Harrosh wrote: > > > 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. > > Personally I don't like it. It's a hint for the compiler. Remember when > code was liberally sprinkled with "register" modifiers on local variables? > Turned out the compiler was smarter than we were, and those modifiers were > hurting performance. I'd rather let the compiler decide how to optimize. Actually the compiler cannot. This is specifying: "against all judgment I consider this path as the cold path, even if it is taken more times or generates less compact code. Remove this branch from branch prediction permanently, and never pre-fetch this path" Again for me it's a programming style programmer-to-programmer hint. And is very unlike "register". The Kernel style does use unlikely() extensively in error paths, so it's not only me. I'm not sure what the official stance is though. I agree that it's all just shop talk ;-) Thanks Boaz ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() @ 2012-05-15 16:06 ` Boaz Harrosh 0 siblings, 0 replies; 16+ messages in thread From: Boaz Harrosh @ 2012-05-15 16:06 UTC (permalink / raw) To: Jim Rees; +Cc: Dan Carpenter, Trond Myklebust, linux-nfs, kernel-janitors On 05/15/2012 06:27 PM, Jim Rees wrote: > Boaz Harrosh wrote: > > > 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. > > Personally I don't like it. It's a hint for the compiler. Remember when > code was liberally sprinkled with "register" modifiers on local variables? > Turned out the compiler was smarter than we were, and those modifiers were > hurting performance. I'd rather let the compiler decide how to optimize. Actually the compiler cannot. This is specifying: "against all judgment I consider this path as the cold path, even if it is taken more times or generates less compact code. Remove this branch from branch prediction permanently, and never pre-fetch this path" Again for me it's a programming style programmer-to-programmer hint. And is very unlike "register". The Kernel style does use unlikely() extensively in error paths, so it's not only me. I'm not sure what the official stance is though. I agree that it's all just shop talk ;-) Thanks Boaz ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() 2012-05-15 14:18 ` Boaz Harrosh @ 2012-05-15 16:49 ` walter harms -1 siblings, 0 replies; 16+ messages in thread From: walter harms @ 2012-05-15 16:49 UTC (permalink / raw) To: Boaz Harrosh; +Cc: Dan Carpenter, Trond Myklebust, linux-nfs, kernel-janitors Am 15.05.2012 16:18, schrieb Boaz Harrosh: > 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 >> > > Not long a go we had a hint from one of the developers that this likely()-stuff should be used in the scheduler and has no use outside. re, wh ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() @ 2012-05-15 16:49 ` walter harms 0 siblings, 0 replies; 16+ messages in thread From: walter harms @ 2012-05-15 16:49 UTC (permalink / raw) To: Boaz Harrosh; +Cc: Dan Carpenter, Trond Myklebust, linux-nfs, kernel-janitors Am 15.05.2012 16:18, schrieb Boaz Harrosh: > 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 >> > > Not long a go we had a hint from one of the developers that this likely()-stuff should be used in the scheduler and has no use outside. re, wh ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() 2012-05-15 16:49 ` walter harms @ 2012-05-16 0:38 ` Peng Tao -1 siblings, 0 replies; 16+ messages in thread From: Peng Tao @ 2012-05-16 0:38 UTC (permalink / raw) To: wharms Cc: Boaz Harrosh, Dan Carpenter, Trond Myklebust, linux-nfs, kernel-janitors On Wed, May 16, 2012 at 12:49 AM, walter harms <wharms@bfs.de> wrote: > > > Am 15.05.2012 16:18, schrieb Boaz Harrosh: >> 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. >> My impression is these hints are useful iif the code is on performance critical path like scheduler, path walking, etc. Apparently nfs idmap isn't the case. Thanks, Tao >>> regards, >>> dan carpenter >>> >> >> > > Not long a go we had a hint from one of the developers that this likely()-stuff > should be used in the scheduler and has no use outside. > > re, > wh > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR() @ 2012-05-16 0:38 ` Peng Tao 0 siblings, 0 replies; 16+ messages in thread From: Peng Tao @ 2012-05-16 0:38 UTC (permalink / raw) To: wharms Cc: Boaz Harrosh, Dan Carpenter, Trond Myklebust, linux-nfs, kernel-janitors On Wed, May 16, 2012 at 12:49 AM, walter harms <wharms@bfs.de> wrote: > > > Am 15.05.2012 16:18, schrieb Boaz Harrosh: >> 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. >> My impression is these hints are useful iif the code is on performance critical path like scheduler, path walking, etc. Apparently nfs idmap isn't the case. Thanks, Tao >>> regards, >>> dan carpenter >>> >> >> > > Not long a go we had a hint from one of the developers that this likely()-stuff > should be used in the scheduler and has no use outside. > > re, > wh > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-05-16 0:38 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-05-14 19:45 [patch] NFS: kmalloc() doesn't return an ERR_PTR() Dan Carpenter 2012-05-14 19:45 ` Dan Carpenter 2012-05-15 13:48 ` Boaz Harrosh 2012-05-15 13:48 ` Boaz Harrosh 2012-05-15 13:57 ` Dan Carpenter 2012-05-15 13:57 ` Dan Carpenter 2012-05-15 14:18 ` Boaz Harrosh 2012-05-15 14:18 ` Boaz Harrosh 2012-05-15 15:27 ` Jim Rees 2012-05-15 15:27 ` Jim Rees 2012-05-15 16:06 ` Boaz Harrosh 2012-05-15 16:06 ` Boaz Harrosh 2012-05-15 16:49 ` walter harms 2012-05-15 16:49 ` walter harms 2012-05-16 0:38 ` Peng Tao 2012-05-16 0:38 ` Peng Tao
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.