This is a *partial* NOOP revert of:
'bpf: support BPF_F_NO_PREALLOC in bpf_map_def.h'
https://android-review.googlesource.com/c/platform/packages/modules/Connectivity/+/3457780
The comment is simply wrong, the negativeness is hidden
by the map declaration macros and thus never makes it
into the max_entries field of bpf_map_def struct.
A negative value passed to the map creation macros will store
the absolute value in max_entries, and set the BPF_F_NO_PREALLOC
flag in map_flags.
A negative / excessively large max_entries field will (presumably)
fail during map creation due to lack of ram.
Bug: 399549732
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I86951605cb1397c512c484c84e9d67a85b992b07
Maciej Żenczykowskicommited 2025-02-27 14:26:52 -08:00
Make sure _Alignof(unsigned long long) is 4 on i386
and 8 on all other archs.
This should be a no-op, as it should be trivially true on
any 64-bit architectures (aarch64/riscv64/x86-64), and is
also true on 32-bit arm.
btw. currently failing targets if you just == 8 unconditionally
include at least:
cf_gwear_x86-trunk_staging-userdebug:git_main
test_suites_x86_64-trunk_staging:aosp-main
test_suites_x86_64-trunk_staging:git_main
test_suites_x86_64-trunk_staging_coverage:aosp-main
test_suites_x86_64-trunk_staging_coverage:git_main
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2fac89d552232150b167e9f67fe1bd0cf2c129ee
Maciej Żenczykowskicommited 2025-02-10 22:50:45 -08:00
These are convenience macros which do
(const|volatile) cast for atomic operations.
I've run into a case where two 32-bit writes get optimized
by the compiler into a single 64-bit write, which then fails
verification. WRITE_ONCE() avoids that by virtue of the volatile annotation.
Technically I think the same thing could happen on read,
so add READ_ONCE too.
Test: N/A
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iade089aab3522916bd7b431d4064f89a21bc78b0
Maciej Żenczykowskicommited 2025-01-30 14:43:45 -08:00
4.9 and 6.12 are LTS kernels - add them
5.8 is not, and the constant is no longer used - remove it
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1f0d8dd08e331412eaddeaf86b1435f9cf7d15db
Maciej Żenczykowskicommited 2025-01-22 09:26:47 -08:00
automatically enable these messages in test code and in GTS
(which already sets the BPFMAP_VERBOSE_ABORT define)
Bug: 379821131
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I84dc142e7875a80fa18b4783c1d0d39b31b8aaad
Maciej Żenczykowskicommited 2025-01-21 22:12:58 -08:00
5.9 is not LTS, and thus isn't supported.
Let's simplify to 5.10 which is the actual LTS supported version.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I5595abaacb9b479d82787dc021b0e3109a49951d
Maciej Żenczykowskicommited 2025-01-21 15:01:04 -08:00
Neither 5.8 nor 5.9 are LTS, and thus aren't supported.
Let's simplify to 5.10 which is the actual LTS supported version.
Generated via:
sed -i -r 's/KVER_5_8/KVER_5_10/' bpf/progs/offload.c
sed -i -r 's/KVER_5_8/KVER_5_10/' bpf/progs/netd.c
plus manual edit to:
bpf/headers/include/bpf_helpers.h
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2b9563e1a392011718d3f7d788f84201993e58c2
Maciej Żenczykowskicommited 2025-01-21 15:00:53 -08:00
This will allow build time compiling versions of an ebpf program
with sdk level specific behaviour.
The mainline bpfloader already supports loading programs
based on the sdk level, so this builds on that.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I97078c6bdf4cef143cdfeed6ea8e2594bd1f5cd6
Maciej Żenczykowskicommited 2025-01-21 14:21:01 -08:00
This behaviour we depend on continues to be present...
Test: N/A
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I785e908700182734ef7cc21c7c2741c327f7a18b
Maciej Żenczykowskicommited 2025-01-21 12:33:10 -08:00
Kernel requires maps of type BPF_MAP_TYPE_LPM_TRIE to not be
preallocated, so default enable the flag for these.
But even for non LPM_TRIE maps allow a negative num_entries
value to ask for 'non preallocated' maps.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I48d5d5813628c87094c5efa7266b0354b135dd7e
Maciej Żenczykowskicommited 2025-01-20 14:49:44 -08:00
This will allow BPF maps to be created with flag options that are
supported e.g BPF_F_NO_PREALLOC, BPF_F_MMAPABLE and others.
Bug: 387984935
Test: Modified NetBpfLoader to dump the map flags.
Change-Id: Ia13ca5a861e8275e831c2b96f4759d1e8f111963
The kernel updates the length with xchg() which does a memory barrier,
on the kernel side when the data is actually committed to the ring
buffer [1].
On the user space side the volatile is not sufficient to prevent the
data read from being reordered before the load of length.
[1]a20971c187/kernel/bpf/ringbuf.c (L484)
Bug: 374722456
Bug: 368624834
Bug: 376536942
Change-Id: I75eee3deee2afce83c1b760e6df383375f926ebb
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
This helper is available on 5.1+ kernels and required to read certain
fields (like the mark) from skb->sk.
Test: TH
Change-Id: I96087c9974262594fdcb4119cbdbd1b39c26a5d4
6.12 is virtually certain to release in the second half of November:
2024-09-15 - 6.11 release
2024-09-22 - merge window
2024-09-29 - 6.12-rc1
2024-10-06 - 6.12-rc2
2024-10-13 - 6.12-rc3
2024-10-20 - 6.12-rc4
2024-10-27 - 6.12-rc5
2024-11-03 - 6.12-rc6
2024-11-10 - 6.12-rc7 or 6.12
2024-11-16 - 6.12-rc8 or 6.12
2024-11-23 - 6.12-rc9 or 6.12
2024-11-30 - 6.12
This means it *will* be the last Linus kernel of the year.
Hence it is almost certainly going to be the LTS for 2024.
Thus the next Android OS release will drop support for 4.19
and add support for 6.12.
Bug: 370043209
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I53f52a0e65f31d4db5f10f8b1acac18ba6f34d18
Maciej Żenczykowskicommited 2024-09-27 17:12:56 +00:00
(since this map relies on percpu access semantics,
and we don't even have userspace helpers to access PERCPU_ maps)
This will also be used by the upcoming satellite egress limiting logic.
See aosp/3235142
With this change we see:
$ adbz shell ls -lZ /sys/fs/bpf/net_shared/*_dscpPolicy_*
-rw-rw---- 1 root system u:object_r:fs_bpf_net_shared:s0 0 2024-09-04 17:01 /sys/fs/bpf/net_shared/map_dscpPolicy_ipv4_dscp_policies_map
-rw-rw---- 1 root system u:object_r:fs_bpf_net_shared:s0 0 2024-09-04 17:01 /sys/fs/bpf/net_shared/map_dscpPolicy_ipv6_dscp_policies_map
---------- 1 root root u:object_r:fs_bpf_loader:s0 0 2024-09-04 17:01 /sys/fs/bpf/net_shared/map_dscpPolicy_socket_policy_cache_map
-r--r----- 1 root system u:object_r:fs_bpf_net_shared:s0 0 2024-09-04 17:01 /sys/fs/bpf/net_shared/prog_dscpPolicy_schedcls_set_dscp_ether
Test: TreeHugger, atest CtsNetTestCases:android.net.cts.DscpPolicyTest
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I50a12ca4cd5587342f8aaf9df8cb28917f555252
Maciej Żenczykowskicommited 2024-09-04 17:41:47 -07:00
This simplified macro will prevent leaking of mainline specific
bpf implementation details into platform.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id0564f2e8a927ace6dcddb93d78a58891f06795c
Maciej Żenczykowskicommited 2024-09-04 17:39:49 -07:00
(pulled from my notes / in-progress work on non-Android clat implementation)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iae662f542be371c4110205c8c3bef0a416b47566
Maciej Żenczykowskicommited 2024-08-29 21:18:17 +00:00
Generated via:
git mv staticlibs/native/bpf_headers bpf/headers
cd bpf/headers/include
git mv bpf/bpf_helpers.h .
git mv bpf/bpf_map_def.h .
manually fix up bpf/bpf_map_def.h include path
bpf_helpers.h is only used by bpf programs so the 'bpf/'
prefix is spurious.
bpf_map_def.h is only used by bpf programs and the two
bpfloaders, which effectively means the 'bpf/' prefix isn't
useful.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic3fc4e354a15821c27c23b7dbc019daad9f6ad85
Maciej Żenczykowskicommited 2024-08-21 13:18:59 -07:00