-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 17 +
net/core/skbuff.c | 18 ++
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/include/linux/
On Feb 20 2008 15:47, Ilpo Järvinen wrote:
>
>-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
>
>-static inline struct sk_buff *dev_alloc_skb(unsigned int length)
>-{
>- return __dev_alloc_skb(length, GFP_ATOMIC);
>-}
>+extern struct sk_buff *dev_alloc_skb(unsigned int lengt
Jan Engelhardt wrote:
On Feb 20 2008 15:47, Ilpo Järvinen wrote:
-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
-static inline struct sk_buff *dev_alloc_skb(unsigned int length)
-{
- return __dev_alloc_skb(length, GFP_ATOMIC);
-}
+extern struct sk_buff *dev_alloc_skb(un
On Feb 20 2008 17:27, Patrick McHardy wrote:
>> Striking. How can this even happen? A callsite which calls
>>
>> dev_alloc_skb(n)
>>
>> is just equivalent to
>>
>> __dev_alloc_skb(n, GFP_ATOMIC);
>>
>> which means there's like 4 (or 8 if it's long) bytes more on the
>> stack. For a worst cas
On Wed, 20 Feb 2008, Jan Engelhardt wrote:
>
> On Feb 20 2008 17:27, Patrick McHardy wrote:
> >> Striking. How can this even happen? A callsite which calls
> >>
> >> dev_alloc_skb(n)
> >>
> >> is just equivalent to
> >>
> >> __dev_alloc_skb(n, GFP_ATOMIC);
> >>
> >> which means there's like
