| Summary: | sys-apps/systemd-256.6 fails with bpf useflag enabled | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Shaumyadeep Chaudhuri <shaumya> |
| Component: | Current packages | Assignee: | Gentoo systemd Team <systemd> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | holger, plevine457, shaumya |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=941185 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
Kernel config |
||
|
Description
Shaumyadeep Chaudhuri
2024-10-07 13:34:10 UTC
Using libbpf-1.4.5 (https://forums.gentoo.org/viewtopic-p-8842383.html#8842383): FAILED: src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.unstripped.o /usr/bin/bpf-unknown-none-gcc -std=gnu11 -fno-stack-protector -fno-ssa-phiopt -O2 -mcpu=v3 -mco-re -gbtf -c -D__x86_64__ -mlittle-endian -I. -isystem /usr/include/x86_64-pc-linux-gnu -idirafter /usr/include ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c -o src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.unstripped.o -I/var/tmp/portage/sys-apps/systemd-256.6/work/systemd-256.6-abi_x86_64.amd64 ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c: In function 'validate_inode_on_mount': ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c:81: error: assignment to 'struct user_namespace *' from incompatible pointer type 'struct user_namespace___9 *' [-Wincompatible-pointer-types] 81 | mount_userns = m->mnt_ns->user_ns; ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c:85: error: assignment to 'struct user_namespace *' from incompatible pointer type 'struct user_namespace___162 *' [-Wincompatible-pointer-types] 85 | task_userns = task->cred->user_ns; ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c: In function 'validate_path': ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c:127: error: assignment to 'struct inode *' from incompatible pointer type 'struct inode___16 *' [-Wincompatible-pointer-types] 127 | inode = path->dentry->d_inode; The code is kind of new: https://github.com/systemd/systemd/commit/7a5edb07956841492b23a8a39a36f9286efd51ef#diff-0498e3d4fdb1b5cd3eb9e1ed388f125eb8275e339a0f8595654c0da70e783930R66 (in 256). In the build directory (/var/tmp/portage/sys-apps/systemd-256.6/work/systemd-256.6-abi_x86_64.amd64), can you run: /usr/bin/bpf-unknown-none-gcc -std=gnu11 -fno-stack-protector -fno-ssa-phiopt -O2 -mcpu=v3 -mco-re -gbtf -c -D__x86_64__ -mlittle-endian -I. -isystem /usr/include/x86_64-pc-linux-gnu -idirafter /usr/include ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c -o src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.unstripped.o -I/var/tmp/portage/sys-apps/systemd-256.6/work/systemd-256.6-abi_x86_64.amd64 -save-temps and then upload ./src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.unstripped.i Thanks. I can't yet reproduce it. Couldn't upload here, since it's too big so here's the link - https://file.io/ABdhwM2gjr72 But also got the following errors trying to generate the file ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c: In function 'validate_inode_on_mount': ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c:81: error: assignment to 'struct user_namespace *' from incompatible pointer type 'struct user_namespace___9 *' [-Wincompatible-pointer-types] 81 | mount_userns = m->mnt_ns->user_ns; ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c:85: error: assignment to 'struct user_namespace *' from incompatible pointer type 'struct user_namespace___162 *' [-Wincompatible-pointer-types] 85 | task_userns = task->cred->user_ns; ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c: In function 'validate_path': ../systemd-256.6/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c:127: error: assignment to 'struct inode *' from incompatible pointer type 'struct inode___16 *' [-Wincompatible-pointer-types] 127 | inode = path->dentry->d_inode; That link doesn't work for me ("The transfer you requested has been deleted.") -- can you upload it compressed here?
Sorry, tried uploading compressed and too big. Here's a dropbox link - https://www.dropbox.com/scl/fi/qhjjh3z82crwqque0q6p4/userns-restrict.bpf.unstripped.i.zst?rlkey=v1kqgnxnxtflfu3bm33kfp4nl&st=rxbig6b7&dl=0 Hopefully this time it works Thanks, got it. Ours are surprisingly different! For example (RHS is mine)... ``` -typedef int fs_param_type___25(struct p_log *, const struct fs_parameter_spec *, struct fs_parameter___6 *, struct fs_parse_result *); +typedef void (*btf_trace_xfs_buf_submit)(void *, struct xfs_buf *, long unsigned int); ``` I wonder what happens if you rebuild bpftool? (Maybe try with your normal flags, then if systemd fails still, try the basic ones)? The difference wrt. the function prototypes makes me think that maybe the kernel BTF is missing or broken? Would it depend on the running kernel? I was under the impression that the `linux-headers` were the only requirement to compile. I can upload my kernel config if that's helpful At runtime, bpftool (which is used while building systemd) needs access to BPF from the running kernel. Yes, please upload the current kernel config, thanks Created attachment 905106 [details] Kernel config Added the kernel config, also compiled bpftool with the base flags and tried again the last step, here's the output - https://www.dropbox.com/scl/fi/x08qj62xkzu91iogkc0py/base-flags-userns-restrict.bpf.unstripped.i.zst?rlkey=3fiixi2x3bxw6v4g6ansqinh2&st=9ug0brzo&dl=0 (In reply to Shaumyadeep Chaudhuri from comment #11) > Created attachment 905106 [details] > Kernel config CONFIG_DEBUG_INFO_BTF=y so that's good...or not, since it should work. :/ Really no idea why the symbols are botched. Would the compile also depend on `DWARF` info? If it makes any difference, the pahole version i have is dev-util/pahole-1.27-r1::gentoo (In reply to Shaumyadeep Chaudhuri from comment #13) > Would the compile also depend on `DWARF` info? I see you do not have CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT set, but instead only CONFIG_DEBUG_INFO_DWARF5. I don't know if that could be the reason, maybe Sam can share his config. Unfortunately I cannot really help reproduce this either since I only have split-usr systems and the systemd ebuild refuses to build - sorry. > If it makes any difference, the pahole version i have is > dev-util/pahole-1.27-r1::gentoo That's OK and should work. So I tried with `gentoo-kernel-bin` and was able to successfully compile, so it's definitely related to the kernel. Could it be the kernel config or could it be becasue i'm compiling the kernel with gcc-14? I edited the ebuild to pass -Dbpf-compiler=clang instead of -Dbpf-compiler=gcc and rebuilt with clang as the active toolchain. It installed fine, though it emitted the QA warning > ../systemd-256.7/src/nsresourced/bpf/userns_restrict/userns-restrict.bpf.c:81:22: warning: > incompatible pointer types assigning to 'struct user_namespace *' from > 'struct user_namespace___44 *' [-Wincompatible-pointer-types]" So clang treats it as a warning while gcc treats it as an error. Furthermore, according to https://nakryiko.com/posts/bpf-core-reference-guide/#handling-incompatible-field-and-type-changes > For any type, field, enum, or enumerator, if the entity's name contains > a suffix of the form ___something (three underscores plus some text after > it), such name suffix is ignored for the purposes of CO-RE relocation as > if it was never there. > > This means that if you were to define a struct task_struct___my_own_copy and > use it in your BPF application, as far as BPF CO-RE is concerned, that struct > is equivalent to the kernel struct task_struct and will be matched and > relocated accordingly. Though I haven't tested it, this seems to imply that such a conversion is benign. (In reply to Peter Levine from comment #16) > So clang treats it as a warning while gcc treats it as an error. > Clang intends to promote it to an error: https://github.com/llvm/llvm-project/issues/74605. |
