From 87f3b6b6fbcbfa715f0d0db3e7a63e65716a6d4e Mon Sep 17 00:00:00 2001 From: Mathieu Desnoyers Date: Mon, 6 Oct 2008 09:30:12 -0400 Subject: Marker depmod fix core kernel list * Theodore Ts'o (tytso@mit.edu) wrote: > > I've been playing with adding some markers into ext4 to see if they > could be useful in solving some problems along with Systemtap. It > appears, though, that as of 2.6.27-rc8, markers defined in code which is > compiled directly into the kernel (i.e., not as modules) don't show up > in Module.markers: > > kvm_trace_entryexit arch/x86/kvm/kvm-intel %u %p %u %u %u %u %u %u > kvm_trace_handler arch/x86/kvm/kvm-intel %u %p %u %u %u %u %u %u > kvm_trace_entryexit arch/x86/kvm/kvm-amd %u %p %u %u %u %u %u %u > kvm_trace_handler arch/x86/kvm/kvm-amd %u %p %u %u %u %u %u %u > > (Note the lack of any of the kernel_sched_* markers, and the markers I > added for ext4_* and jbd2_* are missing as wel.) > > Systemtap apparently depends on in-kernel trace_mark being recorded in > Module.markers, and apparently it's been claimed that it used to be > there. Is this a bug in systemtap, or in how Module.markers is getting > built? And is there a file that contains the equivalent information > for markers located in non-modules code? I think the problem comes from "markers: fix duplicate modpost entry" (commit d35cb360c29956510b2fe1a953bd4968536f7216) Especially : - add_marker(mod, marker, fmt); + if (!mod->skip) + add_marker(mod, marker, fmt); } return; fail: Here is a fix that should take care if this problem. Thanks for the bug report! Signed-off-by: Mathieu Desnoyers Tested-by: "Theodore Ts'o" CC: Greg KH CC: David Smith CC: Roland McGrath CC: Sam Ravnborg CC: Wenji Huang CC: Takashi Nishiie Signed-off-by: Linus Torvalds --- scripts/mod/modpost.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'scripts/mod/modpost.c') diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 418cd7dbbc93..8e0de6a5e18a 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1986,11 +1986,13 @@ static void read_markers(const char *fname) mod = find_module(modname); if (!mod) { - if (is_vmlinux(modname)) - have_vmlinux = 1; mod = new_module(NOFAIL(strdup(modname))); mod->skip = 1; } + if (is_vmlinux(modname)) { + have_vmlinux = 1; + mod->skip = 0; + } if (!mod->skip) add_marker(mod, marker, fmt); -- cgit v1.2.3 From a9860bf05f4cb94f60f8f3459908d5621f75dd06 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 24 Sep 2008 14:46:44 -0700 Subject: Staging: add TAINT_CRAP flag to drivers/staging modules We need to add a flag for all code that is in the drivers/staging/ directory to prevent all other kernel developers from worrying about issues here, and to notify users that the drivers might not be as good as they are normally used to. Based on code from Andreas Gruenbacher and Jeff Mahoney to provide a TAINT flag for the support level of a kernel module in the Novell enterprise kernel release. This is the code that actually modifies the modules, adding the flag to any files in the drivers/staging directory. Cc: Andreas Gruenbacher Cc: Jeff Mahoney Signed-off-by: Greg Kroah-Hartman --- scripts/mod/modpost.c | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'scripts/mod/modpost.c') diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 8e0de6a5e18a..88921611b22e 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1726,6 +1726,14 @@ static void add_header(struct buffer *b, struct module *mod) buf_printf(b, "};\n"); } +void add_staging_flag(struct buffer *b, const char *name) +{ + static const char *staging_dir = "drivers/staging"; + + if (strncmp(staging_dir, name, strlen(staging_dir)) == 0) + buf_printf(b, "\nMODULE_INFO(staging, \"Y\");\n"); +} + /** * Record CRCs for unresolved symbols **/ @@ -2135,6 +2143,7 @@ int main(int argc, char **argv) buf.pos = 0; add_header(&buf, mod); + add_staging_flag(&buf, mod->name); err |= add_versions(&buf, mod); add_depends(&buf, mod, modules); add_moddevtable(&buf, mod); -- cgit v1.2.3