From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
"Frank Ch. Eigler" <fche@redhat.com>,
Jon Masters <jcm@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Christoph Hellwig <hch@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: [patch 01/26] Linux Kernel Markers Support for Proprierary Modules
Date: Thu, 24 Jan 2008 15:27:07 -0500 [thread overview]
Message-ID: <20080124203332.749619937@polymtl.ca> (raw)
In-Reply-To: 20080124202706.250598537@polymtl.ca
[-- Attachment #1: markers-support-for-proprietary-modules.patch --]
[-- Type: text/plain, Size: 4672 bytes --]
There seems to be good arguments for markers to support proprierary modules. So
I am throwing this one-liner in and let's see how people react. It only makes
sure that a module that has been "forced" to be loaded won't have its markers
used. It is important to leave this check to make sure the kernel does not crash
by expecting the markers part of the struct module by mistake in the case there
is an incorrect checksum.
Discussion so far :
http://lkml.org/lkml/2008/1/22/226
Jon Masters <jcm@redhat.com> writes:
I notice in module.c:
#ifdef CONFIG_MARKERS
if (!mod->taints)
marker_update_probe_range(mod->markers,
mod->markers + mod->num_markers, NULL, NULL);
#endif
Is this an attempt to not set a marker for proprietary modules? [...]
* Frank Ch. Eigler (fche@redhat.com) wrote:
I can't seem to find any discussion about this aspect. If this is the
intent, it seems misguided to me. There may instead be a relationship
to TAINT_FORCED_{RMMOD,MODULE}. Mathieu?
- FChE
On Tue, 2008-01-22 at 22:10 -0500, Mathieu Desnoyers wrote:
On my part, its mostly a matter of not crashing the kernel when someone
tries to force modprobe of a proprietary module (where the checksums
doesn't match) on a kernel that supports the markers. Not doing so
causes the markers to try to find the marker-specific information in
struct module which doesn't exist and OOPSes.
Christoph's point of view is rather more drastic than mine : it's not
interesting for the kernel community to help proprietary modules writers,
so it's a good idea not to give them marker support. (I CC'ed him so he
can clarify his position).
* Frank Ch. Eigler (fche@redhat.com) wrote:
[...]
Another way of looking at this though is that by allowing/encouraging
proprietary module writers to include markers, we and their users get
new diagnostic capabilities. It constitutes a little bit of opening
up, which IMO we should reward rather than punish.
* Vladis Ketnieks (Valdis.Kletnieks@vt.edu) wrote:
On Wed, 23 Jan 2008 09:48:12 EST, Mathieu Desnoyers said:
> This specific one is a kernel policy matter, and I personally don't
> have a strong opinion about it. I agree that you raise a good counter
> argument : it can be useful to proprietary modules users to be able to
> extract tracing information from those modules to argue with their
> vendors that their driver/hardware is broken (a tracer is _very_ useful
> in that kind of situation).
Amen, brother. Been there, done that, got the tshirt (not on Linux, but
other operating systems).
> However, it is also useful to proprieraty
> module writers who can benefit from the merged kernel/modules traces.
> Do we want to give them this ability ?
The proprietary module writer has the *source* for the kernel and their module.
There's no way you can prevent the proprietary module writers from using this
feature as long as you allow other module writers to use it.
> It would surely help writing
> better proprieraty kernel modules.
The biggest complaint against proprietary modules is that they make it
impossible for *us* to debug. And you want to argue *against* a feature that
would allow them to develop better code that causes less crashes, and therefor
less people *asking* for us to debug it?
Remember - when a user tries a Linux box with a proprietary module, and the
experience sucks because the module sucks, they will walk away thinking
"Linux sucks", not "That module sucks".
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: "Frank Ch. Eigler" <fche@redhat.com>
CC: Jon Masters <jcm@redhat.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Christoph Hellwig <hch@infradead.org>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Andrew Morton <akpm@linux-foundation.org>
---
kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-lttng.mm/kernel/module.c
===================================================================
--- linux-2.6-lttng.mm.orig/kernel/module.c 2008-01-24 14:17:23.000000000 -0500
+++ linux-2.6-lttng.mm/kernel/module.c 2008-01-24 14:17:33.000000000 -0500
@@ -1989,7 +1989,7 @@ static struct module *load_module(void _
add_kallsyms(mod, sechdrs, symindex, strindex, secstrings);
#ifdef CONFIG_MARKERS
- if (!mod->taints)
+ if (!(mod->taints & TAINT_FORCED_MODULE))
marker_update_probe_range(mod->markers,
mod->markers + mod->num_markers);
#endif
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2008-01-24 20:42 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-24 20:27 [patch 00/26] Instrumentation Support Enhancement (2.6.24-rc8-mm1) Mathieu Desnoyers
2008-01-24 20:27 ` Mathieu Desnoyers [this message]
2008-01-24 22:19 ` [patch 01/26] Linux Kernel Markers Support for Proprierary Modules Jon Masters
2008-01-24 20:27 ` [patch 02/26] Fix ARM to play nicely with generic Instrumentation menu Mathieu Desnoyers
2008-01-24 21:13 ` Russell King
2008-01-24 21:23 ` Mathieu Desnoyers
2008-01-24 22:17 ` Russell King
2008-01-24 20:27 ` [patch 03/26] Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig Mathieu Desnoyers
2008-01-24 21:00 ` Randy Dunlap
2008-01-24 21:05 ` Mathieu Desnoyers
2008-01-24 22:03 ` Mathieu Desnoyers
2008-01-24 23:05 ` Haavard Skinnemoen
2008-01-24 20:27 ` [patch 04/26] Kprobes - use a mutex to protect the instruction pages list Mathieu Desnoyers
2008-01-24 20:27 ` [patch 05/26] Kprobes - do not use kprobes mutex in arch code Mathieu Desnoyers
2008-01-24 20:27 ` [patch 06/26] Kprobes - declare kprobe_mutex static Mathieu Desnoyers
2008-01-24 20:27 ` [patch 07/26] Add INIT_ARRAY() to kernel.h Mathieu Desnoyers
2008-01-24 20:39 ` Jan Engelhardt
2008-01-24 20:54 ` [patch 07/26] Add INIT_ARRAY() to kernel.h (updated) Mathieu Desnoyers
2008-01-24 21:08 ` Jan Engelhardt
2008-01-24 21:18 ` Mathieu Desnoyers
2008-01-24 20:58 ` [patch 07/26] Add INIT_ARRAY() to kernel.h Randy Dunlap
2008-01-24 21:04 ` Mathieu Desnoyers
2008-01-24 22:02 ` Stefan Richter
2008-01-24 22:10 ` [patch 07/26] Add INIT_ARRAY() to kernel.h (update 2) Mathieu Desnoyers
2008-01-24 22:50 ` Alexey Dobriyan
2008-01-24 23:04 ` [patch 07/26] Add INIT_ARRAY() to kernel.h H. Peter Anvin
2008-01-25 13:14 ` Mathieu Desnoyers
2008-01-25 8:03 ` Jan Engelhardt
2008-01-24 23:03 ` H. Peter Anvin
2008-01-24 20:27 ` [patch 08/26] Text Edit Lock - Architecture Independent Code Mathieu Desnoyers
2008-01-24 20:27 ` [patch 09/26] Text Edit Lock - Alternative code for x86 Mathieu Desnoyers
2008-01-24 20:27 ` [patch 10/26] Text Edit Lock - kprobes architecture independent support Mathieu Desnoyers
2008-01-24 20:27 ` [patch 11/26] Text Edit Lock - kprobes x86 Mathieu Desnoyers
2008-01-24 20:27 ` [patch 12/26] Text Edit Lock - x86_32 standardize debug rodata Mathieu Desnoyers
2008-01-24 20:27 ` [patch 13/26] Text Edit Lock - x86_64 " Mathieu Desnoyers
2008-01-24 20:27 ` [patch 14/26] Immediate Values - Architecture Independent Code Mathieu Desnoyers
2008-01-24 20:27 ` [patch 15/26] Immediate Values - Kconfig menu in EMBEDDED Mathieu Desnoyers
2008-01-24 20:27 ` [patch 16/26] Immediate Values - x86 Optimization Mathieu Desnoyers
2008-01-24 20:27 ` [patch 17/26] Add text_poke and sync_core to powerpc Mathieu Desnoyers
2008-01-24 20:27 ` [patch 18/26] Immediate Values - Powerpc Optimization Mathieu Desnoyers
2008-01-24 20:27 ` [patch 19/26] Immediate Values - Documentation Mathieu Desnoyers
2008-01-24 20:27 ` [patch 20/26] Scheduler Profiling - Use Immediate Values Mathieu Desnoyers
2008-01-24 20:27 ` [patch 21/26] Immediate Values - Move Kprobes x86 restore_interrupt to kdebug.h Mathieu Desnoyers
2008-01-24 20:27 ` [patch 22/26] Add __discard section to x86 Mathieu Desnoyers
2008-01-24 20:27 ` [patch 23/26] Immediate Values - x86 Optimization NMI and MCE support Mathieu Desnoyers
2008-01-24 20:27 ` [patch 24/26] Immediate Values - Powerpc Optimization NMI " Mathieu Desnoyers
2008-01-24 20:27 ` [patch 25/26] Immediate Values Use Arch NMI and MCE Support Mathieu Desnoyers
2008-01-24 20:27 ` [patch 26/26] Linux Kernel Markers - Use Immediate Values Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080124203332.749619937@polymtl.ca \
--to=mathieu.desnoyers@polymtl.ca \
--cc=akpm@linux-foundation.org \
--cc=fche@redhat.com \
--cc=hch@infradead.org \
--cc=jcm@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox