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.
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.
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.
- Kevin