diff options
author | John Fastabend <john.fastabend@gmail.com> | 2018-12-17 02:47:04 +0300 |
---|---|---|
committer | Daniel Borkmann <daniel@iogearbox.net> | 2018-12-19 02:27:23 +0300 |
commit | 3bdbd0228e7555ec745e08469b98e5a0966409d6 (patch) | |
tree | 4a237a66574499f47d17fbcad4ad62f59384cfc1 /include/linux/skmsg.h | |
parent | 0bae2d4d62d523f06ff1a8e88ce38b45400acd28 (diff) | |
download | linux-3bdbd0228e7555ec745e08469b98e5a0966409d6.tar.xz |
bpf: sockmap, metadata support for reporting size of msg
This adds metadata to sk_msg_md for BPF programs to read the sk_msg
size.
When the SK_MSG program is running under an application that is using
sendfile the data is not copied into sk_msg buffers by default. Rather
the BPF program uses sk_msg_pull_data to read the bytes in. This
avoids doing the costly memcopy instructions when they are not in
fact needed. However, if we don't know the size of the sk_msg we
have to guess if needed bytes are available by doing a pull request
which may fail. By including the size of the sk_msg BPF programs can
check the size before issuing sk_msg_pull_data requests.
Additionally, the same applies for sendmsg calls when the application
provides multiple iovs. Here the BPF program needs to pull in data
to update data pointers but its not clear where the data ends without
a size parameter. In many cases "guessing" is not easy to do
and results in multiple calls to pull and without bounded loops
everything gets fairly tricky.
Clean this up by including a u32 size field. Note, all writes into
sk_msg_md are rejected already from sk_msg_is_valid_access so nothing
additional is needed there.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Diffstat (limited to 'include/linux/skmsg.h')
-rw-r--r-- | include/linux/skmsg.h | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h index 2a11e9d91dfa..eb8f6cb84c10 100644 --- a/include/linux/skmsg.h +++ b/include/linux/skmsg.h @@ -36,6 +36,9 @@ struct sk_msg_sg { struct scatterlist data[MAX_MSG_FRAGS + 1]; }; +/* UAPI in filter.c depends on struct sk_msg_sg being first element. If + * this is moved filter.c also must be updated. + */ struct sk_msg { struct sk_msg_sg sg; void *data; |