Support associating BPF programs with struct_ops #6359
Closed
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
Author
|
Upstream branch: 63066b7 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
4fcc7e1 to
1aeb398
Compare
Author
|
Upstream branch: c133390 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
c83fd5f to
0d521e5
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
1aeb398 to
f68d848
Compare
Author
|
Upstream branch: ef2c0b2 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
0d521e5 to
37b0e49
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
f68d848 to
3fd24de
Compare
Author
|
Upstream branch: a4d31f4 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
37b0e49 to
f963e98
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
3fd24de to
22f76ea
Compare
Author
|
Upstream branch: 4f7bc83 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
f963e98 to
a25d0ce
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
22f76ea to
d766c2f
Compare
Author
|
Upstream branch: 6cc73f3 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
a25d0ce to
a817c72
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
d766c2f to
86f62c3
Compare
Author
|
Upstream branch: 4722981 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
a817c72 to
cc6d2ac
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
86f62c3 to
c8a7e22
Compare
Author
|
Upstream branch: 7dc211c |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
cc6d2ac to
97980ac
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
c8a7e22 to
c919396
Compare
Author
|
Upstream branch: ec12ab2 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
97980ac to
ec6bd1b
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
c919396 to
73c6b0b
Compare
Author
|
Upstream branch: d6ec090 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
ec6bd1b to
d0e8a8b
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
73c6b0b to
0bdd2b9
Compare
Author
|
Upstream branch: d6ec090 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
d0e8a8b to
deb00dc
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
0bdd2b9 to
729c7ba
Compare
Author
|
Upstream branch: d088da9 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
deb00dc to
3746390
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
729c7ba to
623bab9
Compare
Author
|
Upstream branch: e0940c6 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
3746390 to
f213420
Compare
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
bpf-next_base
branch
from
623bab9 to
fe03c14
Compare
Allow verifier to fixup kfuncs in kernel module to support kfuncs with __prog arguments. Currently, special kfuncs and kfuncs with __prog arguments are kernel kfuncs. Allowing kernel module kfuncs should not affect existing kfunc fixup as kernel module kfuncs have BTF IDs greater than kernel kfuncs' BTF IDs. Signed-off-by: Amery Hung <[email protected]>
Add a new BPF command BPF_PROG_ASSOC_STRUCT_OPS to allow associating a BPF program with a struct_ops map. This command takes a file descriptor of a struct_ops map and a BPF program and set prog->aux->st_ops_assoc to the kdata of the struct_ops map. The command does not accept a struct_ops program nor a non-struct_ops map. Programs of a struct_ops map is automatically associated with the map during map update. If a program is shared between two struct_ops maps, prog->aux->st_ops_assoc will be poisoned to indicate that the associated struct_ops is ambiguous. The pointer, once poisoned, cannot be reset since we have lost track of associated struct_ops. For other program types, the associated struct_ops map, once set, cannot be changed later. This restriction may be lifted in the future if there is a use case. A kernel helper bpf_prog_get_assoc_struct_ops() can be used to retrieve the associated struct_ops pointer. The returned pointer, if not NULL, is guaranteed to be valid and point to a fully updated struct_ops struct. For struct_ops program reused in multiple struct_ops map, the return will be NULL. prog->aux->st_ops_assoc is protected by bumping the refcount for non-struct_ops programs and RCU for struct_ops programs. Since it would be inefficient to track programs associated with a struct_ops map, every non-struct_ops program will bump the refcount of the map to make sure st_ops_assoc stays valid. For a struct_ops program, it is protected by RCU as map_free will wait for an RCU grace period before disassociating the program with the map. The helper must be called in BPF program context or RCU read-side critical section. struct_ops implementers should note that the struct_ops returned may or may not be attached. The struct_ops implementer will be responsible for tracking and checking the state of the associated struct_ops map if the use case requires an attached struct_ops. Signed-off-by: Amery Hung <[email protected]>
Add low-level wrapper and libbpf API for BPF_PROG_ASSOC_STRUCT_OPS command in the bpf() syscall. Signed-off-by: Amery Hung <[email protected]>
Test BPF_PROG_ASSOC_STRUCT_OPS command that associates a BPF program with a struct_ops. The test follows the same logic in commit ba7000f ("selftests/bpf: Test multi_st_ops and calling kfuncs from different programs"), but instead of using map id to identify a specific struct_ops, this test uses the new BPF command to associate a struct_ops with a program. The test consists of two sets of almost identical struct_ops maps and BPF programs associated with the map. Their only difference is the unique value returned by bpf_testmod_multi_st_ops::test_1(). The test first loads the programs and associates them with struct_ops maps. Then, it exercises the BPF programs. They will in turn call kfunc bpf_kfunc_multi_st_ops_test_1_prog_arg() to trigger test_1() of the associated struct_ops map, and then check if the right unique value is returned. Signed-off-by: Amery Hung <[email protected]>
Add a test to make sure implicit struct_ops association does not break backward compatibility nor return incorrect struct_ops. struct_ops programs should still be allowed to be reused in different struct_ops map. The associated struct_ops map set implicitly however will be poisoned. Trying to read it through the helper bpf_prog_get_assoc_struct_ops() should result in a NULL pointer. While recursion of test_1() cannot happen due to the associated struct_ops being ambiguois, explicitly check for it to prevent stack overflow if the test regresses. Signed-off-by: Amery Hung <[email protected]>
Make sure 1) a timer callback can also reference the associated struct_ops, and then make sure 2) the timer callback cannot get a dangled pointer to the struct_ops when the map is freed. The test schedules a timer callback from a struct_ops program since struct_ops programs do not pin the map. It is possible for the timer callback to run after the map is freed. The timer callback calls a kfunc that runs .test_1() of the associated struct_ops, which should return MAP_MAGIC when the map is still alive or -1 when the map is gone. The first subtest added in this patch schedules the timer callback to run immediately, while the map is still alive. The second subtest added schedules the callback to run 500ms after syscall_prog runs and then frees the map right after syscall_prog runs. Both subtests then wait until the callback runs to check the return of the kfunc. Signed-off-by: Amery Hung <[email protected]>
Author
|
Upstream branch: 792f258 |
kernel-patches-daemon-bpf-rc
bot
force-pushed
the
series/1023753=>bpf-next
branch
from
f213420 to
089f8bb
Compare
kernel-patches-daemon-bpf-rc
bot
deleted the
series/1023753=>bpf-next
branch
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.
Pull request for series with
subject: Support associating BPF programs with struct_ops
version: 6
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1023753