[draft, dont merge] Rebase on old with force resolve#200
Draft
umanwizard wants to merge 30 commits intomainfrom
Draft
[draft, dont merge] Rebase on old with force resolve#200umanwizard wants to merge 30 commits intomainfrom
umanwizard wants to merge 30 commits intomainfrom
Conversation
umanwizard
force-pushed
the
rebase-on-old-with-force-resolve
branch
2 times, most recently
from
02e4488 to
eadf3c6
Compare
umanwizard
force-pushed
the
rebase-on-old-with-force-resolve
branch
3 times, most recently
from
26bc1bf to
684e9cc
Compare
umanwizard
force-pushed
the
rebase-on-old-with-force-resolve
branch
2 times, most recently
from
8e26fd2 to
b6d0115
Compare
fold this into respective commits
type tail call invocations.
Now we have to be consistent with the attach type we use for both the
main program and the tail call. We could just get rid of the multi
attach stuff but we'll eventually want it when we have hundreds of
programs we want to attach all over the place.
This broke with this kernel change:
commit 4540aed51b12bc13364149bf95f6ecef013197c0
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri Sep 26 19:12:00 2025 +0200
bpf: Enforce expected_attach_type for tailcall compatibility
Yinhao et al. recently reported:
Our fuzzer tool discovered an uninitialized pointer issue in the
bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem.
This leads to a NULL pointer dereference when a BPF program attempts to
deference the txq member of struct xdp_buff object.
...
Linux kernel 6.12+ (commit 4540aed51b12) enforces that all programs in a BPF_MAP_TYPE_PROG_ARRAY share the same expected_attach_type. This breaks multi-uprobe attachment because the unwinder programs in kprobe_progs use the default attach type while USDT programs need AttachTraceUprobeMulti. Rather than maintaining separate prog arrays for different attach types, detect this restriction at startup by probing whether the kernel allows inserting programs with different attach types into the same prog array. When the restriction is detected, disable multi-uprobe support and fall back to single-shot USDT attachment. This reverts the loadProbeUnwinders AttachTraceUprobeMulti change from ed5844f which broke off-cpu profiling (finish_task_switch kprobe). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The rootfs and test binary output directories were created in the source tree, leaving root-owned files that break `go generate ./...` with permission denied errors. Use mktemp dirs in /tmp with a trap cleanup on EXIT to ensure they're always removed. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
this commit will need to be broken up into the original commits that need the licenses for upstream
AFAICT this is only used in parca-agent, not sure if we will actually upstream it
time="2025-07-22T14:40:42-04:00" level=warning msg="Failed to decode stackcheck symbol, Go label collection might not work" Issue was two instruction formulation of TLS load.
In Go, [`runtime.morestack`](https://github.com/golang/go/blob/7b60d06739/src/runtime/asm_amd64.s#L680-L680) is called by goroutines that have exhausted their stack space and need to create more. This can be a significant bottleneck in some programs. As can be seen from the above link, the function in question clears the frame pointer before calling into `newstack`, making it impossible for us to unwind further. Luckily, before doing so, it stashes the necessary registers on the current goroutine. This PR introduces a new unwinding command specifically for unwinding past `runtime.morestack`. It uses the infrastructure already developed for Go Custom Labels to find the current goroutine, then grabs the appropriate values. Currently, this only works in Go 1.25 and does not work for kernel stacks; making it more general will be done in a [later follow-up](parca-dev/parca-agent#3124).
…y#728) Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
symbol hash not found is a comon new error, ignore it. also log which loader returned an error
apparently very common.
(some might just need to be reverted in our fork because there's no real justification to land them upstream)
(Why do we have this change? Should we just revert it in our fork?) (Also, even if we DO keep this, we should squash it into whatever commit added util.GCKV)
umanwizard
force-pushed
the
rebase-on-old-with-force-resolve
branch
from
94ce2a5 to
7ed0433
Compare
|
|
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
No description provided.