Bernhard Thaler <bernhard.thaler@xxxxxxxx> wrote: > >> index d89f4fa..db0d038 100644 > >> --- a/net/bridge/br_netfilter_hooks.c > >> +++ b/net/bridge/br_netfilter_hooks.c > >> @@ -47,14 +47,22 @@ > >> #ifdef CONFIG_SYSCTL > >> static struct ctl_table_header *brnf_sysctl_header; > >> static int brnf_call_iptables __read_mostly = 1; > >> +#if IS_ENABLED(CONFIG_IPV6) > > > > IS_ENABLED(IP6_NF_IPTABLES) ? > > > > br_netfilter_ipv6.o is dependent on CONFIG_IPV6 and contains > br_nf_pre_routing_ipv6()...for this reason I sticked with CONFIG_IPV6 to > stay consistent. Maybe we should check for both here? Hmmm, good point. I think br_netfilter_ipv6.o should depend on IP6_NF_IPTABLES (which depends on IPV6) too. The entire point of that thing is to push skbs into ip6tables... > > Might also make sense to not create the sysctl and sysfs entry in the > > first place if no ip6tables is available. > > Totally agree, it would be the best solution. > > My idea was that I do not know how admins and their existing scripts > react if sysctl and sysfs entry are gone entirely...and if everybody > assumes the default is 0 if these entry do not exist. > > But scripts that do not check the return code of their write operations > on the sysctl and sysfs may not check for the existance of these entries > either... Yes, thats the problem, a script checking the errors would break as well. Fortunately its not really important since this only affects custom kernel builds. > A message in dmesg log explaining that ip6tables sysctl and sysfs > entries are not exposed due to CONFIG_IPV6=n (and/or IP6_NF_IPTABLES) > may be more helpful to understand what is going on. Hmm, not sure if there is any point in doing that. We don't do that in other cases either, the assumotion is that if you build your own kernels you better know what you're doing (also, in this case ip6tables doesn't work either which is hopefully the right clue...) -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
