Hi Mathieu, (2014/02/26 4:46), Mathieu Desnoyers wrote: > Hi, > > I had a bug report[1] from a user trying to add a kretprobe on the system > call entry code path: > > arch/x86/kernel/entry_64.S: > > ffffffff813dffe2 <system_call_fastpath+0x16>: > cmpl $__NR_syscall_max,%eax > #endif > ja badsys > movq %r10,%rcx > call *sys_call_table(,%rax,8) # XXX: rip relative > movq %rax,RAX-ARGOFFSET(%rsp) <--- return address pointing here
Hm, I guess you put kretprobes on the functions on the sys_call_table, right? > And all hell breaks loose (various types of faults, machine reboots, > applications exit randomly, etc.). I understand that this code path > is not marked as unsafe against kprobes, and I tested that a kprobes > indeed works fine there. However, kretprobes probably presumes a function > stack layout that is just not valid for the syscall entry routine. All the syscall entry functions caused this issue? or some specific function(s) ? And could you tell me the kernel version you used? > Any thoughts on how kretprobes should handle this ? I'll try to reproduce it in kvm environment. Thank you! -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
