net/bpf: Fix writing of buffer bigger than PAGESIZE (Bug 205164)

[fflorens]

When allocating the mbuf we used m_get2 which fails
if len is superior to MJUMPAGESIZE, if its the case,
use m_getjcl instead.

This fixes bug 205164.

[kprovost]

This may be useful context:
https://lists.freebsd.org/pipermail/freebsd-net/2017-November/049231.html

The main concern is that allocating large contiguous memory areas (as is required for BPF) is problematic, especially under memory pressure. Changing the BPF code to cope with non-contiguous memory would be difficult, so I'm not sure what the best solution would be here.

[fflorens]

Well as i am fairly new to the internals of bpf, im someone can help me get up to speed, maybe i could patch this in a 'better' way allowing jumbo writes even under memory pressure.

[kprovost]

After the allocation of the mbuf the data that's supposed to be sent is copied from user space (that's the uiomove() call). That can be adapted to deal with an mbuf chain.
After that the filter program is applied (bpf_filter()), but that function assumes a flat (i.e. contiguous) buffer to operate on. It executes the BPF bytecode on that buffer. Changing that bytecode interpreter is not a realistic option I'm afraid.

[fflorens]

When using M_NOWAIT to allocate a buffer, shouldn't it fail under memory pressure ? thus avoiding any 'real' issue with big clusters under memory pressure.

[kprovost]

That helps, but holding contiguous memory (larger than a single page) is problematic too.

Ryan might be able to give you more information: https://lists.freebsd.org/pipermail/freebsd-net/2017-November/049258.html

[bsdimp]

Hash f13da24 lands this. I confirmed with kp@ that this was a good chance and that the negative effects noted by Ryan are less bad than this not working.