diff options
Diffstat (limited to 'Documentation/bpf')
| -rw-r--r-- | Documentation/bpf/bpf_devel_QA.rst | 16 | ||||
| -rw-r--r-- | Documentation/bpf/bpf_iterators.rst | 10 |
2 files changed, 19 insertions, 7 deletions
diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst index edf8107a7beb..4729efd657c3 100644 --- a/Documentation/bpf/bpf_devel_QA.rst +++ b/Documentation/bpf/bpf_devel_QA.rst @@ -374,9 +374,10 @@ developers in order to get the feature implemented in a timely manner. Please refer to the git log (``arch/*/net/``) to locate the necessary people for helping out. -Also always make sure to add BPF test cases (e.g. test_bpf.c and -test_verifier.c) for new instructions, so that they can receive -broad test coverage and help run-time testing the various BPF JITs. +Also always make sure to add BPF test cases (e.g. the jit_insns test +in test_progs and test_verifier.c) for new instructions, so that they +can receive broad test coverage and help run-time testing the various +BPF JITs. In case of new BPF instructions, once the changes have been accepted into the Linux kernel, please implement support into LLVM's BPF back @@ -514,10 +515,11 @@ A: If you run a kernel ``xyz``, then always run the BPF kernel selftests from that kernel ``xyz`` as well. Do not expect that the BPF selftest from the latest mainline tree will pass all the time. -In particular, test_bpf.c and test_verifier.c have a large number of -test cases and are constantly updated with new BPF test sequences, or -existing ones are adapted to verifier changes e.g. due to verifier -becoming smarter and being able to better track certain things. +In particular, test_verifier.c and the instruction tests in test_progs +have a large number of test cases and are constantly updated with new +BPF test sequences, or existing ones are adapted to verifier changes +e.g. due to verifier becoming smarter and being able to better track +certain things. LLVM ==== diff --git a/Documentation/bpf/bpf_iterators.rst b/Documentation/bpf/bpf_iterators.rst index 189e3ec1c6c8..72435e32ffa1 100644 --- a/Documentation/bpf/bpf_iterators.rst +++ b/Documentation/bpf/bpf_iterators.rst @@ -86,6 +86,16 @@ Constructor/next/destructor implementation contract is as follows: resources and marks stack space used by `struct bpf_iter_<type>` as usable for something else. Destructor is marked with KF_ITER_DESTROY flag. +The verifier treats a non-RCU, non-acquired struct result as borrowed from +the iterator's current element. It invalidates the previous result and its +tracked derived pointers on the next call, including when it returns NULL, +and on destruction of the iterator. Resources borrowing that lifetime must +be released first. A next method whose struct result has an independent +lifetime must use ``KF_ITER_RET_INDEPENDENT``. This flag requires +``KF_ITER_NEXT`` and a struct pointer return type, and cannot be combined +with ``KF_ACQUIRE``. RCU-protected and acquired results retain their own +lifetime rules. + Any open-coded BPF iterator implementation has to implement at least these three methods. It is enforced that for any given type of iterator only applicable constructor/destructor/next are callable. I.e., verifier ensures |
