<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/tools/lib/bpf/libbpf.map, branch v5.9</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.9</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.9'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2020-08-13T23:45:41Z</updated>
<entry>
<title>libbpf: Handle BTF pointer sizes more carefully</title>
<updated>2020-08-13T23:45:41Z</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-08-13T20:49:40Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=44ad23dfbccbcd26d6ca504eba1ac55755864969'/>
<id>urn:sha1:44ad23dfbccbcd26d6ca504eba1ac55755864969</id>
<content type='text'>
With libbpf and BTF it is pretty common to have libbpf built for one
architecture, while BTF information was generated for a different architecture
(typically, but not always, BPF). In such case, the size of a pointer might
differ betweem architectures. libbpf previously was always making an
assumption that pointer size for BTF is the same as native architecture
pointer size, but that breaks for cases where libbpf is built as 32-bit
library, while BTF is for 64-bit architecture.

To solve this, add heuristic to determine pointer size by searching for `long`
or `unsigned long` integer type and using its size as a pointer size. Also,
allow to override the pointer size with a new API btf__set_pointer_size(), for
cases where application knows which pointer size should be used. User
application can check what libbpf "guessed" by looking at the result of
btf__pointer_size(). If it's not 0, then libbpf successfully determined a
pointer size, otherwise native arch pointer size will be used.

For cases where BTF is parsed from ELF file, use ELF's class (32-bit or
64-bit) to determine pointer size.

Fixes: 8a138aed4a80 ("bpf: btf: Add BTF support to libbpf")
Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion")
Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200813204945.1020225-5-andriin@fb.com
</content>
</entry>
<entry>
<title>libbpf: Add btf__parse_raw() and generic btf__parse() APIs</title>
<updated>2020-08-03T14:39:48Z</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-08-02T01:32:17Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=94a1fedd63edb672933bef44ca9213937e377c05'/>
<id>urn:sha1:94a1fedd63edb672933bef44ca9213937e377c05</id>
<content type='text'>
Add public APIs to parse BTF from raw data file (e.g.,
/sys/kernel/btf/vmlinux), as well as generic btf__parse(), which will try to
determine correct format, currently either raw or ELF.

Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/20200802013219.864880-2-andriin@fb.com
</content>
</entry>
<entry>
<title>libbpf: Add bpf_link detach APIs</title>
<updated>2020-08-02T03:38:28Z</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-07-31T18:28:27Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2e49527e52486dac910460b1b3f6fce6e21c6b48'/>
<id>urn:sha1:2e49527e52486dac910460b1b3f6fce6e21c6b48</id>
<content type='text'>
Add low-level bpf_link_detach() API. Also add higher-level bpf_link__detach()
one.

Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Acked-by: Song Liu &lt;songliubraving@fb.com&gt;
Acked-by: John Fastabend &lt;john.fastabend@gmail.com&gt;
Link: https://lore.kernel.org/bpf/20200731182830.286260-3-andriin@fb.com
</content>
</entry>
<entry>
<title>libbpf: Add support for BPF XDP link</title>
<updated>2020-07-26T03:37:02Z</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-07-22T06:46:00Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=dc8698cac7aada9b61a612cb819341d84591163e'/>
<id>urn:sha1:dc8698cac7aada9b61a612cb819341d84591163e</id>
<content type='text'>
Sync UAPI header and add support for using bpf_link-based XDP attachment.
Make xdp/ prog type set expected attach type. Kernel didn't enforce
attach_type for XDP programs before, so there is no backwards compatiblity
issues there.

Also fix section_names selftest to recognize that xdp prog types now have
expected attach type.

Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200722064603.3350758-8-andriin@fb.com
</content>
</entry>
<entry>
<title>libbpf: Add support for SK_LOOKUP program type</title>
<updated>2020-07-18T03:18:17Z</updated>
<author>
<name>Jakub Sitnicki</name>
<email>jakub@cloudflare.com</email>
</author>
<published>2020-07-17T10:35:33Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=499dd29d90bb78d4ac4f0d6648e26f4a339829b1'/>
<id>urn:sha1:499dd29d90bb78d4ac4f0d6648e26f4a339829b1</id>
<content type='text'>
Make libbpf aware of the newly added program type, and assign it a
section name.

