Systemtap Embedded 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が解決され、アドレスが正しく解決されていることをテストできました。システムコールが呼び出されているようですが、戻りません。
*カーネル空間からシステムコールを呼び出すのが最善のアイデアではないことはわかっていますが、私を信じてください。これを行う必要があります;) *
一方、別の簡単なテストを行って、カーネルによってエクスポートされたfilp_openを呼び出し、syscall でさえなく、単なるカーネル関数であり、同じ失敗した結果のファイルを作成しました。
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 と関数は、syscall.open.returnプローブのコンテキストで呼び出されます。コメントの 1 つで説明されているように、Systemtapリターン プローブはkretprobeを使用して実装されます ... これは、トランポリンの関数リターン アドレスを置き換えます ... これは、syscall ルーチンが既に終了しており、これにより、関連するロックが解放されている必要があることを意味しますファイルシステム自体ですが、おそらく何かが欠けています。
その時点でカーネルをデバッグすると、次のトレースバックが表示されます。明らかに、デッドロックは 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 でも発生します。