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]
Message-ID: <1299778653.15854.370.camel@gandalf.stny.rr.com>
Date:	Thu, 10 Mar 2011 12:37:33 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	linux-kbuild <linux-kbuild@...r.kernel.org>,
	Michal Marek <mmarek@...e.cz>
Subject: Sucky dependencies found in video saa7134 rc

Running randconfigs with ktest seems to find this crap all over. It's
not just saa7134, it happens else where too, but this is the one that
I'm currently looking at.

I'm also not blaming the saa7134 driver, but I think we need to find a
way to fix Kconfig to handle this. Maybe it is in the works. I don't
know.

Here's the issue:

1) in the Makefile in drivers/media/video/saa7134/ we have:

aa7134-y :=	saa7134-cards.o saa7134-core.o saa7134-i2c.o
saa7134-y +=	saa7134-ts.o saa7134-tvaudio.o saa7134-vbi.o
saa7134-y +=	saa7134-video.o
saa7134-$(CONFIG_VIDEO_SAA7134_RC) += saa7134-input.o

2) in the Kconfig of that directory:

config VIDEO_SAA7134_RC
	bool "Philips SAA7134 Remote Controller support"
	depends on RC_CORE
	depends on VIDEO_SAA7134
	default y

3) in the Makefile of drivers/media/rc

obj-$(CONFIG_RC_CORE) += rc-core.o

4) in the Kconfig of that directory:

menuconfig RC_CORE
	tristate "Remote Controller adapters"
	depends on INPUT
	default INPUT

And finally in the .config produced by randconfig:

CONFIG_RC_CORE=m
CONFIG_VIDEO_SAA7134=y
CONFIG_VIDEO_SAA7134_RC=y

Thus, RC_CORE is a module and the SAA7134 input file is built in, which
gives me the following error:

drivers/built-in.o: In function `saa7134_input_init1':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:737: undefined reference to `rc_allocate_device'
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:780: undefined reference to `rc_register_device'
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:787: undefined reference to `rc_free_device'
drivers/built-in.o: In function `saa7134_input_fini':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:799: undefined reference to `rc_unregister_device'
drivers/built-in.o: In function `ir_raw_decode_timer_end':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:400: undefined reference to `ir_raw_event_handle'
drivers/built-in.o: In function `build_key':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:93: undefined reference to `rc_keydown_notimeout'
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:101: undefined reference to `rc_keydown_notimeout'
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:102: undefined reference to `rc_keyup'
drivers/built-in.o: In function `saa7134_raw_decode_irq':
/home/rostedt/work/autotest/nobackup/linux-test.git/drivers/media/video/saa7134/saa7134-input.c:920: undefined reference to `ir_raw_event_store_edge'
make[1]: *** [.tmp_vmlinux1] Error 1

I know this is just a randconfig and I doubt that people will actually
run into this problem, but randconfig should always produce a kernel
that can compile, and preferably boot ;)

I think the issue here is that we should never allowed that SAA7134_RC
be set to 'y' when RC_CORE is 'm'. I need to look at the kconfig code
and see if there's a way to prevent that 'y' if its dependencies have
'm'.

Hmm, but that may not work either :( This may be a Makefile issue, as
that 'y' is not really a builtin to the kernel but a builtin to a module
that may or may not be built into the kernel. Which makes this
dependency agnostic to the Kconfigs. God what a horrible tangled web we
weave!

-- Steve


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