This also bumps the bpfloader version to 0.3 to signify support
for loading schedact (ie. tc scheduler action) programs.
Test: load netd.o
Change-Id: Ic3fdc80d3f6ea2b42a4f1d6829b1ff12dd4d52c0
This is also bpfloader v0.2.
Some newer map types (for example DEVMAP) are unusable
on older kernel versions.
Bug: 190519702
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I085cc723ff1c19d8acc8972a391f894e16dd1875
This is bpfLoader v0.1, previously we had no version number,
the version immediately preceding this commit we'll call v0.0.
Versions older than that are either pre-S and don't matter, since
loading mainline eBpf code was only added in S, or are from early
during the S development cycle (ie. pre-March 5th 2021 or earlier)
and simply no longer supported (no need to maintain compatibility).
Bug: 190519702
Test: atest, TreeHugger - existing bpf programs load
examination of bpfloader logs
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I36fa5b917540be7ea3ecfddc5fe7834e9eb18d88
Needs to be used by dns mainline module tests on R devices (Pixel 2).
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2974a5368f4a9d744e30be9148aefac117d09acb
Basically:
<4.14: DEVMAP -> ARRAY
<5.4: DEVMAP_HASH -> HASH
See added comments for explanation of why, but basically:
This allows our bpf program .o files to load maps on all kernel versions,
even if those map types are not supported by the kernel.
This avoids the need for code that conditionally creates maps based on
kernel version. Any program that actually attempts to use one of these
maps will fail to load, but programs are already loaded conditionally
based on kernel version so this is not a problem.
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1a1d73b68de3606423de078fddb224402621e154
This slightly improves error logging.
(also fd == 0 is not an error condition)
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I135e7405c508951fba632c634bc4e2d2161fc940
Instead of doing 16/8/8 bits for major/minor/subver macro,
switch to 8/8/16 bits, since this gives plenty of space:
- major versions are bumped every few years, so 256 last forever
- minor versions are bumped every few months (~5-6 per year),
so 256 lasts for decades, additionally Linus Torvalds doesn't
like big numbers, and eventually bumps the major instead
- sub versions are the problematic ones, because they're bumped
on every LTS security release, however even at one release per day,
16 bits lasts for 180 years
Note: before this change 4.9.256 was treated as equivalent to 4.10.0.
Luckily all our tests were only ever (by chance) against the LTS release
bases (ie. 4.9.0, 4.14.0, 4.19.0, 5.4.0) and thus we wouldn't have hit
an actually failure until 4.9.(5*256) === 4.14.0 which would have caused
the bpfloader to attempt to load bpf code requiring 4.14 on a 4.9 kernel,
and resulted in failure of device to successfully boot.
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I0535ce081967af092f3342c0abfd05a1e5028eb6
This makes it harder for system and mainline bpf programs to
conflict with each other, thus enabling easier mainline module
updates.
Test: builds and boots, atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic1b69bb1ddc4a10bd4861dadbd6b97e2520c532d
//system/bpf/libbpf_android:libbpf_android clang-tidy Loader.cpp
system/bpf/libbpf_android/Loader.cpp:133:5: warning: Value stored to 'entries' is never read [clang-analyzer-deadcode.DeadStores]
entries = shTable.size();
^
system/bpf/libbpf_android/Loader.cpp:133:5: note: Value stored to 'entries' is never read
Test: builds without warnings
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I548976b59d44a51e992c9520e730fc9dae82fce2
so there is no longer a need to look at any properties
or api levels.
Test: builds, atest, TreeHugger
Bug: 167500195
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia5479db807f5444e48251dff45fd42fff610d5ca
Android S requires devices to support eBPF.
Test: builds, atest, TreeHugger
Bug: 167500195
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I62fb97f79103515f5a2fd531cfa36356d21a4a6f
This will be used by the tethering module when running on S, so
it needs to have an sdk_version. Because this target does not
depend on anything, there is no need to change any other code.
Because this is only needed by the tethering module, which
shipped in R, pick the R SDK version, 30. That ensures we do not
need to support it on releases older than when it is needed.
Test: m
Bug: 173167302
Change-Id: I15c1e943d0c30aceebcb8288e78a5a8135ee7fd1
Tested via:
packages/modules/Connectivity/Tethering/Tethering/bpf_progs/offload.c:
+DEFINE_BPF_PROG_KVER("xdp/test", AID_ROOT, AID_ROOT,
+ xdp_test, KVER(5, 10, 0))
+(struct xdp_md *ctx) {
+ return XDP_PASS;
+}
vsoc_x86:/ # ip link show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
vsoc_x86:/ # ip link set dev lo xdp pinned /sys/fs/bpf/prog_offload_xdp_test
vsoc_x86:/ # ip link show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
prog/xdp id 3 tag 3b185187f1855c4c jited
vsoc_x86:/ # ip link set dev lo xdp off
vsoc_x86:/ # ip link show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
Test: atest, TreeHugger
Bug: 167540099
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7472d6d8120344abde9ea0f44c59a46f30da77f1
libmeminfo needs to use BPF to read GPU usage reported by kernel
drivers, therefore a new dependency between libmeminfo and
libbpf_android is added. After this addition, native_bridge_supported
is required to successfully build cuttlefish targets.
Bug: 171261987
Test: build libmeminfo accessing BPF map
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I12e0613b13fb1206e204b5e85b4ea9a4d33e0cc9
Cause that's what it actually does...
Bug: 173167302
Test: atest BpfMapTest
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I8445cc4fe68f24bb3b26a678b7731b0c518e80f9
Logging every 5s isn't actually useful and it just gets the important stuff out
of log buffers.
Test: adb logcat -s 'bpfloader:D' 'BpfUtils:D' 'LibBpfLoader:D'
...
06-17 01:02:34.205 433 433 E bpfloader: --- DO NOT EXPECT SYSTEM TO BOOT SUCCESSFULLY ---
06-17 01:02:38.103 335 335 W LibBpfLoader: Waited 5s for bpf.progs_loaded, still waiting...
06-17 01:02:48.104 335 335 W LibBpfLoader: Waited 10s for bpf.progs_loaded, still waiting...
06-17 01:03:08.104 335 335 W LibBpfLoader: Waited 20s for bpf.progs_loaded, still waiting...
06-17 01:04:12.226 335 335 W LibBpfLoader: Waited 60s for bpf.progs_loaded, still waiting...
06-17 01:04:17.628 1324 1324 W LibBpfLoader: Waited 5s for bpf.progs_loaded, still waiting...
06-17 01:04:27.629 1324 1324 W LibBpfLoader: Waited 10s for bpf.progs_loaded, still waiting...
06-17 01:04:47.629 1324 1324 W LibBpfLoader: Waited 20s for bpf.progs_loaded, still waiting...
06-17 01:05:50.163 1324 1324 W LibBpfLoader: Waited 60s for bpf.progs_loaded, still waiting...
06-17 01:05:55.551 1741 1741 W LibBpfLoader: Waited 5s for bpf.progs_loaded, still waiting...
Bug: 150040815
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I77b82bf44141df8ffab1d11d01a89c3927fbe827
This is useful for critical functions with fallbacks, but
may even be useful for non-critical functions, where a function
in the middle of the file may fail to load, but you still want
other (later) functions to be attempted.
Critical applies to the entire .c file (or to be more correct to
the entire resulting .o). Optional applies to a specific section
of that .o (ie. a specific individual function).
This new optional attribute is necessary to be able to declare
a .c/.o file critical even if *some* of the individual functions
might fail to load due to missing kernel patches.
(Note: we currently have no way to specify a map as optional)
Critical guarantees that all non-optional programs, and all maps,
have been created, pinned, chowned, and chmoded successfully
(or that they already existed).
For an example of use see:
system/netd/bpf_progs/offload.c
(while at it also add retrieveProgram() and mapRetrieve{RW,RO,WO}()
helpers to BpfUtils.h)
Test: builds, atest, see paired netd change for extra details
Bug: 150040815
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I50b292c061b05fc8f4b4b8574f128345c45c78db
Reasoning: critical load failures for netd bpf programs will just result
in unpredictable behaviour later on. For example netd/systemserver
crash loops.
Test: builds
Bug: 150040815
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iefa01e60cd0a9a223e96411726a199bfb4857a5a
... which also means waitForProgsLoaded() has to be a no-op on pre-bpf devices.
This is more consistent: it's weird to have bpf.progs_loaded set on a 4.4 device.
Test: builds, atest
Bug: 150040815
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iddabcf56c187ea518dd2e4d8db451b2f6902aa8e
Fixes:
system/bpf/libbpf_android/include/bpf/BpfMap.h:132:10: warning: operator=() does not handle self-assignment properly [cert-oop54-cpp]
void operator=(const BpfMap<Key, Value>& other) {
^
Matches the self-assignment check from
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-unhandled-self-assignment.html
This isn't needed here, since the code was already correct, but
it does prevent a pointless newfd = dup(fd); close(fd); sequence.
Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia57f95d4ab180783c97db7e6f8d929f822c8958d
Fixes:
system/bpf/libbpf_android/Loader.cpp:557:49: warning: 'find_last_of' called with a string literal consisting of a single character; consider using the more effective overload accepting a character [performance-faster-string-find]
name = name.substr(0, name.find_last_of("$"));
^~~
'$'
Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iea62a59380c155796a7fa2ac4ca3352f9236ba98
