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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 28 Apr 2008 10:08:19 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roland Dreier <rdreier@...co.com>
Cc:	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: Build failure (with insane config)


* Roland Dreier <rdreier@...co.com> wrote:

> For x86-64, arch/x86/lib/Makefile has:
> 
>         lib-y += csum-partial_64.o csum-copy_64.o csum-wrappers_64.o
> 
> so in particular ip_compute_csum() (from csum-partial_64.c) gets put in
> libs, so even though it is exported, it gets thrown away at link time if
> there are no non-modular users.
> 
> However, if someone has an insane config with CONFIG_NET=n and
> CONFIG_VIDEO_BT848=m, then ip_compute_csum() gets discarded but the
> modular code in drivers/media/video/bt8xx/bttv-cards.c calls it and...
> 
>         ERROR: "ip_compute_csum" [drivers/media/video/bt8xx/bttv.ko] undefined!
> 
> I guess one fix is just to put at least csum-partial_64.c in obj-y 
> instead; it does seem broken to have files with EXPORT_SYMBOL() be 
> lib-y, since it is really an invitation for this problem.  Other ideas 
> would be for bttv to depend on or select CONFIG_NET.

well, the TCP/IP checksumming functions are in lib portions on every 
architecture i checked, and the exports are handled by the networking 
code. And the symbol used is named ip_compute_csum(). So i think the 
correct solution is to make CONFIG_VIDEO_BT848 depend on CONFIG_NET ...

especially on embedded there's an advantage in linking out unused core 
kernel functions. But even if we did this change on x86, other 
architectures might (correctly) complain about x86 going it alone. x86 
gets the most use by far, so if we start introducing build assymetries 
like this it will just mess up the build on other architectures.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists