| Message ID | 564B5937.1070707@users.sourceforge.net |
|---|---|
| State | Rejected, archived |
| Delegated to: | David Miller |
| Headers | show |
From: SF Markus Elfring <elfring@users.sourceforge.net> Date: Tue, 17 Nov 2015 17:43:35 +0100 > From: Markus Elfring <elfring@users.sourceforge.net> > 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 <elfring@users.sourceforge.net> 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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/17/2015 05:43 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > 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 <elfring@users.sourceforge.net> > --- > 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 ??? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 ... -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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;