* Rusty Russell (ru...@rustcorp.com.au) wrote: > On Tue, 25 Oct 2011 16:17:24 -0400, Dave Jones <da...@redhat.com> wrote: > > commit 7816c45bf13255157c00fb8aca86cb64d825e878 > > Author: Roland Vossen <rvos...@broadcom.com> > > Date: Thu Apr 7 11:20:58 2011 +0200 > > > > modules: Enabled dynamic debugging for staging modules > ... > > > > Signed-off-by: Roland Vossen <rvos...@broadcom.com> > > Acked-by: Jason Baron <jba...@redhat.com> > > Signed-off-by: Greg Kroah-Hartman <gre...@suse.de> > > Greg, you know better. This is why we have maintainers: I can't track > patches I don't see. Grrr... > > > If we want to support out of tree modules with this, should we just nuke the > > whole check, or do we still want to prevent certain types of tainted kernels > > from using this stuff ? > > It goes back to the first implementation of kernel markers. IIRC, it > was to prevent dynamic debug stuff from circumventing licensing, but > testing for *any* taint seems overbroad. Mathieu?
This check for tainted modules was first introduced with markers, and then used by tracepoints, and then also by dynamic debug. The rationale for this check was mainly to ensure that the marker/tracepoint code would not trigger a crash when loading a module with incompatible module header, originally compiled for an older kernel, into a newer kernel. This problem would happen even if the said module does not contain any marker/tracepoint, because we happen to try to use fields that are non-existent in the module header. AFAIK, dynamic debug use a similar trick that require extra members in the module header, so checking that the module header format is compatible with the kernel would be enough. Is there a taint flag that allows us to check for this more narrowly ? TAINT_FORCED_MODULE would probably be the closest one we have now, although we might want to be more specific than that. Thanks, Mathieu > > Thanks, > Rusty. > PS. Can't see how this related to lockdep either... -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111026061521.GB16408@Krystal
