ci: Update build.yaml to include Ubuntu 24.04 #179
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
c0d33ngr
force-pushed
the
update-github-workflow
branch
from
65b5f21 to
6432da3
Compare
|
Thanks a lot! The CI fails on Ubuntu 24.04, though. I forgot we needed #152 to be addressed before using Ubuntu 24.04. Once the fix makes it to bpf-next, it will be pulled when we update the mirror. It will need an additional commit in this repo to compensate for the feature detection in the kernel repo, and then we'll be able to merge your change. |
|
Okay. Thank you :) |
qmonnet
force-pushed
the
update-github-workflow
branch
4 times, most recently
from
cf462c6 to
3b812c2
Compare
|
Apologies, I synchronized the repo and the Makefile fix is in, but it seems I'm still missing something on the probing side - so the build workflow on Ubuntu 24.04 still fails. I'll need to look into it more. |
qmonnet
force-pushed
the
update-github-workflow
branch
7 times, most recently
from
fa94535 to
1a88cf7
Compare
|
OK I've got the fix but the |
qmonnet
added a commit
to qmonnet/bpftool
that referenced
this pull request
May 20, 2025
Ubuntu 20.04 runners for GitHub Actions have been retired. Let's remove them from the build matrix, to avoid failures in our CI. We want to add Ubuntu 24.04 instead, but need to finalise libbpf#179 for that. Link: https://github.blog/changelog/2025-01-15-github-actions-ubuntu-20-runner-image-brownout-dates-and-other-breaking-changes/ Signed-off-by: Quentin Monnet <qmo@kernel.org>
qmonnet
added a commit
that referenced
this pull request
May 20, 2025
Ubuntu 20.04 runners for GitHub Actions have been retired. Let's remove them from the build matrix, to avoid failures in our CI. We want to add Ubuntu 24.04 instead, but need to finalise #179 for that. Link: https://github.blog/changelog/2025-01-15-github-actions-ubuntu-20-runner-image-brownout-dates-and-other-breaking-changes/ Signed-off-by: Quentin Monnet <qmo@kernel.org>
Signed-off-by: Jeffrey <jeffwhewhetu@gmail.com> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
The Ubuntu 20.04-based runners have been deprecated by GitHub at the beginning of this month, and are expected to go fully unsupported by 2025-04-01. Let's remove it from the workflow file. Link: actions/runner-images#11101 Signed-off-by: Quentin Monnet <qmo@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Add the probe to test whether we need to link against the zstd library to use libelf in bpftool. This should ideally have been merged before commit 67f1758 ("bpftool: Link zstd lib required by libelf"), where we have the Makefile use the actual feature, but I forgot to add the probe when synchronising the repository. Elfutils commit a5b07cdf9c49 adds support for ZSTD compression, first shipped with elfutils 0.189. Distros now have it; for example, Ubuntu 22.04 ships version 0.186 (or 0.188 in backports), but Ubuntu 24.04 has 0.189 or 0.190 depending on the arch. Link: https://sourceware.org/git/?p=elfutils.git;a=commit;h=a5b07cdf9c491fb7a4a16598c482c68b718f59b9 Signed-off-by: Quentin Monnet <qmo@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Signed-off-by: Quentin Monnet <qmo@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Use Ubuntu 24.04 instead of 22.04 (when we use a single version, not for the build test Matrix where we want to test both), except for the job where we package the release (where we're not really tied to a specific version and can just go with ubuntu-latest). Signed-off-by: Quentin Monnet <qmo@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
A follow-up commit will remove the assignation to $(Q) in bpftool's main
Makefile, to reflect changes in the kernel repository where the
definition of that variable has been moved to
tools/scripts/Makefile.include, from where it is shared by various
utilities. To preserve the verbose behaviour during the build, when
users pass V=1 to the make invocation, we need a definition for the $(Q)
"quiet" variable in our own Makefile.include. Let's add it.
See Linux commit 293f324ce96d ("tools: Unify top-level quiet
infrastructure")
Signed-off-by: Quentin Monnet <qmo@kernel.org>
Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Pull latest libbpf from mirror. Libbpf version: 1.6.0 Libbpf commit: 4659eaafa4809150c9d1794455224af37252f6dd Signed-off-by: Quentin Monnet <qmo@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Q is exported from Makefile.include so it is not necessary to manually set it. Reviewed-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Acked-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Quentin Monnet <qmo@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Benjamin Tissoires <bentiss@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Eduard Zingerman <eddyz87@gmail.com> Cc: Hao Luo <haoluo@google.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: John Fastabend <john.fastabend@gmail.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: KP Singh <kpsingh@kernel.org> Cc: Lukasz Luba <lukasz.luba@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Martin KaFai Lau <martin.lau@linux.dev> Cc: Mykola Lysenko <mykolal@fb.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Song Liu <song@kernel.org> Cc: Stanislav Fomichev <sdf@google.com> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Yonghong Song <yonghong.song@linux.dev> Cc: Zhang Rui <rui.zhang@intel.com> Link: https://lore.kernel.org/r/20250213-quiet_tools-v3-2-07de4482a581@rivosinc.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
"int" was misspelled as "init" the code comments in the bits.h and const.h files. Fix the typo. CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
The new SK_BPF_CB_FLAGS and new SK_BPF_CB_TX_TIMESTAMPING are added to bpf_get/setsockopt. The later patches will implement the BPF networking timestamping. The BPF program will use bpf_setsockopt(SK_BPF_CB_FLAGS, SK_BPF_CB_TX_TIMESTAMPING) to enable the BPF networking timestamping on a socket. Signed-off-by: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250220072940.99994-2-kerneljasonxing@gmail.com Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Support SCM_TSTAMP_SCHED case for bpf timestamping. Add a new sock_ops callback, BPF_SOCK_OPS_TSTAMP_SCHED_CB. This callback will occur at the same timestamping point as the user space's SCM_TSTAMP_SCHED. The BPF program can use it to get the same SCM_TSTAMP_SCHED timestamp without modifying the user-space application. A new SKBTX_BPF flag is added to mark skb_shinfo(skb)->tx_flags, ensuring that the new BPF timestamping and the current user space's SO_TIMESTAMPING do not interfere with each other. Signed-off-by: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250220072940.99994-7-kerneljasonxing@gmail.com Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Support sw SCM_TSTAMP_SND case for bpf timestamping. Add a new sock_ops callback, BPF_SOCK_OPS_TSTAMP_SND_SW_CB. This callback will occur at the same timestamping point as the user space's software SCM_TSTAMP_SND. The BPF program can use it to get the same SCM_TSTAMP_SND timestamp without modifying the user-space application. Based on this patch, BPF program will get the software timestamp when the driver is ready to send the skb. In the sebsequent patch, the hardware timestamp will be supported. Signed-off-by: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250220072940.99994-8-kerneljasonxing@gmail.com Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Support hw SCM_TSTAMP_SND case for bpf timestamping. Add a new sock_ops callback, BPF_SOCK_OPS_TSTAMP_SND_HW_CB. This callback will occur at the same timestamping point as the user space's hardware SCM_TSTAMP_SND. The BPF program can use it to get the same SCM_TSTAMP_SND timestamp without modifying the user-space application. To avoid increasing the code complexity, replace SKBTX_HW_TSTAMP with SKBTX_HW_TSTAMP_NOBPF instead of changing numerous callers from driver side using SKBTX_HW_TSTAMP. The new definition of SKBTX_HW_TSTAMP means the combination tests of socket timestamping and bpf timestamping. After this patch, drivers can work under the bpf timestamping. Considering some drivers don't assign the skb with hardware timestamp, this patch does the assignment and then BPF program can acquire the hwstamp from skb directly. Signed-off-by: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250220072940.99994-9-kerneljasonxing@gmail.com Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Support the ACK case for bpf timestamping. Add a new sock_ops callback, BPF_SOCK_OPS_TSTAMP_ACK_CB. This callback will occur at the same timestamping point as the user space's SCM_TSTAMP_ACK. The BPF program can use it to get the same SCM_TSTAMP_ACK timestamp without modifying the user-space application. This patch extends txstamp_ack to two bits: 1 stands for SO_TIMESTAMPING mode, 2 bpf extension. Signed-off-by: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250220072940.99994-10-kerneljasonxing@gmail.com Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
This patch introduces a new callback in tcp_tx_timestamp() to correlate tcp_sendmsg timestamp with timestamps from other tx timestamping callbacks (e.g., SND/SW/ACK). Without this patch, BPF program wouldn't know which timestamps belong to which flow because of no socket lock protection. This new callback is inserted in tcp_tx_timestamp() to address this issue because tcp_tx_timestamp() still owns the same socket lock with tcp_sendmsg_locked() in the meanwhile tcp_tx_timestamp() initializes the timestamping related fields for the skb, especially tskey. The tskey is the bridge to do the correlation. For TCP, BPF program hooks the beginning of tcp_sendmsg_locked() and then stores the sendmsg timestamp at the bpf_sk_storage, correlating this timestamp with its tskey that are later used in other sending timestamping callbacks. Signed-off-by: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250220072940.99994-11-kerneljasonxing@gmail.com Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Currently for bpf progs in a cgroup hierarchy, the effective prog array
is computed from bottom cgroup to upper cgroups (post-ordering). For
example, the following cgroup hierarchy
root cgroup: p1, p2
subcgroup: p3, p4
have BPF_F_ALLOW_MULTI for both cgroup levels.
The effective cgroup array ordering looks like
p3 p4 p1 p2
and at run time, progs will execute based on that order.
But in some cases, it is desirable to have root prog executes earlier than
children progs (pre-ordering). For example,
- prog p1 intends to collect original pkt dest addresses.
- prog p3 will modify original pkt dest addresses to a proxy address for
security reason.
The end result is that prog p1 gets proxy address which is not what it
wants. Putting p1 to every child cgroup is not desirable either as it
will duplicate itself in many child cgroups. And this is exactly a use case
we are encountering in Meta.
To fix this issue, let us introduce a flag BPF_F_PREORDER. If the flag
is specified at attachment time, the prog has higher priority and the
ordering with that flag will be from top to bottom (pre-ordering).
For example, in the above example,
root cgroup: p1, p2
subcgroup: p3, p4
Let us say p2 and p4 are marked with BPF_F_PREORDER. The final
effective array ordering will be
p2 p4 p3 p1
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20250224230116.283071-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Introduce BPF instructions with load-acquire and store-release
semantics, as discussed in [1]. Define 2 new flags:
#define BPF_LOAD_ACQ 0x100
#define BPF_STORE_REL 0x110
A "load-acquire" is a BPF_STX | BPF_ATOMIC instruction with the 'imm'
field set to BPF_LOAD_ACQ (0x100).
Similarly, a "store-release" is a BPF_STX | BPF_ATOMIC instruction with
the 'imm' field set to BPF_STORE_REL (0x110).
Unlike existing atomic read-modify-write operations that only support
BPF_W (32-bit) and BPF_DW (64-bit) size modifiers, load-acquires and
store-releases also support BPF_B (8-bit) and BPF_H (16-bit). As an
exception, however, 64-bit load-acquires/store-releases are not
supported on 32-bit architectures (to fix a build error reported by the
kernel test robot).
An 8- or 16-bit load-acquire zero-extends the value before writing it to
a 32-bit register, just like ARM64 instruction LDARH and friends.
Similar to existing atomic read-modify-write operations, misaligned
load-acquires/store-releases are not allowed (even if
BPF_F_ANY_ALIGNMENT is set).
As an example, consider the following 64-bit load-acquire BPF
instruction (assuming little-endian):
db 10 00 00 00 01 00 00 r0 = load_acquire((u64 *)(r1 + 0x0))
opcode (0xdb): BPF_ATOMIC | BPF_DW | BPF_STX
imm (0x00000100): BPF_LOAD_ACQ
Similarly, a 16-bit BPF store-release:
cb 21 00 00 10 01 00 00 store_release((u16 *)(r1 + 0x0), w2)
opcode (0xcb): BPF_ATOMIC | BPF_H | BPF_STX
imm (0x00000110): BPF_STORE_REL
In arch/{arm64,s390,x86}/net/bpf_jit_comp.c, have
bpf_jit_supports_insn(..., /*in_arena=*/true) return false for the new
instructions, until the corresponding JIT compiler supports them in
arena.
[1] https://lore.kernel.org/all/20240729183246.4110549-1-yepeilin@google.com/
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: kernel test robot <lkp@intel.com>
Signed-off-by: Peilin Ye <yepeilin@google.com>
Link: https://lore.kernel.org/r/a217f46f0e445fbd573a1a024be5c6bf1d5fe716.1741049567.git.yepeilin@google.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
We are missing setting error code in do_loader() when bpf_object__open_file() fails. This means the command's exit status code will be successful, even though the operation failed. So make sure to return the correct error code. To maintain consistency with other locations where bpf_object__open_file() is called, return -1. [0] Closes: libbpf#156 Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Sewon Nam <swnam0729@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Tested-by: Quentin Monnet <qmo@kernel.org> Reviewed-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/bpf/d3b5b4b4-19bb-4619-b4dd-86c958c4a367@stanley.mountain/t/#u Link: https://lore.kernel.org/bpf/20250311031238.14865-1-swnam0729@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Currently BPF_BTF_GET_FD_BY_ID requires CAP_SYS_ADMIN, which does not allow running it from user namespace. This creates a problem when freplace program running from user namespace needs to query target program BTF. This patch relaxes capable check from CAP_SYS_ADMIN to CAP_BPF and adds support for BPF token that can be passed in attributes to syscall. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250317174039.161275-2-mykyta.yatsenko5@gmail.com Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
This commit adds the -Wformat-signedness compiler flag to detect and prevent printf format errors, where signed or unsigned types are mismatched with format specifiers. This helps to catch potential issues at compile-time, ensuring that our code is more robust and reliable. With this flag, the compiler will now warn about incorrect format strings, such as using %d with unsigned types or %u with signed types. Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250311112809.81901-2-jiayuan.chen@linux.dev Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Fixed some formatting specifiers errors, such as using %d for int and %u for unsigned int, as well as other byte-length types. Perform type cast using the type derived from the data type itself, for example, if it's originally an int, it will be cast to unsigned int if forced to unsigned. Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250311112809.81901-3-jiayuan.chen@linux.dev Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Syncing latest bpftool commits from kernel repository. Baseline bpf-next commit: 239860828f8660e2be487e2fbdae2640cce3fd67 Checkpoint bpf-next commit: 25601e85441dd91cf7973b002f27af4c5b8691ea Baseline bpf commit: 319fc77f8f45a1b3dba15b0cc1a869778fd222f7 Checkpoint bpf commit: 0c2623cef4f49e1ef6a908a389eea86130d11057 Charlie Jenkins (1): tools: Remove redundant quiet setup Jason Xing (6): bpf: Add networking timestamping support to bpf_get/setsockopt() bpf: Add BPF_SOCK_OPS_TSTAMP_SCHED_CB callback bpf: Add BPF_SOCK_OPS_TSTAMP_SND_SW_CB callback bpf: Add BPF_SOCK_OPS_TSTAMP_SND_HW_CB callback bpf: Add BPF_SOCK_OPS_TSTAMP_ACK_CB callback bpf: Add BPF_SOCK_OPS_TSTAMP_SENDMSG_CB callback Jiayuan Chen (2): bpftool: Add -Wformat-signedness flag to detect format errors bpftool: Using the right format specifiers Mykyta Yatsenko (1): bpf: BPF token support for BPF_BTF_GET_FD_BY_ID Peilin Ye (1): bpf: Introduce load-acquire and store-release instructions Sewon Nam (1): bpf: bpftool: Setting error code in do_loader() Vincent Mailhol (1): treewide: fix typo 'unsigned __init128' -> 'unsigned __int128' Yonghong Song (1): bpf: Allow pre-ordering for bpf cgroup progs docs/Makefile | 6 ------ include/uapi/linux/bpf.h | 35 +++++++++++++++++++++++++++++++++++ include/uapi/linux/const.h | 2 +- src/Makefile | 13 ++++++------- src/btf.c | 14 +++++++------- src/btf_dumper.c | 2 +- src/cgroup.c | 2 +- src/common.c | 4 ++-- src/jit_disasm.c | 3 ++- src/kernel/bpf/disasm.c | 16 ++++++++++++++-- src/map_perf_ring.c | 6 +++--- src/net.c | 4 ++-- src/netlink_dumper.c | 6 +++--- src/prog.c | 13 +++++++------ src/tracelog.c | 2 +- src/xlated_dumper.c | 6 +++--- 16 files changed, 88 insertions(+), 46 deletions(-) Signed-off-by: Quentin Monnet <qmo@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
A recent patch has touched some portions of bpftool's Makefile that differ between kernel's and mirror's sources. Let's update the diff with the expected differences accordingly, to smoothen future sync ups. Signed-off-by: Quentin Monnet <qmo@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Pull latest libbpf from mirror. Libbpf version: 1.6.0 Libbpf commit: 02bdeb7a2c2e7cb2c9cecb125527a9c5a6bbf139 Signed-off-by: Quentin Monnet <qmo@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
The map_fd field of the bpf_attr union is used in the BPF_MAP_FREEZE syscall. Explicitly mention this in the comments. Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250331203618.1973691-2-a.s.protopopov@gmail.com Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
BPF_F_RECOMPUTE_CSUM doesn't update the actual L3 and L4 checksums in the packet, but simply updates skb->csum (according to skb->ip_summed). This patch clarifies that to avoid confusions. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/ff6895d42936f03dbb82334d8bcfd50e00c79086.1744102490.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
In the bpf_l4_csum_replace helper, the BPF_F_PSEUDO_HDR flag should only be set if the modified header field is part of the pseudo-header. If you modify for example the UDP ports and pass BPF_F_PSEUDO_HDR, inet_proto_csum_replace4 will update skb->csum even though it shouldn't (the port and the UDP checksum updates null each other). Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/5126ef84ba75425b689482cbc98bffe75e5d8ab0.1744102490.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
…l sources
To pick up the changes in:
c53e14f1ea4a8f8d perf: Extend per event callchain limit to branch stack
Addressing this perf tools build warning:
Warning: Kernel ABI header differences:
diff -u tools/include/uapi/linux/perf_event.h include/uapi/linux/perf_event.h
Please see tools/include/uapi/README for further details.
Acked-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Link: https://lore.kernel.org/r/20250410001125.391820-4-namhyung@kernel.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
If cgroup_has_attached_progs queries an attach type not supported
by the running kernel, due to the kernel being older than the bpftool
build, it would encounter an -EINVAL from BPF_PROG_QUERY syscall.
Prior to commit 98b303c9bf05 ("bpftool: Query only cgroup-related
attach types"), this EINVAL would be ignored by the function, allowing
the function to only consider supported attach types. The commit
changed so that, instead of querying all attach types, only attach
types from the array `cgroup_attach_types` is queried. The assumption
is that because these are only cgroup attach types, they should all
be supported. Unfortunately this assumption may be false when the
kernel is older than the bpftool build, where the attach types queried
by bpftool is not yet implemented in the kernel. This would result in
errors such as:
$ bpftool cgroup tree
CgroupPath
ID AttachType AttachFlags Name
Error: can't query bpf programs attached to /sys/fs/cgroup: Invalid argument
This patch restores the logic of ignoring EINVAL from prior to that patch.
Fixes: 98b303c9bf05 ("bpftool: Query only cgroup-related attach types")
Reported-by: Sagarika Sharma <sharmasagarika@google.com>
Reported-by: Minh-Anh Nguyen <minhanhdn@google.com>
Signed-off-by: YiFei Zhu <zhuyifei@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Quentin Monnet <qmo@kernel.org>
Link: https://lore.kernel.org/bpf/20250428211536.1651456-1-zhuyifei@google.com
Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
The netkit program is not a cgroup bpf program and should not be shown
in the output of the "bpftool cgroup show" command.
However, if the netkit device happens to have ifindex 3,
the "bpftool cgroup show" command will output the netkit
bpf program as well:
> ip -d link show dev nk1
3: nk1@if2: ...
link/ether ...
netkit mode ...
> bpftool net show
tc:
nk1(3) netkit/peer tw_ns_nk2phy prog_id 469447
> bpftool cgroup show /sys/fs/cgroup/...
ID AttachType AttachFlags Name
... ... ...
469447 netkit_peer tw_ns_nk2phy
The reason is that the target_fd (which is the cgroup_fd here) and
the target_ifindex are in a union in the uapi/linux/bpf.h. The bpftool
iterates all values in "enum bpf_attach_type" which includes
non cgroup attach types like netkit. The cgroup_fd is usually 3 here,
so the bug is triggered when the netkit ifindex just happens
to be 3 as well.
The bpftool's cgroup.c already has a list of cgroup-only attach type
defined in "cgroup_attach_types[]". This patch fixes it by iterating
over "cgroup_attach_types[]" instead of "__MAX_BPF_ATTACH_TYPE".
Cc: Quentin Monnet <qmo@kernel.org>
Reported-by: Takshak Chahande <ctakshak@meta.com>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <qmo@kernel.org>
Link: https://lore.kernel.org/r/20250507203232.1420762-1-martin.lau@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Adding support to retrieve ref_ctr_offset for uprobe perf link, which got somehow omitted from the initial uprobe link info changes. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Yafang Shao <laoar.shao@gmail.com> Link: https://lore.kernel.org/bpf/20250509153539.779599-2-jolsa@kernel.org Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Adding support to display ref_ctr_offset in link output, like:
# bpftool link
...
42: perf_event prog 174
uprobe /proc/self/exe+0x102f13 cookie 3735928559 ref_ctr_offset 0x303a3fa
bpf_cookie 3735928559
pids test_progs(1820)
# bpftool link -j | jq
[
...
{
"id": 42,
...
"ref_ctr_offset": 50500538,
}
]
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20250509153539.779599-4-jolsa@kernel.org
Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Syncing latest bpftool commits from kernel repository.
Baseline bpf-next commit: 25601e85441dd91cf7973b002f27af4c5b8691ea
Checkpoint bpf-next commit: 9325d53fe9adff354b6a93fda5f38c165947da0f
Baseline bpf commit: 0c2623cef4f49e1ef6a908a389eea86130d11057
Checkpoint bpf commit: b4432656b36e5cc1d50a1f2dc15357543add530e
Anton Protopopov (1):
bpf: Fix a comment describing bpf_attr
Jiri Olsa (2):
bpf: Add support to retrieve ref_ctr_offset for uprobe perf link
bpftool: Display ref_ctr_offset for uprobe link info
Martin KaFai Lau (1):
bpftool: Fix cgroup command to only show cgroup bpf programs
Namhyung Kim (1):
tools headers: Update the uapi/linux/perf_event.h copy with the kernel
sources
Paul Chaignon (2):
bpf: Clarify role of BPF_F_RECOMPUTE_CSUM
bpf: Clarify the meaning of BPF_F_PSEUDO_HDR
YiFei Zhu (1):
bpftool: Fix regression of "bpftool cgroup tree" EINVAL on older
kernels
include/uapi/linux/bpf.h | 19 ++++++++++++-------
include/uapi/linux/perf_event.h | 2 ++
src/cgroup.c | 14 +++++++-------
src/link.c | 3 +++
4 files changed, 24 insertions(+), 14 deletions(-)
Signed-off-by: Quentin Monnet <qmo@kernel.org>
Signed-off-by: c0d33ngr <jeffwhewhetu@gmail.com>
Ubuntu 20.04 runners for GitHub Actions have been retired. Let's remove them from the build matrix, to avoid failures in our CI. We want to add Ubuntu 24.04 instead, but need to finalise libbpf#179 for that. Link: https://github.blog/changelog/2025-01-15-github-actions-ubuntu-20-runner-image-brownout-dates-and-other-breaking-changes/ Signed-off-by: Quentin Monnet <qmo@kernel.org>
c0d33ngr
force-pushed
the
update-github-workflow
branch
from
8435b1a to
d3e609a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR to close #177