From: Markus Elfring <[email protected]>
Date: Tue, 17 Nov 2015 17:37:22 +0100
The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <[email protected]>
---
net/core/scm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/scm.c b/net/core/scm.c
index 3b6899b..4f64173 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -193,7 +193,7 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
}
}
- if (p->fp && !p->fp->count)
+ if (likely(!p->fp->count))
{
kfree(p->fp);
p->fp = NULL;
--
2.6.2
From: SF Markus Elfring <[email protected]>
Date: Tue, 17 Nov 2015 17:43:35 +0100
> From: Markus Elfring <[email protected]>
> Date: Tue, 17 Nov 2015 17:37:22 +0100
>
> The kfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <[email protected]>
STOP submitting this crap, NOW!
I told you I won't review nor apply these patches any more.
And ever worse, this one is BUGGY.
We're testing p->fp so we know if we can safely dereference
it or not.
You're adding an OOPS to the kernel.
This is why these mindless mechanical transformations are not
only often a waste of time, they are dangerous as well.
I am silently rejecting from patchwork, immediately, any and all
patches you submit of this nature.
On 11/17/2015 05:43 PM, SF Markus Elfring wrote:
> From: Markus Elfring <[email protected]>
> Date: Tue, 17 Nov 2015 17:37:22 +0100
>
> The kfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <[email protected]>
> ---
> net/core/scm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/scm.c b/net/core/scm.c
> index 3b6899b..4f64173 100644
> --- a/net/core/scm.c
> +++ b/net/core/scm.c
> @@ -193,7 +193,7 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
> }
> }
>
> - if (p->fp && !p->fp->count)
> + if (likely(!p->fp->count))
> {
> kfree(p->fp);
> p->fp = NULL;
>
Really, I don't like your blind, silly removals everywhere throughout
the kernel tree for these tests. Eric already mentioned that in some
situations where it's critical, it actually slows down the code, i.e.
you'll have an extra function call to get there and inside kfree() /
kfree_skb() / etc, the test is actually marked as unlikely().
Anyway, I think this one in particular could throw a NULL pointer deref.
You even say in your commit message "kfree() function tests whether its
argument [p->fp] is NULL" and yet if that is the case then, you already
deref'ed on the p->fp->count test ???
> Eric already mentioned that in some situations where it's critical,
> it actually slows down the code, i.e. you'll have an extra
> function call to get there and inside kfree() / kfree_skb() / etc,
> the test is actually marked as unlikely().
How do you think about to add similar annotations to any more
source code places?
Regards,
Markus
On 11/17/2015 07:05 PM, SF Markus Elfring wrote:
>> Eric already mentioned that in some situations where it's critical,
>> it actually slows down the code, i.e. you'll have an extra
>> function call to get there and inside kfree() / kfree_skb() / etc,
>> the test is actually marked as unlikely().
>
> How do you think about to add similar annotations to any more
> source code places?
You mean this likely() annotation of yours? It doesn't make any sense
to me to place it there, and since you've spend the second thinking
about it when adding it to the diff, you should have already realized
that your code was buggy ...
> You mean this likely() annotation of yours?
How do you think about to express the software design pattern
which is applied at the mentioned source code place by a dedicated
preprocessor macro?
Regards,
Markus
On Wed, 2015-11-18 at 08:45 +0100, SF Markus Elfring wrote:
> > You mean this likely() annotation of yours?
>
> How do you think about to express the software design pattern
> which is applied at the mentioned source code place by a dedicated
> preprocessor macro?
likely()/unlikely() are not always applicable.
In the Ipv6 case I mentioned to you, it all depends if an application
for some reason absolutely wants the sockets to store the extra skb
There are seldom used socket options. _if_/_when_ they are used, a
likely()/unlikely() would give the wrong signal.
likely() should only be used in contexts we know better than branch
predictor/compiler.