Signed-off-by: Jakub Sitnicki &lt;jakub@cloudflare.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Acked-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Link: https://lore.kernel.org/bpf/20200717103536.397595-13-jakub@cloudflare.com
</content>
</entry>
<entry>
<title>libbpf: Add btf__set_fd() for more control over loaded BTF FD</title>
<updated>2020-07-08T22:44:44Z</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-07-08T01:53:14Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=81372e121802fd57892a0b44d93cc747d9568627'/>
<id>urn:sha1:81372e121802fd57892a0b44d93cc747d9568627</id>
<content type='text'>
Add setter for BTF FD to allow application more fine-grained control in more
advanced scenarios. Storing BTF FD inside `struct btf` provides little benefit
and probably would be better done differently (e.g., btf__load() could just
return FD on success), but we are stuck with this due to backwards
compatibility. The main problem is that it's impossible to load BTF and than
free user-space memory, but keep FD intact, because `struct btf` assumes
ownership of that FD upon successful load and will attempt to close it during
btf__free(). To allow callers (e.g., libbpf itself for BTF sanitization) to
have more control over this, add btf__set_fd() to allow to reset FD
arbitrarily, if necessary.

Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/20200708015318.3827358-3-andriin@fb.com
</content>
</entry>
<entry>
<title>libbpf: Support disabling auto-loading BPF programs</title>
<updated>2020-06-28T17:06:53Z</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-06-25T23:26:28Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d929758101fc0674008169dc1de963e3181c587b'/>
<id>urn:sha1:d929758101fc0674008169dc1de963e3181c587b</id>
<content type='text'>
Currently, bpf_object__load() (and by induction skeleton's load), will always
attempt to prepare, relocate, and load into kernel every single BPF program
found inside the BPF object file. This is often convenient and the right thing
to do and what users expect.

But there are plenty of cases (especially with BPF development constantly
picking up the pace), where BPF application is intended to work with old
kernels, with potentially reduced set of features. But on kernels supporting
extra features, it would like to take a full advantage of them, by employing
extra BPF program. This could be a choice of using fentry/fexit over
kprobe/kretprobe, if kernel is recent enough and is built with BTF. Or BPF
program might be providing optimized bpf_iter-based solution that user-space
might want to use, whenever available. And so on.

With libbpf and BPF CO-RE in particular, it's advantageous to not have to
maintain two separate BPF object files to achieve this. So to enable such use
cases, this patch adds ability to request not auto-loading chosen BPF
programs. In such case, libbpf won't attempt to perform relocations (which
might fail due to old kernel), won't try to resolve BTF types for
BTF-aware (tp_btf/fentry/fexit/etc) program types, because BTF might not be
present, and so on. Skeleton will also automatically skip auto-attachment step
for such not loaded BPF programs.

Overall, this feature allows to simplify development and deployment of
real-world BPF applications with complicated compatibility requirements.

Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200625232629.3444003-2-andriin@fb.com
</content>
</entry>
<entry>
<title>libbpf: Add a bunch of attribute getters/setters for map definitions</title>
<updated>2020-06-22T22:01:32Z</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-06-21T06:21:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1bdb6c9a1c43fdf9b83b2331dfc6229bd2e71d9b'/>
<id>urn:sha1:1bdb6c9a1c43fdf9b83b2331dfc6229bd2e71d9b</id>
<content type='text'>
Add a bunch of getter for various aspects of BPF map. Some of these attribute
(e.g., key_size, value_size, type, etc) are available right now in struct
bpf_map_def, but this patch adds getter allowing to fetch them individually.
bpf_map_def approach isn't very scalable, when ABI stability requirements are
taken into account. It's much easier to extend libbpf and add support for new
features, when each aspect of BPF map has separate getter/setter.

Getters follow the common naming convention of not explicitly having "get" in
its name: bpf_map__type() returns map type, bpf_map__key_size() returns
key_size. Setters, though, explicitly have set in their name:
bpf_map__set_type(), bpf_map__set_key_size().

This patch ensures we now have a getter and a setter for the following
map attributes:
  - type;
  - max_entries;
  - map_flags;
  - numa_node;
  - key_size;
  - value_size;
  - ifindex.

bpf_map__resize() enforces unnecessary restriction of max_entries &gt; 0. It is
unnecessary, because libbpf actually supports zero max_entries for some cases
(e.g., for PERF_EVENT_ARRAY map) and treats it specially during map creation
time. To allow setting max_entries=0, new bpf_map__set_max_entries() setter is
added. bpf_map__resize()'s behavior is preserved for backwards compatibility
reasons.

Map ifindex getter is added as well. There is a setter already, but no
corresponding getter. Fix this assymetry as well. bpf_map__set_ifindex()
itself is converted from void function into error-returning one, similar to
other setters. The only error returned right now is -EBUSY, if BPF map is
already loaded and has corresponding FD.

One lacking attribute with no ability to get/set or even specify it
declaratively is numa_node. This patch fixes this gap and both adds
programmatic getter/setter, as well as adds support for numa_node field in
BTF-defined map.

Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Toke Høiland-Jørgensen &lt;toke@redhat.com&gt;
Link: https://lore.kernel.org/bpf/20200621062112.3006313-1-andriin@fb.com
</content>
</entry>
<entry>
<title>libbpf: Bump version to 0.1.0</title>
<updated>2020-06-17T20:20:02Z</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-06-17T18:31:32Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7bd3a33ae6d2b820bc44a206f9b81b96840219fd'/>
<id>urn:sha1:7bd3a33ae6d2b820bc44a206f9b81b96840219fd</id>
<content type='text'>
Bump libbpf version to 0.1.0, as new development cycle starts.

Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200617183132.1970836-1-andriin@fb.com
</content>
</entry>
<entry>
<title>libbpf: Add support for bpf_link-based netns attachment</title>
<updated>2020-06-01T22:21:03Z</updated>
<author>
<name>Jakub Sitnicki</name>
<email>jakub@cloudflare.com</email>
</author>
<published>2020-05-31T08:28:40Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d60d81acc2c180e33244857e35ef60072573b000'/>
<id>urn:sha1:d60d81acc2c180e33244857e35ef60072573b000</id>
<content type='text'>
Add bpf_program__attach_nets(), which uses LINK_CREATE subcommand to create
an FD-based kernel bpf_link, for attach types tied to network namespace,
that is BPF_FLOW_DISSECTOR for the moment.

Signed-off-by: Jakub Sitnicki &lt;jakub@cloudflare.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200531082846.2117903-7-jakub@cloudflare.com
</content>
</entry>
</feed>
