On 12/02/2025 11:54, Joshua Lant wrote:
Hi Kevin,
On 11/12/2024 17:17, Joshua Lant wrote:
diff --git a/include/uapi/linux/netfilter_bridge/ebtables.h b/include/uapi/linux/netfilter_bridge/ebtables.h index 4ff328f3d339..2491b4acd590 100644 --- a/include/uapi/linux/netfilter_bridge/ebtables.h +++ b/include/uapi/linux/netfilter_bridge/ebtables.h @@ -65,11 +65,16 @@ struct ebt_replace_kernel { /* total size of the entries */ unsigned int entries_size; /* start of the chains */
- struct ebt_entries *hook_entry[NF_BR_NUMHOOKS];
- /* Corresponds to struct ebt_entries * */
- __nf_kptr_t hook_entry[NF_BR_NUMHOOKS];
As I mentioned in my reply to v3, this is the one case where we can't transparently pad entries (this doesn't build: kernel code like in net/bridge/netfilter/ebtable_broute.c expects hook_entry to contain pointers, not integers). What I was wondering is whether we need to touch this struct at all, because surely it is never used by userspace and should never have appeared in a uapi header? If this assumption sounds reasonable to you I'll drop the changes to this struct.
Apologies. In my build these are giving me warnings rather than errors, and I did not spot them... I think that this is a somewhat reasonable assumption... There is a function in the ebtables userspace tool "translate_user2kernel". I am unsure its exact workings, but it uses the ebt_replace struct, which looks to be a carbon copy of the ebt_replace_kernel struct. You are right that it is likely not intended to be in the uapi headers. However, there may be an issue with the kernel reading netlink messages incorrectly if the userspace writes ebt_replace structs (with capabilities), and the kernel is trying to read corresponding ebt_replace_kernel structs with pointers. But at any rate I think this issue can be ignored since it only occurs in the legacy ebtables package, which is now deprecated, and certainly not ported to purecap.
Fair enough, I think it's reasonable to ignore this struct then.
There is another issue in patch 3 (struct xt_rateest_match_info::{est1,est2} are distinct members and so must be in separate unions), and patch 5 needs to be extended to #include the header in all modified uapi headers, but these are both trivial and I can take care of them too.
Okay, I have fixed up the patches and will post them.
Thank you!
By the way I expect that the reason that you are missing various compiler errors is simply that you're not enabling many netfilter options, and as a result not building most of the netfilter files. I tried building those patches with make allyesconfig, that should provide (almost) full coverage.
This is interesting. I was unable to compile using allyesconfig. I dont know if this is due to my flow (using Yocto) or what? I got all sorts of strange errors when building like this. Mainly due to it assuming that GCC should be used for building. Anyway, I simply took all of the netfilter/networking flags and turned all of them on to achieve the same result.
Just to be clear, I didn't enable PCuABI when building allyesconfig, that definitely won't work. Either way enabling the netfilter/networking configs manually should be good enough.
- Kevin