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
Compiled bpfilter doesn't load: No such file or directory #1
Comments
Hi! I tried [ 935.679528] bpfilter: Loaded bpfilter_umh pid 10526
[ 935.680291] bpfilter: log file opened and ready to use
[ 935.680393] bpfilter: generate forward packet assessment
[ 935.680422] bpfilter: fixup counter for rule 0
[ 935.680451] bpfilter: generate forward packet assessment
[ 935.680473] bpfilter: fixup counter for rule 1
[ 935.680502] bpfilter: fixup counter for rule 2
[ 935.680921] bpfilter: opened BPF map with FD 3
[ 935.682306] libbpf: Kernel error message: Exclusivity flag on, cannot modify
[ 935.683390] libbpf: Kernel error message: Exclusivity flag on, cannot modify
[ 935.684148] libbpf: Kernel error message: Exclusivity flag on, cannot modify
[ 935.684190] bpfilter: installed filter table My guess is that this error is commit from a missing configuration. Could you share your Also, I've pushed a few new commits to fix a couple of issues I found out, although I don't expect those to solve your problem. |
Hello, That's weird, alright. I personally think the ifindex is part of the problem, anyway, here's my current .config file: https://pastebin.com/raw/RKN6RgPJ Thanks a lot, |
Seems like it. I added a comment to |
@Haxverse did changing the ifindex solved it? |
Closing this issue as it is most likely fixed now. |
Until now, each bf_program expected its rules indexes to be sequential for all the rules applicable to it, starting from 0. For example, with the following set of rules: - #0 - Block ICMP on veth1 - facebook#1 - Allow all The program attached to veth1 would have #0 and facebook#1, while the program attached to eth0 would only have facebook#1. Then, there would be 1 counters map for each program, with as many entries as rules defined in the program (following previous example, 2 entries for veth1, 1 for eth0). However, rule->index would be used to retrieve a rule's counters in each bf_program. Hence, the program attached to eth0 tried to access the counters map at index 1 to get the counters of the rule with index=1, which doesn't exist. This changes solves this issue by ensuring the rule will update the counters at its rule->index index, meaning all the programs from a given codegen will have the same number of entries in their counters map, even though some of them might remain unused. Using the first example, both veth1 and eth0 programs would have a counters map with 2 entries. #0 would always write to index 0, while facebook#1 would always write to index 1. Another solution would be to have a unique counters map at the codegen level, shared by all the codegen's programs, but we wouldn't have per-interface counters. Signed-off-by: Quentin Deslandes <qde@naccy.de>
Until now, each bf_program expected its rules indexes to be sequential for all the rules applicable to it, starting from 0. For example, with the following set of rules: - #0 - Block ICMP on veth1 - #1 - Allow all The program attached to veth1 would have #0 and #1, while the program attached to eth0 would only have #1. Then, there would be 1 counters map for each program, with as many entries as rules defined in the program (following previous example, 2 entries for veth1, 1 for eth0). However, rule->index would be used to retrieve a rule's counters in each bf_program. Hence, the program attached to eth0 tried to access the counters map at index 1 to get the counters of the rule with index=1, which doesn't exist. This changes solves this issue by ensuring the rule will update the counters at its rule->index index, meaning all the programs from a given codegen will have the same number of entries in their counters map, even though some of them might remain unused. Using the first example, both veth1 and eth0 programs would have a counters map with 2 entries. #0 would always write to index 0, while #1 would always write to index 1. Another solution would be to have a unique counters map at the codegen level, shared by all the codegen's programs, but we wouldn't have per-interface counters. Signed-off-by: Quentin Deslandes <qde@naccy.de>
Hello @qdeslandes,
I have just compiled the bpfilter module on both the linux-6.1.14 branch and the bpf-next branch, both times I get the following output in dmesg:
Would you happen to know if I did something wrong?
Thanks a lot,
Mr. Hax
The text was updated successfully, but these errors were encountered: