Message-ID: <7c36a9aa-bfc6-6d97-ba86-c58d86e6713c@iogearbox.net>
Date:   Fri, 3 Aug 2018 10:14:23 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Roman Gushchin <guro@...com>, netdev@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, kernel-team@...com,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>
Subject: Re: [PATCH v7 bpf-next 00/14] bpf: cgroup local storage

On 08/02/2018 11:27 PM, Roman Gushchin wrote:
> 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@...com>
> Cc: Alexei Starovoitov <ast@...nel.org>
> Cc: Martin KaFai Lau <kafai@...com>
> 
> Roman Gushchin (14):
>   bpf: add ability to charge bpf maps memory dynamically
>   bpf: introduce cgroup storage maps
>   bpf: pass a pointer to a cgroup storage using pcpu variable
>   bpf: allocate cgroup storage entries on attaching bpf programs
>   bpf: extend bpf_prog_array to store pointers to the cgroup storage
>   bpf/verifier: introduce BPF_PTR_TO_MAP_VALUE
>   bpf: don't allow create maps of cgroup local storages
>   bpf: introduce the bpf_get_local_storage() helper function
>   bpf: sync bpf.h to tools/
>   bpftool: add support for CGROUP_STORAGE maps
>   bpf/test_run: support cgroup local storage
>   selftests/bpf: add verifier cgroup storage tests
>   selftests/bpf: add a cgroup storage test
>   samples/bpf: extend test_cgrp2_attach2 test to use cgroup storage

Tossed the old series from bpf-next and replaced with this one which fixes
the syzkaller issue, thanks Roman!

Powered by blists - more mailing lists