netdev - build breakage due to br_multicast.c referencing ipv6_dev_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Mar 2011 12:34:19 +0000
From:	"Jan Beulich" <JBeulich@...ell.com>
To:	<linus.luessing@....de>
Cc:	<davem@...emloft.net>, <shemminger@...ux-foundation.org>,
	<bridge@...ts.linux-foundation.org>, <netdev@...r.kernel.org>
Subject: build breakage due to br_multicast.c referencing
	 ipv6_dev_get_saddr()

With BRIDGE=y and IPV6=m commit
fe29ec41aaa51902aebd63658dfb04fe6fea8be5 ("bridge: Use IPv6
link-local address for multicast listener queries") causes the build to
break.

Similary, even if both are =m, but ipv6.ko got blacklisted (as is
happening in various SuSE distros when disabling IPv6), there's
a runtime problem since bridge.ko then won't load anymore due
to the missing symbol.

I note that infiniband appears to have had a similar problem
(didn't verify whether they have other dependencies on ipv6.ko),
resolved by an odd looking dependency of INFINIBAND_ADDR_TRANS
on !(INFINIBAND = y && IPV6 = m).

IP_VS also seems to have a similar issue.

Resolving this the infiniband way seems rather undesirable to me.
Instead I would think that this and any similar dependency should
get resolved via placing a stub pointer in net/ipv6/addrconf_core.c
(for this particular case), and having ipv6.ko set the pointer to the
actual implementation.

Otherwise, namely in distro kernels, pure IPv4 environments
pointlessly load the (huge) ipv6.ko just to satisfy symbol
references that would never get called.

One unrelated other observation with this change of yours:
daddr is an input argument to ipv6_dev_get_saddr(), yet
it gets initialized only after the function was called. Is that
really correct?

Thanks, Jan

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html