0

Linuxでいくつかのソフトウェア+ドライバーをテストしていますが、ドライバーは内部関数で get_user_pages() を使用しています。ある時点で、私のドライバーは get_user_pages() から ERESTARTSYS エラー (-512) を受け取ります。カーネル コードによると、「保留中の SIGKILL がある場合は、ページに障害を発生させたり、メモリを割り当てたりしないでください」という理由で発生します。- memory.c カーネル ファイルからのコメントです。私の質問は、この SIGKILL の送信者とその理由を確認するにはどうすればよいですか? /var/log/kern.log ファイルを調べようとしましたが、シグナルについて何も確認できませんでした。私に何ができる？

4

2 に答える 2

0

シグナル情報を提供するためにカーネルにパッチを適用する意思がない限り、SIGKILL を使用できるとは思いません (その他の場合も同様です)。その場合、ドキュメントごとに si_code と si_pid の値を調べることができます: http://pubs.opengroup.org/onlinepubs/009696699/basedefs/signal.h.html

たとえば、シグナル情報が siptr にある場合:

if ((siptr)->si_code <= 0) {
   printk(KERN_DEBUG "kill sent by process %u", (siptr)->si_pid);
}

if チェックは厳密には必要ありません: printk() を kill() によって生成されたシグナルに制限します。カーネルがシグナルを発生させた場合、si_code は 0 より大きくなります。

于 2013-11-24T16:49:30.040 に答える
0

私はまったく同じ問題を抱えていました。しかし、get_user_pages() の代わりに、sock_sendmsg() から -ERESTARTSYS を取得します。

この問題をデバッグするために、linux-3.2/kernel/signal.c: __send_signal() にログ メッセージを追加しました。

また、カーネルログにメッセージがいっぱいになるのを避けるため。strncmp(t->comm, "myprogramname") そして、t->comm、t->pid、current->comm、current->pid をログに記録します。

また、SIGKILLだけでなく、保留中の他のシグナルでもあることに気付きました。その後、呼び出しは-ERESTARTSYSを返します。

したがって、私の次のステップは、誰が私のプログラムに信号を送っているのかを見つけることでした. そして、すべてのシグナルのハンドラーを追加します（実際には処理できないSIGKILLを除く）。幸運なことに、SIGKILL ではありませんでした。

ハンドラーを追加すると、問題が解決しない場合がありますが、ログに記録すると、送信者と理由が特定されます。

取り扱いは、同様の問題を抱えている他の人を助けるかもしれません。

于 2015-03-23T20:51:02.117 に答える