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
Maciej Żenczykowskicommited 2021-07-05 18:02:16 -07:00
It really turns out that till now we've just been lucky to not have
ever used a 64-bit type.
See also discussion on:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
(and other places on the internet)
Bug: 190519702
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ibe74a6f97bdbba490a7848060d07dc3efcee0e68
Maciej Żenczykowskicommited 2021-07-05 16:56:22 -07:00
We cannot submit this as long as we want current mainline releases
bpf .o objects to be loaded by images with bpfloader v0.0.
Bug: 190519702
Test: atest, TreeHugger - existing bpf programs load
examination of bpfloader logs
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I157458a4f798e455fb563fad569e20bfde5248fd
Maciej Żenczykowskicommited 2021-07-02 01:17:13 -07:00
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
Maciej Żenczykowskicommited 2021-07-02 03:36:49 +00:00
This change enables Async mode ARM MTE in the bpfloader process on compatible
hardware and has no effect otherwise.
Bug: 181603044
Test: atest under system/bpf
Change-Id: I6340055fea1f97fcc781b418e2465a7961ecedf4
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
Maciej Żenczykowskicommited 2021-03-11 19:52:30 -08:00
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
Maciej Żenczykowskicommited 2021-03-05 06:00:59 +00:00
This is due to changing how many bits are assigned to individual fragments,
which was done to support kernel version 4.9.256.
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7f556352beab009cd114e2241f3d7fe6d878a458
Maciej Żenczykowskicommited 2021-03-04 15:47:40 +00:00
This is required for it to be able to create DEVMAP/DEVMAP_HASH maps.
See kernel source code in kernel/bpf/devmap.c:
static struct bpf_map *dev_map_alloc(union bpf_attr *attr) {
...
if (!capable(CAP_NET_ADMIN)) return ERR_PTR(-EPERM);
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4f3012209186ff0e4bde8807b9032de056367132
Maciej Żenczykowskicommited 2021-03-03 03:28:22 +00:00
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
Maciej Żenczykowskicommited 2021-03-02 07:46:32 +00:00
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
Maciej Żenczykowskicommited 2021-02-11 16:05:21 -08:00
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
Maciej Żenczykowskicommited 2021-01-20 05:17:14 +00:00
Maciej Żenczykowski
commited 
Evgenii Stepanov
authored and
Automerger Merge Worker
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Xin Li
commited 
Bob Badour
authored and