Coverity reported a potential underflow of the offset variable used in
the find_cd() function. Switch to using a signed 64 bit integer for the
representation of offset to make sure we can never underflow.
Fixes: 1eebcb60633f ("libbpf: Implement basic zip archive parsing support")
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20230307215504.837321-1-deso@posteo.net
When performing a sync with the kernel repository using the
sync-kernel.sh script, it may be necessary to manually adjust the
library's Makefile if:
- new source files were added upstream
- new public headers were added upstream
This change adds a new section to `SYNC.md` to spell out this need.
Signed-off-by: Daniel Müller <deso@posteo.net>
The l4lb_all/l4lb_noinline_dynptr test no does not run on kernel 5.5.0,
because functionality is missing there. Do not allow running it.
Signed-off-by: Daniel Müller <deso@posteo.net>
The sync script does not seem to be automatically adding newly added
files added to the kernel repo build to the local Makefile. Do that now.
Signed-off-by: Daniel Müller <deso@posteo.net>
This change adds support for attaching uprobes to shared objects located
in APKs, which is relevant for Android systems where various libraries
may reside in APKs. To make that happen, we extend the syntax for the
"binary path" argument to attach to with that supported by various
Android tools:
<archive>!/<binary-in-archive>
For example:
/system/app/test-app/test-app.apk!/lib/arm64-v8a/libc++_shared.so
APKs need to be specified via full path, i.e., we do not attempt to
resolve mere file names by searching system directories.
We cannot currently test this functionality end-to-end in an automated
fashion, because it relies on an Android system being present, but there
is no support for that in CI. I have tested the functionality manually,
by creating a libbpf program containing a uretprobe, attaching it to a
function inside a shared object inside an APK, and verifying the sanity
of the returned values.
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20230301212308.1839139-4-deso@posteo.net
This change splits the elf_find_func_offset() function in two:
elf_find_func_offset(), which now accepts an already opened Elf object
instead of a path to a file that is to be opened, as well as
elf_find_func_offset_from_file(), which opens a binary based on a
path and then invokes elf_find_func_offset() on the Elf object. Having
this split in responsibilities will allow us to call
elf_find_func_offset() from other code paths on Elf objects that did not
necessarily come from a file on disk.
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20230301212308.1839139-3-deso@posteo.net
This change implements support for reading zip archives, including
opening an archive, finding an entry based on its path and name in it,
and closing it.
The code was copied from https://github.com/iovisor/bcc/pull/4440, which
implements similar functionality for bcc. The author confirmed that he
is fine with this usage and the corresponding relicensing. I adjusted it
to adhere to libbpf coding standards.
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Michał Gregorczyk <michalgr@meta.com>
Link: https://lore.kernel.org/bpf/20230301212308.1839139-2-deso@posteo.net
Commit 837664758d ("ci: Allow usage of .patch patches") removed the
ci/diffs/.do_not_use_dot_patch_here marker file. Given that we currently
have no CI patches present and that git does not track (empty)
directories, ci/diffs/ got removed. That's fine functionality-wise, but
it makes for a bit of a discoverability hurdle. Add back a marker file
to keep the directory around.
Signed-off-by: Daniel Müller <deso@posteo.net>
As of https://github.com/libbpf/ci/pull/67 a bunch of actions honor
KBUILD_OUTPUT. Doing so will make it possible to separate source code
from build artifacts, which in turn may allow us to support incremental
kernel compilation in CI down the line.
Irrespective of these future changes, actions pertaining the kernel
build now ask for an additional input defining where to store or expect
build artifacts. Provide it.
Signed-off-by: Daniel Müller <deso@posteo.net>
With https://github.com/libbpf/ci/pull/68 merged we can now keep the
.patch extension for patches and don't have to worry about forgetting
the rename to .diff.
Remove the marker file reminding us of that need.
Signed-off-by: Daniel Müller <deso@posteo.net>
Patch "selftests/bpf: Fix OOB write in test_verifier" has made it to the
bpf branch (after originally landing on bpf-next). Remove it from CI, as
it is no longer necessary.
Signed-off-by: Daniel Müller <deso@posteo.net>
The comment associated with the entry is a bit confusing. It stemmed
from the test being denylisted on bpf, but not bpf-next in the past.
Regardless, by now said change has propagated to both trees, so we no
longer need to carry around this deny list entry here.
Signed-off-by: Daniel Müller <deso@posteo.net>
With https://github.com/libbpf/ci/pull/41 merged we no longer require
the travis-ci symlink in this repository. Remove it. Also, it turns out
we still have a few locations referencing travis-ci/ instead of ci/.
Convert those.
Signed-off-by: Daniel Müller <deso@posteo.net>
Now that we are including the upstream allow/deny lists we can remove
any duplicates from our local lists. While at it, we also add some usdt
tests to the denylist, which are currently failing. This is the same
step we took in the vmtest repository [0].
[0] https://github.com/kernel-patches/vmtest/pull/133
Signed-off-by: Daniel Müller <deso@posteo.net>
Commit 693de729d0 ("Rename blacklists and whitelists") renamed the
black and white lists but missed the adjustment of a comment,
referencing a file name. Update it accordingly.
Signed-off-by: Daniel Müller <deso@posteo.net>
With an upcoming change we would like to invoke bpftool checks from the
run-qemu action (https://github.com/libbpf/ci/pull/37). This action
requires two environment variables, KERNEL and REPO_ROOT, set in order
to function.
Make sure to set them now. Long term we should probably make them
explicit input arguments instead of implicit global state, but there are
many more such instances that we need to clean up.
Signed-off-by: Daniel Müller <deso@posteo.net>
With https://github.com/libbpf/ci/pull/36 merged the run-qemu action now
accepts an additional argument, `kernel-root`.
Provide it to the action with the value appropriate for this repository.
Signed-off-by: Daniel Müller <deso@posteo.net>
Let's make the "kernel-root" explicit when using the prepare-rootfs
action, instead of relying on the default, .kernel.
Signed-off-by: Daniel Müller <deso@posteo.net>
The path to the helpers.sh script to source was put one level too deep
by cfbd763ef8 ("Use foldable helpers where applicable") and the
GITHUB_ACTION_PATH variable is not actually defined in a workflow.
Fix up both issues.
Signed-off-by: Daniel Müller <deso@posteo.net>
As discussed at some earlier point in time, some of the actions/workflow
logic does not use our foldable helpers despite being able to. Switch
them over.
Signed-off-by: Daniel Müller <deso@posteo.net>
This change adjusts the run_selftests.sh script to accept an optional
list of arguments specifying the tests to run. We will make use of it
once we run selftests in parallel.
Signed-off-by: Daniel Müller <deso@posteo.net>
The path to the file system image used by our invocation of Qemu is
currently hard coded to /tmp/root.img somewhere in a different
repository. With
https://github.com/libbpf/ci/commit/da44c0b6ee29ec53776c1303f7ac790b7e337db5
landed we have the option of specifying it explicitly from here. Let's
do just that, so that we can remove the default value from libbpf/ci
altogether.
Signed-off-by: Daniel Müller <deso@posteo.net>
We are no longer using Travis. As such, we should move away from a lot
of CI functionality located in a folder called travis-ci/. This change
renames the travis-ci/ directory to the more generic ci/.
To preserve backwards compatibility until all "consumers" have
transitioned, we add a symbolic link called travis-ci back. It will be
removed in the near term future.
Signed-off-by: Daniel Müller <deso@posteo.net>
We should include the deny and allow lists used somewhere in the output
of our CI runs in order to improve debuggability in general. With this
change we print out these lists once assembled.
Signed-off-by: Daniel Müller <deso@posteo.net>
The run_selftests.sh script defines functions for running individual
tests. However, not all tests are run in all configurations. E.g.,
test_progs is not run on 4.9.0 kernels and test_maps is only run when
testing on the "latest" kernel version. The checks for these conditions,
however, are applied inconsistently: some are in the functions
themselves and others on the call site.
This change unifies all checks to happen within the test function
itself.
Signed-off-by: Daniel Müller <deso@posteo.net>
This change factors out a new function, test_progs_noalu, in the
run_selftests.sh script. Having this function available will make it
easier for us to run tests conditionally later on, but it's also a
matter of having one function for one binary.
Signed-off-by: Daniel Müller <deso@posteo.net>
Back in 2020, we disabled the test_maps selftest with e05f9be4f4
("vmtests: temporarily disable test_maps") for reasons not closely
elaborated.
It appears that by now the test is succeeding again, so let's enable it
back.
Signed-off-by: Daniel Müller <deso@posteo.net>
Both the bpf and bpf-next tree have suitable BPF selftest configurations
available for usage with the latest kernel now upstream. While we do
test on 4.9 and 5.5 kernels as well, there we just download prebuilt
binaries. The configuration we use for building selftests is always the
upstream one.
With this change we remove the checked-in configuration, as it is now no
longer needed.
Signed-off-by: Daniel Müller <deso@posteo.net>
Upstream uses denylist and allowlist terminology instead of blacklist
and whitelist. It also has established a less deeply nested directory
structure.
This change renames the blacklist & whitelist files accordingly and
moves them one level up out of their containing directory to mirror the
layout we have upstream as well as in kernel-patches/vmtest.
Signed-off-by: Daniel Müller <deso@posteo.net>
The current version of actions/checkout is v3. That means that v2, which
we currently use, has been superseded. Update the version we use
accordingly.
Signed-off-by: Daniel Müller <deso@posteo.net>
Development on LLVM 16 has started and version 15 is no longer available
in the repository we install it from. Bump the version we use
accordingly.
Signed-off-by: Daniel Müller <deso@posteo.net>
Commit 708ac5bea0ce ("libbpf: add ksyscall/kretsyscall sections support
for syscall kprobes") added the arch_specific_syscall_pfx() function,
which returns a string representing the architecture in use. As it turns
out this function is currently not aware of Power PC, where NULL is
returned. That's being flagged by the libbpf CI system, which builds for
ppc64le and the compiler sees a NULL pointer being passed in to a %s
format string.
With this change we add representations for two more architectures, for
Power PC and Power PC 64, and also adjust the string format logic to
handle NULL pointers gracefully, in an attempt to prevent similar issues
with other architectures in the future.
Fixes: 708ac5bea0ce ("libbpf: add ksyscall/kretsyscall sections support for syscall kprobes")
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220728222345.3125975-1-deso@posteo.net
This patch adds support for the proposed type match relation to
relo_core where it is shared between userspace and kernel. It plumbs
through both kernel-side and libbpf-side support.
The matching relation is defined as follows (copy from source):
- modifiers and typedefs are stripped (and, hence, effectively ignored)
- generally speaking types need to be of same kind (struct vs. struct, union
vs. union, etc.)
- exceptions are struct/union behind a pointer which could also match a
forward declaration of a struct or union, respectively, and enum vs.
enum64 (see below)
Then, depending on type:
- integers:
- match if size and signedness match
- arrays & pointers:
- target types are recursively matched
- structs & unions:
- local members need to exist in target with the same name
- for each member we recursively check match unless it is already behind a
pointer, in which case we only check matching names and compatible kind
- enums:
- local variants have to have a match in target by symbolic name (but not
numeric value)
- size has to match (but enum may match enum64 and vice versa)
- function pointers:
- number and position of arguments in local type has to match target
- for each argument and the return value we recursively check match
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220628160127.607834-5-deso@posteo.net
In order to provide type match support we require a new type of
relocation which, in turn, requires toolchain support. Recent LLVM/Clang
versions support a new value for the last argument to the
__builtin_preserve_type_info builtin, for example.
With this change we introduce the necessary constants into relevant
header files, mirroring what the compiler may support.
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220628160127.607834-2-deso@posteo.net
The foldable function from the CI helper infrastructure conceptually
support emitting both GitHub and Travis fold markers. However, given
that we no longer run anything on Travis, let's remove its special case,
as it's effectively dead code.
Signed-off-by: Daniel Müller <deso@posteo.net>
We are no longer using Travis. As such, it is confusing to anyone
reading the code to see a function prefixed 'travis_' in GitHub actions
code.
This change renames the travis_fold function to 'foldable', as a first
step towards eliminating such confusing constructs from the repository
where possible.
Signed-off-by: Daniel Müller <deso@posteo.net>
BPF type compatibility checks (bpf_core_types_are_compat()) are
currently duplicated between kernel and user space. That's a historical
artifact more than intentional doing and can lead to subtle bugs where
one implementation is adjusted but another is forgotten.
That happened with the enum64 work, for example, where the libbpf side
was changed (commit 23b2a3a8f63a ("libbpf: Add enum64 relocation
support")) to use the btf_kind_core_compat() helper function but the
kernel side was not (commit 6089fb325cf7 ("bpf: Add btf enum64
support")).
This patch addresses both the duplication issue, by merging both
implementations and moving them into relo_core.c, and fixes the alluded
to kind check (by giving preference to libbpf's already adjusted logic).
For discussion of the topic, please refer to:
https://lore.kernel.org/bpf/CAADnVQKbWR7oarBdewgOBZUPzryhRYvEbkhyPJQHHuxq=0K1gw@mail.gmail.com/T/#mcc99f4a33ad9a322afaf1b9276fb1f0b7add9665
Changelog:
v1 -> v2:
- limited libbpf recursion limit to 32
- changed name to __bpf_core_types_are_compat
- included warning previously present in libbpf version
- merged kernel and user space changes into a single patch
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220623182934.2582827-1-deso@posteo.net
Checking earlier pull requests, to the best of my understanding nothing
is using Travis anymore -- all CI checks are GitHub Actions based.
Further checking the Travis repository [0] the last CI run there was 2
years ago.
Hence, let's remove stale configuration for Travis, as it's seemingly
only bitrotting and causing confusion.
[0]: https://travis-ci.org/github/libbpf/libbpf/builds
Signed-off-by: Daniel Müller <deso@posteo.net>
Daniel Müller