我正在尝试创建硬链接,直接从Systemtap嵌入式C代码调用 sys_link 。基本上,代码如下:
function sys_link:long(oldname, newname) %{ /* pure */
int error;
mm_segment_t old_fs;
old_fs = get_fs();
set_fs(get_ds());
error = psys_link(STAP_ARG_oldname, STAP_ARG_newname);
set_fs(old_fs);
STAP_RETURN(error);
%}
内核未导出sys_link,因此在初始化时使用 kallsyms_lookup_name()解决了 psys_link 的问题,我可以测试地址是否已正确解析。 似乎正在调用系统调用,但它永远不会返回。
*我知道从内核空间调用syscall并不是最好的主意,但请相信我,我需要这样做;) *
另一方面,我做了另一个更简单的测试,调用了由内核导出的 filp_open ,它甚至不是系统调用,它只是一个内核函数,它创建了一个同样不成功的文件结果:
function myopen:long(newname) %{ /* pure */
struct file *file;
mm_segment_t old_fs = get_fs();
set_fs(get_ds());
file = filp_open(STAP_ARG_newname, O_WRONLY|O_CREAT, 0644);
set_fs(old_fs);
STAP_RETURN(1);
%}
有什么线索为什么冻结内核?
更新: 在 syscall.open.return 探针的上下文中调用syscall和函数。正如其中一项评论所述, Systemtap 返回探针是使用 kretprobe ...实现的,它替换了蹦床的函数返回地址... AFAIU表示系统调用例程已经完成,应该已经释放了与文件系统本身相关的所有锁,但是我可能丢失了一些东西。
在那个时候调试内核给了我以下的追溯,显然,死锁在一个kprobe锁中。
>>> info threads
Id Target Id Frame
* 1 Thread 1 (CPU#0 [running]) __loop_delay () at arch/arm/lib/delay-loop.S:42
2 Thread 2 (CPU#1 [running]) __loop_delay () at arch/arm/lib/delay-loop.S:42
3 Thread 3 (CPU#2 [running]) __loop_delay () at arch/arm/lib/delay-loop.S:42
4 Thread 4 (CPU#3 [running]) arch_spin_lock (lock=<optimised out>) at ./arch/arm/include/asm/spinlock.h:91
>>> thread 4
[Switching to thread 4 (Thread 4)]
#0 arch_spin_lock (lock=<optimised out>) at ./arch/arm/include/asm/spinlock.h:91
91 wfe();
>>> bt
#0 arch_spin_lock (lock=<optimised out>) at ./arch/arm/include/asm/spinlock.h:91
#1 do_raw_spin_lock_flags (flags=<optimised out>, lock=<optimised out>) at ./include/linux/spinlock.h:155
#2 __raw_spin_lock_irqsave (lock=<optimised out>) at ./include/linux/spinlock_api_smp.h:121
#3 _raw_spin_lock_irqsave (lock=0xc1541f80 <kretprobe_table_locks+2240>) at kernel/locking/spinlock.c:159
#4 0xc0412d18 in kretprobe_table_lock (flags=<optimised out>, hash=<optimised out>) at kernel/kprobes.c:1113
#5 kprobe_flush_task (tk=0xed165b00) at kernel/kprobes.c:1158
#6 0xc03814f8 in finish_task_switch (prev=0xed165b00) at kernel/sched/core.c:2783
#7 0xc0c19c38 in context_switch (cookie=..., next=<optimised out>, prev=<optimised out>, rq=<optimised out>) at kernel/sched/core.c:2902
#8 __schedule (preempt=<optimised out>) at kernel/sched/core.c:3402
#9 0xc0c1a1a4 in schedule () at kernel/sched/core.c:3457
#10 0xc0c1a54c in schedule_preempt_disabled () at kernel/sched/core.c:3490
#11 0xc03a23dc in cpu_idle_loop () at kernel/sched/idle.c:273
#12 cpu_startup_entry (state=<optimised out>) at kernel/sched/idle.c:302
#13 0xc031206c in secondary_start_kernel () at arch/arm/kernel/smp.c:412
#14 0x60301dec in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
注意:这是ARM机器的回溯,但是在i386中也会发生相同的结果。
答案 0 :(得分:0)
Systemtap探针处理程序通常在原子上下文中运行,这意味着先占和/或中断被禁用。如果您设法从这样的上下文中调用内核函数,则目标函数最好同样具有“原子性”,即,永远不要使用任何新的锁或块。