lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 21 May 2014 08:51:09 -0700
From:	Eric Dumazet <>
To:	Alexander Duyck <>
Cc:	Alexander Duyck <>,
	David Miller <>,,,,,,,,,,,,,
Subject: Re: [PATCH net-next 1/2] net: Expose header length compution

On Wed, 2014-05-21 at 08:03 -0700, Alexander Duyck wrote:

> So it looks like you did kind of what I expected you would, only you
> allocated a temporary sk_buff on the stack and then pointed the head to
> the start of the page.  I'm not really a fan of this approach though it
> does give me a couple ideas.
> One thought I just had though, what if we were to do something like
> create an eth_build_skb function?

Well, it all depends if you use napi_get_frags() / napi_gro_frags(),
which are normally the way to get very fast GRO processing, since
you don't even have to allocate memory for the skbs at all, since
skb will likely be recycled in napi_reuse_skb()

>   It would essentially be a cross
> between eth_type_trans, your new eth_frame_headlen function, and
> build_skb.  It would allow us to avoid the unnecessary allocation of an
> skb on the stack and avoid any unnecessary data duplication since we
> already would be doing a number of the eth_type_trans steps in your
> eth_frame_headlen function.  The one limitation is that we would need to
> allocate a block of memory for the head, but that would be done after we
> figure out what the size of the header is.

'Allocating' an skb on stack has no cost. Exactly 0 added instructions.

It only increases the size of stack, and at this point we are before all
the networking stacks, so it is safe.

Have you seen the eBPF stuff adding more stack usage than this ?

#define MAX_BPF_STACK 512

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists