-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libbpf: further struct_ops fixes and improvements #6974
Conversation
Upstream branch: 329a672 |
459d932
to
ba083f5
Compare
Upstream branch: 75b0fbf |
3ca0ccd
to
a399416
Compare
ba083f5
to
20150dc
Compare
libbpf ensures that BPF program references set in map->st_ops->progs[i] during open phase are always valid STRUCT_OPS programs. This is done in bpf_object__collect_st_ops_relos(). So there is no need to double-check that in bpf_map__init_kern_struct_ops(). Simplify the code by removing unnecessary check. Also, we avoid using local prog variable to keep code similar to the upcoming fix, which adds similar logic in another part of bpf_map__init_kern_struct_ops(). Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
There is yet another corner case where user can set STRUCT_OPS program reference in STRUCT_OPS map to NULL, but libbpf will fail to disable autoload for such BPF program. This time it's the case of "new" kernel which has type information about callback field, but user explicitly nulled-out program reference from user-space after opening BPF object. Fix, hopefully, the last remaining unhandled case. Fixes: 0737df6 ("libbpf: better fix for handling nulled-out struct_ops program") Fixes: f973fcc ("libbpf: handle nulled-out program in struct_ops correctly") Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add a test which tests the case that was just fixed. Kernel has full type information about callback, but user explicitly nulls out the reference to declaratively set BPF program reference. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
strerror_r(), used from libbpf-specific libbpf_strerror_r() wrapper is documented to return error in two different ways, depending on glibc version. Take that into account when handling strerror_r()'s own errors, which happens when we pass some non-standard (internal) kernel error to it. Before this patch we'd have "ERROR: strerror_r(524)=22", which is quite confusing. Now for the same situation we'll see a bit less visually scary "unknown error (-524)". At least we won't confuse user with irrelevant EINVAL (22). Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Extend libbpf's pre-load checks for BPF programs, detecting more typical conditions that are destinated to cause BPF program failure. This is an opportunity to provide more helpful and actionable error message to users, instead of potentially very confusing BPF verifier log and/or error. In this case, we detect struct_ops BPF program that was not referenced anywhere, but still attempted to be loaded (according to libbpf logic). Suggest that the program might need to be used in some struct_ops variable. User will get a message of the following kind: libbpf: prog 'test_1_forgotten': SEC("struct_ops") program isn't referenced anywhere, did you forget to use it? Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Add a simple test that validates that libbpf will reject isolated struct_ops program early with helpful warning message. Also validate that explicit use of such BPF program through BPF skeleton after BPF object is open won't trigger any warnings. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Upstream branch: 93d1c2d |
Drive-by clean up, we shouldn't use meaningless "test_" prefix for subtest names. Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
a399416
to
cafb352
Compare
20150dc
to
606f72a
Compare
Upstream branch: 7e2c7a3 Pull request is NOT updated. Failed to apply https://patchwork.kernel.org/project/netdevbpf/list/?series=850977
conflict:
|
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=850977 irrelevant now. Closing PR. |
Summary: Upstream git and patchwork can race. A series could have already been merged+pushed while patchwork reports a relevant status (ie. !accepted). Handle the race by checking if a series has already been merged. Here's a prod example of the race: * kernel-patches/bpf#6974 (comment) * P1314577443 * https://patchwork.kernel.org/project/netdevbpf/list/?series=850977&state=* Reviewed By: chantra Differential Revision: D57133263 fbshipit-source-id: 09e42a0709c427b4a8942f267070aeaa7b64aa7a
Pull request for series with
subject: libbpf: further struct_ops fixes and improvements
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=850977