Merge branch 'bpf-cgroup-local-storage'
Roman Gushchin says:
====================
This patchset implements cgroup local storage for bpf programs.
The main idea is to provide a fast accessible memory for storing
various per-cgroup data, e.g. number of transmitted packets.
Cgroup local storage looks as a special type of map for userspace,
and is accessible using generic bpf maps API for reading and
updating of the data. The (cgroup inode id, attachment type) pair
is used as a map key.
A user can't create new entries or destroy existing entries;
it happens automatically when a user attaches/detaches a bpf program
to a cgroup.
From a bpf program's point of view, cgroup storage is accessible
without lookup using the special get_local_storage() helper function.
It takes a map fd as an argument. It always returns a valid pointer
to the corresponding memory area.
To implement such a lookup-free access a pointer to the cgroup
storage is saved for an attachment of a bpf program to a cgroup,
if required by the program. Before running the program, it's saved
in a special global per-cpu variable, which is accessible from the
get_local_storage() helper.
This patchset implement only cgroup local storage, however the API
is intentionally made extensible to support other local storage types
further: e.g. thread local storage, socket local storage, etc.
v7->v6:
- fixed a use-after-free bug, caused by not clearing
prog->aux->cgroup_storage pointer after releasing the map
v6->v5:
- fixed an error with returning -EINVAL instead of a pointer
v5->v4:
- fixed an issue in verifier (test that flags == 0 properly)
- added a corresponding test
- added a note about synchronization, sync docs to tools/uapi/...
- switched the cgroup test to use XADD
- added a check for attr->max_entries to be 0, and atter->max_flags
to be sane
- use bpf_uncharge_memlock() in bpf_uncharge_memlock()
- rebased to bpf-next
v4->v3:
- fixed a leak in cgroup attachment code (discovered by Daniel)
- cgroup storage map will be released if the corresponding
bpf program failed to load by any reason
- introduced bpf_uncharge_memlock() helper
v3->v2:
- fixed more build and sparse issues
- rebased to bpf-next
v2->v1:
- fixed build issues
- removed explicit rlimit calls in patch 14
- rebased to bpf-next
====================
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
