Subject: Re: [RFC][PATCH] Prevent overriding of Symbols in the Kernel,
	avoiding Undefined behaviour
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Andrew Morton <akpm@osdl.org>
Cc: Ashutosh Naik <ashutosh.naik@gmail.com>, anandhkrishnan@yahoo.com,
       linux-kernel@vger.kernel.org, rusty@rustcorp.com.au, rth@redhat.com,
       greg@kroah.com
In-Reply-To: <20051212111322.40be4cfe.akpm@osdl.org>
References: <81083a450512120439h69ccf938m12301985458ea69f@mail.gmail.com>
	 <20051212111322.40be4cfe.akpm@osdl.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Mon, 12 Dec 2005 22:48:32 +0000
Message-Id: <1134427712.10304.6.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 888
Lines: 21

On Llu, 2005-12-12 at 11:13 -0800, Andrew Morton wrote:
> Do we really need to do this at runtime?  We could check this when building
> module depoendencies (for example).  That'll be a 95% solution..

Its almost the 0% solution. The kernel as shipped doesn't seem to have
any clashing symbols like this. The two sets of cases people report are 

1. Out of tree modules
2. Reconfiguring, rebuilding something from kernel to module and not
cleaning up

A dep time solution might fix one of those but robustness here would be
good, especially as once the installation is incorrect end users can
often trigger hotplug loads that cause problems.


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