linux-kernel - Re: [PATCH 3/5] Module: check to see if we have a built in module with the same name

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:	Tue, 29 Jan 2008 00:54:22 +0100 (CET)
From:	Jan Engelhardt <jengelh@...putergmbh.de>
To:	Greg Kroah-Hartman <gregkh@...e.de>
cc:	linux-kernel@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 3/5] Module: check to see if we have a built in module
 with the same name


On Jan 27 2008 15:38, Greg Kroah-Hartman wrote:
>Subject: [PATCH 3/5] Module: check to see if we have a built in module with the
>     same name
>
>When trying to load a module with the same name as a built-in one, a
>scary kobject backtrace comes up.  Prevent that from checking for this
>condition and warning the user as to what exactly is going on.

Should not external modules with internal names be rejected at modprobe 
time? Otherwise I'd wonder how you want to deal with /sys/modules/XXX if 
both modules export some module_param()s.

It's just that if I happen to load vt.ko that the existing 
/sys/modules/vt (from in-kernel vt.o) does not get overwritten by new 
dentries that vt.ko will spawn. Something like /sys/modules/vt.1 perhaps 
for /the new module with same name?
--
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/