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.

0 files changed, 0 insertions, 0 deletions