Trigger CI #10228
Open
Trigger CI #10228
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
jrife
force-pushed
the
jrife/support-tracing-link-update
branch
2 times, most recently
from
d444e26 to
7b54f95
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
b6555d5 to
910d3ce
Compare
jrife
force-pushed
the
jrife/support-tracing-link-update
branch
8 times, most recently
from
c2e6a43 to
61adc71
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
910d3ce to
50dc55d
Compare
jrife
force-pushed
the
jrife/support-tracing-link-update
branch
from
61adc71 to
686dc6e
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
50dc55d to
f882b4c
Compare
jrife
force-pushed
the
jrife/support-tracing-link-update
branch
2 times, most recently
from
d4eea5b to
dea1eec
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
f882b4c to
4752827
Compare
The type and expected_attach_type of the new program must match the original program and the new program must be compatible with the attachment target. Use a global mutex, trace_link_mutex, to synchronize parallel update operations similar to other link types (sock_map, xdp, etc.) that use a global mutex. Contention should be low, so this should be OK. Subsequent patches fill in the program update logic for freplace/fentry/fmod_ret/fexit links. Signed-off-by: Jordan Rife <[email protected]>
Implement program update logic for freplace links. Signed-off-by: Jordan Rife <[email protected]>
Implement program update for other link types supported by bpf_tracing_link_lops (fentry, fexit, fmod_ret, ...). I wanted to make the implementation generic so that no architecture-specific support would be required, but couldn't think of a good way to do this: * I considered updating link.prog before calling bpf_trampoline_update and reverting it back to the old prog if the update fails, but this could create inconsistencies with concurrent operations that read links where they see the uncommitted program associated with the link. * I considered making a deep copy of the link whose program is being updated and putting a pointer to that copy into tlinks when calling bpf_trampoline_get_progs where the copy references the new program instead of the current program. This would avoid updating the original link.prog before the update was committed; however, this seemed slightly hacky and I wasn't sure if this was better than just making the architecture-specific layer aware of the intent to update one of the link programs. This patch sets up the scaffolding for trampoline program updates while subsequent patches enable this for various architectures. For now, only x86, arm64, and s390 are implemented since that's what I could test in CI. Add update_link and update_prog to bpf_tramp_links. When these are set, arch_bpf_trampoline_size() and arch_prepare_bpf_trampoline() use update_prog in place of update_link->link.prog when calculating the trampoline size and constructing a new trampoline image. link.prog is only updated after the trampoline update is successfully committed. If the current architecture does not support program updates (i.e. bpf_trampoline_supports_update_prog() is not implemented) then the BPF_LINK_UPDATE operation will return -ENOTSUPP. Signed-off-by: Jordan Rife <[email protected]>
Use update_prog in place of current link prog when link matches update_link. Signed-off-by: Jordan Rife <[email protected]>
Use update_prog in place of current link prog when link matches update_link. Signed-off-by: Jordan Rife <[email protected]>
Use update_prog in place of current link prog when link matches update_link. Signed-off-by: Jordan Rife <[email protected]>
Exercise a series of edge cases and happy path scenarios across a gamut of link types (fentry, fmod_ret, fexit, freplace) to test BPF_LINK_UPDATE behavior for tracing links. This test swaps fentry/fmod_ret/fexit programs in-place and makes sure that the sequence and attach cookie are as expected based on the link positions. Signed-off-by: Jordan Rife <[email protected]>
jrife
force-pushed
the
jrife/support-tracing-link-update
branch
from
dea1eec to
32491b3
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
4 times, most recently
from
6a32d09 to
b967d93
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.