Re: [patch 0/3] Allow inlined spinlocks again V3

[David Miller <davem@davemloft.net>]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 14 Aug 2009 11:08:16 -0700 (PDT)

> On Fri, 14 Aug 2009, Heiko Carstens wrote:
>> 
>> However quite a few of the additional function calls in networking code
>> come from uninlining:
>> 
>> c2aa270a [NET]: uninline skb_push, de-bloats a lot
>> 6be8ac2f [NET]: uninline skb_pull, de-bloats a lot
>> 419ae74e [NET]: uninline skb_trim, de-bloats
> 
> Hmm. Those functions are big only because of the stupid debugging, which 
> is almost certainly not worth it any more. I doubt people have seen enough 
> skb under/over-flows in the last years to merit the code.

We have found a few bugs in the past year or two because of
the check, but indeed not "a lot".

> I suspect we should remove the silly skb_under/over_panic functions, and 
> do
> 
>  - skb_put:
> 	-       if (unlikely(skb->tail > skb->end))
> 	-               skb_over_panic(skb, len, __builtin_return_address(0));
> 	+       BUG_ON(skb->tail > skb->end);
> 
>  - skb_push:
> 	-       if (unlikely(skb->data<skb->head))
> 	-               skb_under_panic(skb, len, __builtin_return_address(0));
> 	+       BUG_ON(skb->data < skb->head);
> 
> at which point it might be worthwhile to inline them again, because the 
> footprint of a BUG_ON() is really fairly small.

Maybe.  Although most people turn on verbose BUG's and that
expands to the same if not more code than what's there now
in these SKB inlines.