aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/src/compat/compat.h
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2017-04-09 04:56:00 +0200
committerJason A. Donenfeld <Jason@zx2c4.com>2017-04-09 04:56:00 +0200
commitdfed22fb89b2a776ad4977d9d00ea319a6089d93 (patch)
tree8f6bf4400a13c09131923865401e3b20990d4353 /src/compat/compat.h
parentdebug: cleanups (diff)
downloadwireguard-linux-compat-dfed22fb89b2a776ad4977d9d00ea319a6089d93.tar.xz
wireguard-linux-compat-dfed22fb89b2a776ad4977d9d00ea319a6089d93.zip
data: alloca is actually as dangerous as they say
It turns out that calling alloca from an inline function means that the memory isn't ever deallocated until the caller function exits, which means we were using tons of stack space for every iteration of the call. So, we hard code the sg array. While 128 seems like a reasonable number, we actually wind up using "MAX_SKB_FRAGS * 2 + 1". An skb has its data segment, so that's 1. Then it has its frags, which are MAX_SKB_FRAGS at max. Then it has its frag list, which, so far as I can tell, are potentially unbounded. So we just hope it's no more than MAX_SKB_FRAGS, and so we plan for at most two of those. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Diffstat (limited to 'src/compat/compat.h')
0 files changed, 0 insertions, 0 deletions