History

bpf: sockmap, add msg_cork_bytes() helper

In the case where we need a specific number of bytes before a verdict can be assigned, even if the data spans multiple sendmsg or sendfile calls. The BPF program may use msg_cork_bytes(). The extreme case is a user can call sendmsg repeatedly with 1-byte msg segments. Obviously, this is bad for performance but is still valid. If the BPF program needs N bytes to validate a header it can use msg_cork_bytes to specify N bytes and the BPF program will not be called again until N bytes have been accumulated. The infrastructure will attempt to coalesce data if possible so in many cases (most my use cases at least) the data will be in a single scatterlist element with data pointers pointing to start/end of the element. However, this is dependent on available memory so is not guaranteed. So BPF programs must validate data pointer ranges, but this is the case anyways to convince the verifier the accesses are valid.

John Fastabend committed 8 years ago

Commit 91843d51 parent 2a100312 files · +18 −1Browse files

Showing the changes to include/uapi/linux (1 of 2 files). Show all

Unified · Split

include/uapi/linux/bpf.h+2−1
@@ -792,7 +792,8 @@ union bpf_attr { · 791 unmodified lines
792 FN(override_return), \792 FN(override_return), \
793 FN(sock_ops_cb_flags_set), \793 FN(sock_ops_cb_flags_set), \
794 FN(msg_redirect_map), \794 FN(msg_redirect_map), \
795 FN(msg_apply_bytes),795 FN(msg_apply_bytes), \
796 FN(msg_cork_bytes),
796 797
797/* integer value in 'imm' field of BPF_CALL instruction selects which helper798/* integer value in 'imm' field of BPF_CALL instruction selects which helper
798 * function eBPF program intends to call799 * function eBPF program intends to call