> From: Daniel Müller [mailto:deso@xxxxxxxxxx] > Sent: Friday, August 12, 2022 1:52 AM > On Thu, Aug 11, 2022 at 12:02:57PM +0000, Roberto Sassu wrote: > > > From: Roberto Sassu [mailto:roberto.sassu@xxxxxxxxxx] > > > Sent: Thursday, August 11, 2022 9:47 AM > > > > From: Alexei Starovoitov [mailto:alexei.starovoitov@xxxxxxxxx] > > > > Sent: Wednesday, August 10, 2022 11:34 PM > > > > On Wed, Aug 10, 2022 at 06:59:28PM +0200, Roberto Sassu wrote: > > > > > + > > > > > +static int __init bpf_key_sig_kfuncs_init(void) > > > > > +{ > > > > > + int ret; > > > > > + > > > > > + ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, > > > > > + &bpf_key_sig_kfunc_set); > > > > > + if (!ret) > > > > > + return 0; > > > > > + > > > > > + return register_btf_kfunc_id_set(BPF_PROG_TYPE_LSM, > > > > > + &bpf_key_sig_kfunc_set); > > > > > > > > Isn't this a watery water ? > > > > Don't you have a patch 1 ? > > > > What am I missing ? > > > > > > Uhm, yes. I had doubts too. That was what also KP did. > > > > > > It makes sense to register once, since we mapped LSM to > > > TRACING. > > > > > > Will resend only this patch. And I will figure out why CI failed. > > > > Adding in CC Daniel Müller, which worked on this. > > > > I think the issue is that some kernel options are set to =m. > > This causes the CI to miss all kernel modules, since they are > > not copied to the virtual machine that executes the tests. > > > > I'm testing this patch: > > > > https://github.com/robertosassu/libbpf- > ci/commit/b665e001b58c4ddb792a2a68098ea5dc6936b15c > > I commented on the pull request. Would it make sense to adjust the > kernel configuration in this repository instead? I am worried that > otherwise everybody may need a similar work around, depending on how > selftests are ultimately run. The issue seems specific of the eBPF CI. Others might be able to use kernel modules. Either choice is fine for me. Roberto
