Re: [PATCH bpf-next] selftests/bpf: skip lsm_cgroup when don't have trampolines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/1/22 2:16 AM, Stanislav Fomichev wrote:
On Thu, Jun 30, 2022 at 4:48 PM Hao Luo <haoluo@xxxxxxxxxx> wrote:
On Thu, Jun 30, 2022 at 3:42 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote:
[...]
With arch_prepare_bpf_trampoline removed on x86:

  #98/1    lsm_cgroup/functional:SKIP
  #98      lsm_cgroup:SKIP
  Summary: 1/0 PASSED, 1 SKIPPED, 0 FAILED

Fixes: dca85aac8895 ("selftests/bpf: lsm_cgroup functional test")
Signed-off-by: Stanislav Fomichev <sdf@xxxxxxxxxx>
---
  tools/testing/selftests/bpf/prog_tests/lsm_cgroup.c | 8 ++++++++
  1 file changed, 8 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/lsm_cgroup.c b/tools/testing/selftests/bpf/prog_tests/lsm_cgroup.c
index d40810a742fa..c542d7e80a5b 100644
--- a/tools/testing/selftests/bpf/prog_tests/lsm_cgroup.c
+++ b/tools/testing/selftests/bpf/prog_tests/lsm_cgroup.c
@@ -9,6 +9,10 @@
  #include "cgroup_helpers.h"
  #include "network_helpers.h"

+#ifndef ENOTSUPP
+#define ENOTSUPP 524
+#endif
+
  static struct btf *btf;

  static __u32 query_prog_cnt(int cgroup_fd, const char *attach_func)
@@ -100,6 +104,10 @@ static void test_lsm_cgroup_functional(void)
         ASSERT_EQ(query_prog_cnt(cgroup_fd, "bpf_lsm_sk_alloc_security"), 0, "prog count");
         ASSERT_EQ(query_prog_cnt(cgroup_fd, NULL), 0, "total prog count");
         err = bpf_prog_attach(alloc_prog_fd, cgroup_fd, BPF_LSM_CGROUP, 0);
+       if (err == -ENOTSUPP) {
+               test__skip();
+               goto close_cgroup;
+       }

It seems ENOTSUPP is only used in the kernel. I wonder whether we
should let libbpf map ENOTSUPP to ENOTSUP, which is the errno used in
userspace and has been used in libbpf.

Yeah, this comes up occasionally, I don't think we've agreed on some
kind of general policy about what to do with these :-(
Thanks for the review!

Consensus was that for existing code, the ship has sailed to change it given
applications could one way or another depend on this error code, but it should
be avoided for new APIs (e.g. [0]).

Thanks,
Daniel

  [0] https://lore.kernel.org/bpf/20211209182349.038ac2b8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux