* 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!
Unified · Split
| @@ -1986,11 +1986,13 @@ static void read_markers(const char *fname) · 1985 unmodified lines | ||
| 1986 | 1986 | |
| 1987 | 1987 | mod = find_module(modname); |
| 1988 | 1988 | if (!mod) { |
| 1989 | − if (is_vmlinux(modname)) | |
| 1990 | − have_vmlinux = 1; | |
| 1991 | 1989 | mod = new_module(NOFAIL(strdup(modname))); |
| 1992 | 1990 | mod->skip = 1; |
| 1993 | 1991 | } |
| 1992 | + if (is_vmlinux(modname)) { | |
| 1993 | + have_vmlinux = 1; | |
| 1994 | + mod->skip = 0; | |
| 1995 | + } | |
| 1994 | 1996 | |
| 1995 | 1997 | if (!mod->skip) |
| 1996 | 1998 | add_marker(mod, marker, fmt); |