| commit | d032eaa73fcc89af9638f9c6cc8839e8ee5cdcc0 | [log] [tgz] |
|---|---|---|
| author | Kui-Feng Lee <kuifeng@meta.com> | Wed Mar 22 20:24:00 2023 -0700 |
| committer | Quentin Monnet <qmonnet+github@qoba.lt> | Tue Apr 04 14:30:46 2023 +0100 |
| tree | a9d32a39579ed2e0c23562406a83f51f91189134 | |
| parent | 1d2424f7e468eb176722f0499ca5b16326159bb0 [diff] |
bpf: Create links for BPF struct_ops maps. Make bpf_link support struct_ops. Previously, struct_ops were always used alone without any associated links. Upon updating its value, a struct_ops would be activated automatically. Yet other BPF program types required to make a bpf_link with their instances before they could become active. Now, however, you can create an inactive struct_ops, and create a link to activate it later. With bpf_links, struct_ops has a behavior similar to other BPF program types. You can pin/unpin them from their links and the struct_ops will be deactivated when its link is removed while previously need someone to delete the value for it to be deactivated. bpf_links are responsible for registering their associated struct_ops. You can only use a struct_ops that has the BPF_F_LINK flag set to create a bpf_link, while a structs without this flag behaves in the same manner as before and is registered upon updating its value. The BPF_LINK_TYPE_STRUCT_OPS serves a dual purpose. Not only is it used to craft the links for BPF struct_ops programs, but also to create links for BPF struct_ops them-self. Since the links of BPF struct_ops programs are only used to create trampolines internally, they are never seen in other contexts. Thus, they can be reused for struct_ops themself. To maintain a reference to the map supporting this link, we add bpf_struct_ops_link as an additional type. The pointer of the map is RCU and won't be necessary until later in the patchset. Signed-off-by: Kui-Feng Lee <kuifeng@meta.com> Link: https://lore.kernel.org/r/20230323032405.3735486-4-kuifeng@meta.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
This is a mirror of bpf-next Linux source tree's tools/bpf/bpftool directory, plus its few dependencies from under kernel/bpf/, and its supporting header files.
All the gory details of syncing can be found in scripts/sync-kernel.sh script.
Some header files in this repo (include/linux/*.h) are reduced versions of their counterpart files at bpf-next's tools/include/linux/*.h to make compilation successful.
Please check out the manual pages for documentation about bpftool. A number of example invocations are also displayed in this blog post.
All general BPF questions, including kernel functionality, bpftool features and usage, should be sent to bpf@vger.kernel.org mailing list. You can subscribe to it here and search its archive here. Please search the archive before asking new questions. It very well might be that this was already addressed or answered before.
bpf@vger.kernel.org is monitored by many more people and they will happily try to help you with whatever issue you have. This repository's PRs and issues should be opened only for dealing with issues pertaining to specific way this bpftool mirror repo is set up and organized.
Required:
Optional:
This repository uses libbpf as a submodule. You can initialize it when cloning bpftool:
$ git clone --recurse-submodules https://github.com/libbpf/bpftool.git
Alternatively, if you have already cloned the repository, you can initialize the submodule by running the following command from within the repository:
$ git submodule update --init
To build bpftool:
$ cd src
$ make
To build and install bpftool on the system:
$ cd src # make install
Building bpftool in a separate directory is supported via the OUTPUT variable:
$ mkdir /tmp/bpftool $ cd src $ OUTPUT=/tmp/bpftool make
Most of the output is suppressed by default, but detailed building logs can be displayed by passing V=1:
$ cd src $ make V=1
Additional compilation flags can be passed to the command line if required. For example, we can create a static build with the following commands:
$ cd src $ EXTRA_CFLAGS=--static make
Note that to use the LLVM disassembler with static builds, we need a static version of the LLVM library installed on the system:
Download a precompiled LLVM release or build it locally.
Download the appropriate release of LLVM for your platform, for example on x86_64 with LLVM 15.0.0:
$ curl -LO https://github.com/llvm/llvm-project/releases/download/llvmorg-15.0.0/clang+llvm-15.0.0-x86_64-linux-gnu-rhel-8.4.tar.xz $ tar xvf clang+llvm-15.0.0-x86_64-linux-gnu-rhel-8.4.tar.xz $ mv clang+llvm-15.0.0-x86_64-linux-gnu-rhel-8.4 llvm_build
Alternatively, clone and build the LLVM libraries locally.
$ git clone https://github.com/llvm/llvm-project.git $ mkdir llvm_build $ cmake -S llvm-project/llvm -B llvm_build -DCMAKE_BUILD_TYPE=Release $ make -j -C llvm_build llvm-config llvm-libraries
Build bpftool with EXTRA_CFLAGS set to --static, and by passing the path to the relevant llvm-config.
$ cd bpftool $ LLVM_CONFIG=../../llvm_build/bin/llvm-config EXTRA_CFLAGS=--static make -j -C src
The man pages for bpftool can be built with:
$ cd docs
$ make
They can be installed on the system with:
$ cd docs # make install
This work is dual-licensed under the GNU GPL v2.0 (only) license and the BSD 2-clause license. You can choose between one of them if you use this work.
SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)