第(3+1)回 六本木 Linux カーネル読書会¶
今回は exit の中を流れを追ってみる。
読む¶
do_exit(kernel/exit.c:898)¶
システムコールexit()のメイン処理は、kernel/exit.cのdo_exit関数から始まります。 do_exitから呼び出されている、exit_xxx関数を読んでいけば大まかな処理が解る
exit_signals(kernel/signals.c:2437)¶
signalをmaskしていたりして、pending状態になっているsignalを処理している。 終了したtask_structがthreadだった場合、pendingしているsignalを他のthreadに付け直す必要があり、その処理をretarget_shared_pending関数で行っている。
exit_itimers(kernel/posix-timers.c:940)¶
いわゆるpoxiタイマー(timer_createで作る奴)の解放処理。
exit_mm(kernel/exit.c:638)¶
カーネルスレッドを除くプロセスまたスレッドのtask_struct構造体はメモリ空間を表すmm_struct構造体を保持している(スレッドでは共有)。 そのmm_structの解放処理を行っている。
exit_sem(include/linux/sem.h:119)¶
保持しているセマフォの解放処理。
exit_shm(include/linux/shm.h:123)¶
保持している共有メモリの解放処理。
exit_files(kernel/exit.c:538)¶
struct files_struct(開いているファイルディスクリプタ)の解放処理。
exit_fs(fs/fs_struct.c:105)¶
struct fs_struct(プロセスの作業ディレクトリ)の解放処理。
exit_thread(arch/x86/kernel/process.c:87)¶
アーキテクチャ固有のプロセス終了処理を行う。
exit_notify(kernel/exit.c:829)¶
プロセスが終了した場合、親プロセスへのSIGCHLDの配信や親プロセスの付け替え(daemon化とか)や、release_taskを呼び出しtask_structが保持している一部データ構造の解放等も行う。
exit_io_context(include/linux/iocontext.h:149)¶
IOスケジューラ回りのデータ構造、task_struct->io_contextの解放処理。
最終処理¶
task_sturct->stateをTASK_DEADに変えてschedule()を呼び出している。 schedule()から処理が帰る事はなく、スケジューラ処理の最終段階(finish_task_switch関数)で、task_structを解放している
schedule(kernel/sched/core.c:3266)
次回¶
- http://togetter.com/li/380435
- プロセスの回三回で出てきた用語を理解する。
候補 - プロセスの名前空間 - cgroup - IRQ (ソフトウェア,ハードウェア) - DMA (Direct Memory Access) - CoW (Copy on Write) - RCU (Read Copy Update) - SystemTap, ftrace, dtrace の違いをまとめる