Bug #322
closedcompiling for 4.5 fails: "implicit declaration of function ‘G_TC_AT’"
0%
Description
I suspect it might even be the compat code I provided with the last multicast patchset, but couldn't quite verify yet. The issue is the following, occuring when trying to build against a 4.5.0 kernel with a kernel config build via "make defconfig":
/home/tux/dev/batman-adv-t_x/gen-compat-autoconf.sh /home/tux/dev/batman-adv-t_x/compat-autoconf.h mkdir -p /home/tux/dev/batman-adv-t_x/build/net/batman-adv/ compat-patches/replacements.sh touch /home/tux/dev/batman-adv-t_x/build/net/batman-adv/.compat-prepared /usr/bin/make -C /home/tux/dev/linux/headers/usr/src/linux-headers-4.5.0+ M=/home/tux/dev/batman-adv-t_x/build PWD=/home/tux/dev/batman-adv-t_x/build REVISION=2016.5 CONFIG_BATMAN_ADV=m CONFIG_BATMAN_ADV_DEBUG=y CONFIG_BATMAN_ADV_DEBUGFS=y CONFIG_BATMAN_ADV_BLA=y CONFIG_BATMAN_ADV_DAT=y CONFIG_BATMAN_ADV_NC=n CONFIG_BATMAN_ADV_MCAST=y CONFIG_BATMAN_ADV_BATMAN_V=y INSTALL_MOD_DIR=updates/ modules make[1]: Entering directory '/home/tux/dev/linux/headers/usr/src/linux-headers-4.5.0+' CC [M] /home/tux/dev/batman-adv-t_x/build/net/batman-adv/../../../compat-sources/net/core/skbuff.o In file included from include/linux/filter.h:16:0, from include/net/sock.h:64, from include/linux/tcp.h:22, from include/linux/ipv6.h:72, from /home/tux/dev/batman-adv-t_x/build/net/batman-adv/../../../compat-sources/net/core/skbuff.c:35: include/net/sch_generic.h: In function ‘skb_at_tc_ingress’: include/net/sch_generic.h:413:2: error: implicit declaration of function ‘G_TC_AT’ [-Werror=implicit-function-declaration] return G_TC_AT(skb->tc_verd) & AT_INGRESS; ^ include/net/sch_generic.h:413:33: error: ‘AT_INGRESS’ undeclared (first use in this function) return G_TC_AT(skb->tc_verd) & AT_INGRESS; ^ include/net/sch_generic.h:413:33: note: each undeclared identifier is reported only once for each function it appears in cc1: all warnings being treated as errors scripts/Makefile.build:258: recipe for target '/home/tux/dev/batman-adv-t_x/build/net/batman-adv/../../../compat-sources/net/core/skbuff.o' failed make[3]: *** [/home/tux/dev/batman-adv-t_x/build/net/batman-adv/../../../compat-sources/net/core/skbuff.o] Error 1 scripts/Makefile.build:407: recipe for target '/home/tux/dev/batman-adv-t_x/build/net/batman-adv' failed make[2]: *** [/home/tux/dev/batman-adv-t_x/build/net/batman-adv] Error 2 Makefile:1391: recipe for target '_module_/home/tux/dev/batman-adv-t_x/build' failed make[1]: *** [_module_/home/tux/dev/batman-adv-t_x/build] Error 2 make[1]: Leaving directory '/home/tux/dev/linux/headers/usr/src/linux-headers-4.5.0+' Makefile:90: recipe for target 'all' failed make: *** [all] Error 2
I can reproduce the error with v2016.3, v2016.4, v2016.5 and master. The issue does not occur with a kernel 4.6 to 4.9 - those versions have a CONFIG_NET_CLS_ACT set in their .config, too, and the includes of net/pkt_cls.h, uapi/linux/pkt_cls.h or net/sch_generic.h look the same to me compared to 4.5.0.
Although the includes do indeed look a little strange, I'm currently wondering why "include/net/pkt_cls.h" is not "include/linux/pkt_cls.h" which would match better to the uapi variant, I guess?
I will try to reproduce the issue with a v4.5.7 kernel.
Update:
- 4.5.7 does not work either
- 4.3.0 and 4.4.0 work fine
Updated by Sven Eckelmann almost 8 years ago
- Assignee set to Linus Lüssing
Have you checked what Virtualbox did to fix it in their SVN repo? https://www.virtualbox.org/ticket/15327
Updated by Linus Lüssing almost 8 years ago
Woops, haven't saved my last update. My last update consisted this, so yes, a search engine also led me to VirtualBox having had the same issue once.
What they did is simply adding an include in their VirtualBox code, compat style. But looks kind of "wrong", I'm wondering why they haven't submitted a patch to Linux for an include in net/sch_generic.h.
I'm currently bisect'ing, it's some commit between Linux 4.4rc-7 and 4.4-rc8 having introduced the issue.
Also, it's not multicast dependent, with multicast optimizations turned off it fails for bridge-loop-avoidance.c instead.
Updated by Linus Lüssing almost 8 years ago
This commit introduced the issue:
fdc5432a7b44ab7de17141beec19d946b9344e91 is the first bad commit commit fdc5432a7b44ab7de17141beec19d946b9344e91 Author: Daniel Borkmann <daniel@iogearbox.net> Date: Thu Jan 7 15:50:22 2016 +0100 net, sched: add skb_at_tc_ingress helper Add a skb_at_tc_ingress() as this will be needed elsewhere as well and can hide the ugly ifdef. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> :040000 040000 6490612e4ede1a69d14b2993df61b925850dcf94 6bd4ed2177fbb2b86ada15e601b2bcdaabbd6be6 M include :040000 040000 9ca6c05034a6f5ea9ca87bd53a1f4b90845d1c45 0ea5adeae816c02397f57bf87a9429aa9c23f791 M net
Seems obvious to me that the author moved code but forgot to move/add an include, too.
I will continue bisect'ing tomorrow to figure out what might have fixed or hidden this bug again between 4.5 and 4.6. (Maybe that points to some fix which was simply forgotten to be backported to 4.5 stable kernels)
Updated by Linus Lüssing almost 8 years ago
And this is the patch which accidentally "fixed" it by adding the missing include for uapi/linux/pkt_cls.h in include/linux/netdevice.h:
commit e4c6734eaab90695db0ea8456307790cb0c1ccb5 Author: John Fastabend <john.fastabend@gmail.com> Date: Tue Feb 16 21:16:15 2016 -0800 net: rework ndo tc op to consume additional qdisc handle parameter The ndo_setup_tc() op was added to support drivers offloading tx qdiscs however only support for mqprio was ever added. So we only ever added support for passing the number of traffic classes to the driver. This patch generalizes the ndo_setup_tc op so that a handle can be provided to indicate if the offload is for ingress or egress or potentially even child qdiscs. CC: Murali Karicheri <m-karicheri2@ti.com> CC: Shradha Shah <sshah@solarflare.com> CC: Or Gerlitz <ogerlitz@mellanox.com> CC: Ariel Elior <ariel.elior@qlogic.com> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com> CC: Bruce Allan <bruce.w.allan@intel.com> CC: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Don Skidmore <donald.c.skidmore@intel.com> Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net> :040000 040000 7db55c94fddeff569c119f80452911d25be007aa c033a54ea9630457f26aeeabb8b75f9d91b2e339 M drivers :040000 040000 46770a522df76c9c0ed1850737e9c1360f03f1de f8d07537f3abdacf194bc99ae4921e37b1f8c0d0 M include :040000 040000 634792dd917190cef10ab8fcf8b9b1faee3dad19 ee7e2dd613e4ff0084e0c967cad9b400070b9aa9 M net
I'll prepare two patches: One reverting the include this commit made with an "Introduced-by:" to this commit. And then a second patch which re-adds the include in include/net/sch_generic.h with an "Introduced-by" to the helper patch mentioned yesterday which introduced the issue in the first place.
So the first patch will hopefully go to 4.6 kernels and newer, the second one to 4.5 kernels and newer.
Updated by Linus Lüssing almost 8 years ago
The simple patch to add the missing include for uapi/linux/pkt_cls.h in net/sch_generic.h did not work.
I'm currently trying to investigate with Daniel Borkmann why the linux-headers directory created via "$ make-kpkg kernel_headers" creates two and differing header files with the same __LINUX_PKT_CLS_H guard:
- uapi/linux/pkt_cls.h
- linux/pkt_cls.h -> has the "#ifdef KERNEL" section containing the necessary define stripped
So if the non-uapi version is included before the uapi one, then compilation fails.
(So far I am a little clueless why those two headers with the same guard exist or how to fix that)
Updated by Linus Lüssing over 7 years ago
Since there was no response from upstream to fix things in Debian's make-kpkg, a workaround was added to the batman-adv compat code, present since batman-adv v2017.0:
"batman-adv: compat: workaround for issues with make-kpkg for 4.5 kernels" (102146d65c5)
However, make-kpkg still needs to be fixed.
(and actually a new, probably related problem just popped up: #333)
Updated by Sven Eckelmann over 7 years ago
- Status changed from New to Closed
- Target version set to 2017.0