Open ryao opened 10 years ago
It looks like save_rest_ptr
is NULL. SAVE_REST is a macro in arch/x86/include/asm/calling.h, but the code tries to call it as a function. The comments suggest that this worked, but it is not apparent how.
What kernel are you using? The code is brittle but works on older kernels. On 29 Jul 2014 00:59, "Richard Yao" notifications@github.com wrote:
It looks like save_rest_ptr is NULL. After looking at this in more detail, I find it a wonder that it ever worked. SAVE_REST is a macro in arch/x86/include/asm/calling.h. It shouldn't be accessible in the manner that it is used here.
— Reply to this email directly or view it on GitHub https://github.com/dtrace4linux/linux/issues/75#issuecomment-50418623.
The original report used 3.13.0. My test VM is currently using 3.12.21-gentoo-r1, which is a very lightly patched 3.12.21. The syscall code was definitely not touched. The latter kernel was compiled with GCC 4.8.2. It is worth noting that the Gentoo version applies to the kernel sources while the .config is provided by the user. Here is a link to a pastebin containing my VM's .config just in case you asked expecting to be able to find it based on my answer to your question:
http://bpaste.net/show/521394/
On a related note, Linux 3.7 changed several syscalls to stop using ptregs. torvalds/linux@6bf9adfc90370b695cb111116e15fdc0e1906270 changed sys_sigaltstack
while torvalds/linux@1d4b4b2994b5fc208963c0b795291f8c1f18becf changed sys_fork/sys_vfork/sys_clone
. This code is definitely broken as of Linux 3.7. It is not clear to me that it should work as expected in earlier kernels because SAVE_REST is not a function, but I believe that it somehow did not crash.
sys_sigsuspend seems to have also been changed in Linux 3.7:
torvalds/linux@0a0e8cdf734ce723bfc4ca6032ffbc03ce17c642
Interesting - I thought I had verified up to the 3.11 kernel but I dont have a VM containing that - so now I have something to keep me busy for a few days. It looks like that if pt_regs stuff is gone, that should make life simpler. The code in my dtrace is horribly complex, and needs simplification. It could be time to split the file and freeze the legacy kernels and make life easier for everything else.
Strangely, it compiles nicely, but as you say, with save_rest having gone AWOL, it will just panic if you invoke it. I will go for 3.13 kernel (current ubuntu) to reset the baseline.
thanks
On 29 July 2014 14:18, Richard Yao notifications@github.com wrote:
sys_sigsuspend seems to have also been changed in Linux 3.7:
torvalds/linux@0a0e8cd https://github.com/torvalds/linux/commit/0a0e8cdf734ce723bfc4ca6032ffbc03ce17c642
— Reply to this email directly or view it on GitHub https://github.com/dtrace4linux/linux/issues/75#issuecomment-50474417.
I now have a 3.13 kernel in a VM and can see that dtrace works, except for the ptregs syscalls. Hopefully not too difficult to fix in the next few days.
On 29 July 2014 22:25, Paul Fox paul.d.fox@gmail.com wrote:
Interesting - I thought I had verified up to the 3.11 kernel but I dont have a VM containing that - so now I have something to keep me busy for a few days. It looks like that if pt_regs stuff is gone, that should make life simpler. The code in my dtrace is horribly complex, and needs simplification. It could be time to split the file and freeze the legacy kernels and make life easier for everything else.
Strangely, it compiles nicely, but as you say, with save_rest having gone AWOL, it will just panic if you invoke it. I will go for 3.13 kernel (current ubuntu) to reset the baseline.
thanks
On 29 July 2014 14:18, Richard Yao notifications@github.com wrote:
sys_sigsuspend seems to have also been changed in Linux 3.7:
torvalds/linux@0a0e8cd https://github.com/torvalds/linux/commit/0a0e8cdf734ce723bfc4ca6032ffbc03ce17c642
— Reply to this email directly or view it on GitHub https://github.com/dtrace4linux/linux/issues/75#issuecomment-50474417.
The following is from a QEMU virtual machine where I tried doing a fork in another virtual termianl.
list *systrace_assembler_dummy+0xb/0x1c
shows that /root/dtrace/build-3.13.0/driver/systrace.c:450 is the last thing on the stack. It looks like we have a NULL pointer dereference in systrace_part1_sys_clone().