diff options
| author | Daniel Borkmann <daniel@iogearbox.net> | 2018-11-29 00:07:57 +0300 |
|---|---|---|
| committer | Daniel Borkmann <daniel@iogearbox.net> | 2018-11-29 00:07:58 +0300 |
| commit | 36dbe571c2c9ac21b964fc87f3e34206b33507ac (patch) | |
| tree | c111feefec6b729f35b21583ffc2b66cfc4fbe27 /include/uapi/linux | |
| parent | 17d95e4225bf24ef3399d9e71c512311259d1ac9 (diff) | |
| parent | 1ade9abadfca0250c8256bb222a1cd5cc5fa8bbc (diff) | |
| download | linux-36dbe571c2c9ac21b964fc87f3e34206b33507ac.tar.xz | |
Merge branch 'bpf-sk-msg-pop-data'
John Fastabend says:
====================
After being able to add metadata to messages with sk_msg_push_data we
have also found it useful to be able to "pop" this metadata off before
sending it to applications in some cases. This series adds a new helper
sk_msg_pop_data() and the associated patches to add tests and tools/lib
support.
Thanks!
v2: Daniel caught that we missed adding sk_msg_pop_data to the changes
data helper so that the verifier ensures BPF programs revalidate
data after using this helper. Also improve documentation adding a
return description and using RST syntax per Quentin's comment. And
delta calculations for DROP with pop'd data (albeit a strange set
of operations for a program to be doing) had potential to be
incorrect possibly confusing user space applications, so fix it.
====================
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Diffstat (limited to 'include/uapi/linux')
| -rw-r--r-- | include/uapi/linux/bpf.h | 16 |
1 files changed, 15 insertions, 1 deletions
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index 23e2031a43d4..597afdbc1ab9 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -2268,6 +2268,19 @@ union bpf_attr { * * Return * 0 on success, or a negative error in case of failure. + * + * int bpf_msg_pop_data(struct sk_msg_buff *msg, u32 start, u32 pop, u64 flags) + * Description + * Will remove *pop* bytes from a *msg* starting at byte *start*. + * This may result in **ENOMEM** errors under certain situations if + * an allocation and copy are required due to a full ring buffer. + * However, the helper will try to avoid doing the allocation + * if possible. Other errors can occur if input parameters are + * invalid either due to *start* byte not being valid part of msg + * payload and/or *pop* value being to large. + * + * Return + * 0 on success, or a negative erro in case of failure. */ #define __BPF_FUNC_MAPPER(FN) \ FN(unspec), \ @@ -2360,7 +2373,8 @@ union bpf_attr { FN(map_push_elem), \ FN(map_pop_elem), \ FN(map_peek_elem), \ - FN(msg_push_data), + FN(msg_push_data), \ + FN(msg_pop_data), /* integer value in 'imm' field of BPF_CALL instruction selects which helper * function eBPF program intends to call |