ゾンビプロセスを作成しない - Linuxの備忘録とか・・・(目次へ）
親プロセスがwaitで子の終了ステータスを取得しない間、子プロセスはゾンビ状態となります。しかし処理によっては、いつ終了するか分からない子プロセスのために、親プロセスは毎回wait状態で待つわけにいかない場合もあります。そこで子の終了をシグナルで親プロセスに知らせるという手法があります。struct sigaction saに子プロセスからの終了シグナルをハンドルすることで実現しています。 親プロセスが子プロセスのそのシグナルを無視するか、ハンドラーにSIG_IGNを設定することで、子プロセスをゾンビ状態にしないことができ、子プロセスが呼び出したexit関数内からタスク構造体を解放することができるようです。 ・補足 waitで待つ場合、子のタスク構造体は親が呼び出したwait内から解放されます。 ゾンビ作成サンプル #include <sys/types.h> #include <unis
sk_buff - Linuxカーネルメモ
3. その他のデータ構造 3.1 frags配列 skb_shared_info内のfrags配列がある。この配列を使用することで、パケットデータを非連続な領域に分断して保持することができる。fragsを使用した状態のsk_buffを図3.1に示す。 ただし、このようにfragsパケットデータを分断して持つ形式はネットワークカード(とそのドライバ)がScatter/gather I/O(*1)に対応していないと使えない。Scatter/gather I/Oに対応しているとデバイスにNETIF_F_SGフラグが設定されているので、送信デバイスにこのフラグが立っている場合のみ、このような形式を使う。 frags配列の要素はskb_frag_structとなっており(ポインタではなくそのもの)、これは、分断されたデータがどこにあるかを管理する。 skb_frag_structはデータが置かれてい
jprobe - Linuxの備忘録とか・・・(目次へ）
jprobeはkprobeで実装されており、その時の引数が継承して関数をフックする。以下はカーネル関数do_sys_openをフックし、新規作成でファイル名がaaaの時、ファイル名をhogehogeにする。 #include <linux/kernel.h> #include <linux/module.h> #include <linux/kprobes.h> #include <linux/fs.h> MODULE_DESCRIPTION("jprobe test"); MODULE_AUTHOR("y.kitamura"); MODULE_LICENSE("GPL"); static long jprobe_do_sys_open(int dfd, char __user *filename, int flags, umode_t mode) { if (flags & O_CREA
フィルタ - Linuxカーネルメモ
カーネルのnetfilter機能により、パケットフィルタやIPマスカレードを行なうことができる。 1. フック処理 フィルタ関連の処理を行うためにLinuxではプロトコル層にフック処理を登録できるようになっている。フック処理はnf_hooks[pf][hook]に登録され、NF_HOOK()によりプロトコル層から呼び出される。プロトコル(pf)毎にフック種別(hook)があり、フック処理のエントリ(struct nf_hook_ops)をリスト形式で登録している。IPv4では表1に示すHook種別がある。 フック処理にはフィルタ処理以外にもIPマスカレードの処理やConnection Trackingに関する処理など様々なものが登録されるが、これらのフック処理はお互いに関連があることが多く処理順序を制御できないとまずい。このため、各フック処理には優先度があり、フック処理の順番を制御できるよ
fuse - Linuxの備忘録とか・・・(目次へ）
ユーザプロセスはファイルをオープンする毎に、マウントされたファイルシステムのinodeのコールバック関数がfileにバインドされ、そのコールバック関数をコールする事で、ユーザプロセスから掛かるファイルシステムを参照できるわけです。このinodeのコールバック関数は、それぞれのカーネル下で動作するファイルシステム処理の実装としてインプリメントされています。 fsueはFilesystem in Userspaceと言うことで、このカーネル下でのインプリメントをユーザプロセスとして実現すると言う物です。 下記はsshによる応用例でsshfsと言うコマンドでのサンプルです。127.0.0.1:/home/kitamuraのネットワークのリモートのファイルを/tmp/hoge0にマウントしています。 [root@localhost ~]# ls /home/kitamura/ Desktop Do
open_by_handle_atシステムコール - Linuxの備忘録とか・・・(目次へ）
name_to_handle_atで取得したfile_handleとmount idで、open_by_handle_atでファイルを参照します。運用はサーバで提供するファイルのfile_handleとmount idをクライアントに送信し、クライアントはそのファイル参照時、file_handleとmount idをサーバに返信する事で、サーバはパスに依存しないでファイル参照します。 open_by_handle_atの第一引数は、mount idでなく、そのファイルシステム下のファイルIDで、そのファイルをopenする事で、掛かるファイルシステムがunmountされていない事、そしてファイル参照中にそのファイルシステムがumontされないようにするためです。掛かるファイルシステムの任意のファイルが１つでもオープンされていれば、unmountできません。なお、AT_FDCWDとすると、カレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
