Unixカーネルの設計 7 プロセスの制御

【UNIXカーネルの設計】

7. プロセスの制御

7章主な内容
●

プロセスの生成

pid = fork();

●

シグナル

●

プロセスの終了

●

プロセス終了の待合せ pid = wait(stat_addr)

●

他のプログラムの起動 execve(filename,argv,envp)

●

プロセスの利用者ID

●

プロセスの大きさの変更

●

システムの起動とinitプロセス

exit(status);

プロセスの生成
pid = fork();

fork システムコール
●
●

UNIXにおいてユーザがプロセスを作る唯一の方法
親 → 子にコンテキストがコピーされるのが特徴
fork時に各領域をコピー

親プロセス
p領域(プロセス固有の領域表)

u区域

子プロセス
p領域(プロセス固有の領域表)

ユーザのFD表
text

data

stack

ユーザのFD表

タイマ(実行時間等)
カレントディレクトリ
エラーフィールド

text

data

stack

fork()

カーネルスタック

共有テキスト

タイマ(実行時間等)
エラーフィールド

プロセス表へのポインタ
親プロセス親プロセス
データ
スタック

u区域

子プロセス子プロセス
データ
スタック


テキストのように、共有できるものはする

【復習】
※1 u区域は、プロセス表とともにプロセスの状態について保持している。p129 を参照。
※2 プロセス固有の領域表は、プロセス内の各領域(テキスト、データ、スタックなど)の開始アドレスを保持する。p131 を参照。

fork の処理順序1: 領域の割り当て
kernel
1. 領域を割り当て、プロセスIDを付ける。

仮想メモリ
親プロセス
(pid1000)

他プロセス

子プロセス
(pid1001)

fork の処理順序2: プロセス表の割り当て
2. プロセス表の空きを確認し、確保して初期化。
デッドロックを防ぐため、一般ユーザは最後の空き項目は
使えない。スーパーユーザだと使える。

kernel

プロセス表
state
S

親プロセス
(pid1000)

他プロセス

子プロセス
(pid1001)

【復習】
※1 プロセス表の各項目については、p129 6.1 プロセスの状態とその遷移を参照。

size
xxx

R

仮想メモリ

pid
982
1000

xxx

initial

1001

xxx

...

fork の処理順序3: コンテキスト複写
仮想メモリ

プロセス表

(pid1000)

p領域

他プロセス

state
R

子プロセス
(pid1001)

u区域

pid
1000
1001

xxx

p領域

u区域

ユーザのFD表
text

data

stack

ユーザのFD表
text

...

data

stack


プログラム
PS
カウンタレジスタ

スタック
ポインタ

kernel

...


データ
スタック

レジスタコンテキスト

...

size
xxx

initial

親プロセス

データ
スタック

利用者スタック

共有テキスト

プログラム
PS


スタック
ポインタ

3. 親から子へコンテキストをコピーする。
スタックのコピーは、fork()実行しているスタックから。

fork の処理順序4: iノードの更新
仮想メモリ

プロセス表

(pid1000)

他プロセス

p領域

state
R

子プロセス
(pid1001)

u区域

pid
1000
1001

xxx

p領域

u区域

オープンされたファイル
text

data

stack


現ディレクトリ
変更されたルート.

text

data

stack

変更されたルート

データ
スタック

PS
プログラム

データ
スタック



...

size
xxx

initial

親プロセス

PS
プログラム

スタック
ポインタ


スタック
ポインタ

共有テキスト
ファイル表

...

xxx
(参照数1+1)

iノード表

...

yyy
(参照数1+1)

...

(参照数1+1)

...

chrootしたdir
(参照数1+1)

4. ファイル表の参照値を+1する。親子は同じファイル表項目を参照する。
iノード表は、現ディレクトリとおよびchrootした場合はルートに+1する。
【復習】
※1 ファイル表、iノード表については 5 ファイルシステム用のシステムコールを参照。

fork の処理順序5: 実行可にしてfork()終了
仮想メモリ

プロセス表

実行可

(pid1000)

他プロセス

state
R

子プロセス
(pid1001)

pid
1000
1001

...

size
xxx

R

親プロセス

xxx

実行可
p領域

u区域

p領域

u区域

text

data

stack


変更されたルート.

text

data

stack

変更されたルート

データ
スタック

PS
プログラム

データ
スタック
PS
プログラム

スタック
ポインタ


スタック
ポインタ

共有テキスト
ファイル表

...

xxx
(参照数2)

iノード表

...

yyy
(参照数2)

...

(参照数2)

...

chrootしたdir
(参照数2)

fork() を使ったプログラムの流れ

main () {
int stat_addr;
if (fork() == 0) {
printf(...);
exit(0);
}
}

wait(&stat_addr);


main () {
int stat_addr;
if (fork() == 0) {
printf(...);
exit(0);
}
wait(&stat_addr);
}

親プロセス


main () {
int stat_addr;
if (fork() == 0) {
printf(...);
exit(0);
}
wait(&stat_addr);
}

親プロセス
子プロセス


main () {
int stat_addr;
if (fork() == 0) {
printf(...);
exit(0);
}
wait(&stat_addr);

子プロセス

親プロセス(待ち)

}
fork()は親プロセスには、子プロセスのpidを返す。
子プロセスには【0】を返す。


main () {
int stat_addr;
if (fork() == 0) {
printf(...);
exit(0);
}
wait(&stat_addr);

子プロセス

親プロセス(待ち)

}
子プロセスが exit() を実行して終了すると


main () {
int stat_addr;
if (fork() == 0) {
printf(...);
exit(0);
}
wait(&stat_addr);
}

親プロセス(終了)

waitの引数アドレスに子プロセスの終了コードを
設定してwaitから復帰します。

シグナル
●
●

非同期に発生した事象をプロセスに伝える手段。
プロセス間の通信や、カーネルからの異常通知に使う。
SIGHUP (1)

SIGINT (2)

SIGABRT (6)

SIGKILL (9)

(ハングアップ検出) (キーボード割り込み)

(アボート)

(kill シグナル)

SIGUSR1 (30,10,16)
(ユーザ定義シグナル)

SIGQUIT (3)

(キーボードによる中止)

SIGSEGV (11)
(メモリ不正参照)

SIGCHLD (20,17,18)

(子プロセスの一時停止または終了)

signal
シグナル処理

参考: POSIX標準シグナル
http://linuxjm.sourceforge.jp/html/LDP_man-pages/man7/signal.7.html

プロセス

シグナルをチェックするタイミング
●
●

主にカーネルモード実行中から遷移する場合にチェック
利用者モード実行中の場合は、割込みを発生させてからチェック
利用者モード実行中
システムコール
割込み

割込み・
割込み復帰

9

2

ゾンビ状態

カーネルモード
実行中
CPU横取り

プロセスの
再スケジュール

休眠

メモリ上
休眠状態

利用者モード復帰

復帰

終了 (exit)

4

1

目覚め

3

ここから下はスワップ関連の状態

7
CPU割り当て
保留状態

メモリ上
実行可能状態

シグナルフィールド
●
●
●

受信したシグナルを示すフィールド
シグナルチェックのタイミングでの確認対象
同じシグナルを複数回受信したかは保持できない
プロセス表
state

size

S

982

xxx

S

1000

xxx

R
p領域

pid

1001

xxx


xxx

u区域
ユーザのFD表

text

data

stack


プロセス
プロセス
データ
スタック
PS
プログラム

スタック
ポインタ


シグナルを受信したかは、
プロセス表のシグナルフィールドに格納

シグナルの操作
シグナルの操作には大きく分けて３つの種類がある
●
●
●

exit を実行してプロセスが終了する (SIGABRT/SIGKILLなど)
無視する (何も設定していないSIGUSR1など？)
ユーザ関数を実行する (システムコールsignalで設定)

システムコール signal

oldfunction = signal(signum, function);
元々登録されていた
関数のアドレス

シグナル番号実行したい関数

シグナル処理順序1: プロセス表の確認と初期化
プロセス表
state
S

982

xxx

1000

xxx

R

チェック

size

S

kernel

pid

1001

xxx


xxxxxx

シグナルを受け取っていた場合、主に３種類の対処がある。

シグナル関数に『0』が設定

exit または Core

『1』が設定

exit

特定のシグナルではcoreを出力し、
それ以外はプロセス終了する。

無視する

『関数』が設定

シグナル処理関数を
実行する

次ページ以降に続く

シグナル処理順序2: 利用者スタックフレームの生成
次に実行する関数をシグナルハンドラ関数に書き換えるために、
スタックフレームを追加して、追加したフレームに元の戻り先をコピーする。
2. 新規フレームを生成
(シグナルに対応した関数実行用)

kernel

signalfunc()
コピーされたレジスタコンテキスト

ローカル変数・関数の引数

1. レジスタコンテキストにアクセス

プログラム
PS

スタック
ポインタ

func1()

呼出し後の戻り番地
(レジスタコンテキスト)
PS
プログラム

スタック
ポインタ

※この時点ではプログラムカウンタ
の実行先はfunc1のまま


シグナル処理順序3: PCとスタックポインタを変更
PCをシグナルハンドラ関数の命令番地に変更し、
スタックポインタは先ほどコピーしたフレームを指すように変更する。

kernel

signalfunc()

3. プログラムカウンタ → シグナル操作関数
スタックポインタ
→ 追加したフレーム
ローカル変数・関数の引数

1. レジスタコンテキストにアクセス

コピーされたレジスタコンテキスト
プログラム
PS

スタック
ポインタ

func1()

呼出し後の戻り番地
(レジスタコンテキスト)
PS
プログラム

スタック
ポインタ


【割込み処理】のようにして、利用者スタックでシグナルに対応した関数を実行

プロセスグループとは
●
●

同じログインシェルの場合などにプロセスをグループ化する
同一のシグナルを、プロセスグループに対して投げるために使う

login
プロセスグループ1

bash
./application_a

端末回線のハング等による
シグナルはグループ内
全てのプロセスに送る。

application_a1
application_a2
login
プロセスグループ2

bash

シグナルの送出

システムコール kill

kill (pid, signum);
プロセス番号シグナル番号

●
●
●

●

pid が整数の場合は、pid のプロセスにシグナルを送る
pid が0の場合は、シグナルを送り主と同じプロセスグループに送る
pid が-1の場合は、シグナル送り主の実行利用者IDと同じ利用者IDを
持つプロセスに送る
pid が-1以外の負数の場合は、絶対値と等しいプロセスグループに送る

exit の実行

システムコール exit

exit(status)
親プロセスに返す終了コード

●

プロセスはゾンビ状態に遷移し、資源を解放する。

●

status の値は親プロセスに返される。

exit の処理順序1: シグナル処理の停止
1. プロセスのシグナル処理を禁止する → 終わるプロセスのシグナルを処理しても意味がない

exit の処理順序2: グループにSIGHUP送出
1. プロセスのシグナル処理を禁止する
2. プロセスグループの代表の場合は、グループのプロセスに
【ハングアップ】シグナルを送る。

SIGHUP
exit()
代表

子

孫

例: loginなど

孫
子

孫
端末に対応付いた全てのプロセスを終了させる

exit の処理順序3: オープン中のファイルをclose()
3. オープンされているファイル識別子を調べ、close()によりクローズする。
FD表

プロセス
p領域
text

data

u区域
stack

ファイル表

iノード表

参照数
1→0

/etc/...
参照数2→1

参照数
1→0

/etc/...
参照数3→1

0
1

ファイル識別子(FD)

データ
スタック
PS
プログラム

スタック
ポインタ


exit の処理順序4: カレントディレクトリファイルのiノード解放
4. iputアルゴリズムによって、プロセスの現ディレクトリとchrootしたiノードを解放する
iノード表

プロセス
p領域

u区域
プロセスの現ディレクトリ

text

data

stack
変更したルートディレクトリ

データ
スタック
PS
プログラム
レジスタ
カウンタ

スタック
ポインタ


u区域の現ディレクトリを元に、
カレントディレクトリを示す
ファイルのiノード参照数を-1する

/home/test
参照数2→1

exit の処理順序5: メモリ解放をゾンビ状態への遷移
5. detachreg アルゴリズムによって、利用者メモリを全て解放し、プロセスをゾンビ状態にする。

利用者モード実行中
システムコール
割込み

復帰

割込み・
割込み復帰

9

1

2

CPU横取り
終了 (exit)
ゾンビ状態
カーネルモード
実行中

利用者モード復帰

7

CPU割り当て
保留状態

exit の処理順序6: 統計情報の記録
6. 統計情報を書き出す
●
●

プロセスおよび子孫の利用者モード・カーネルモードでの実行時間
ユーザIDとCPU、メモリの使用状況、I/Oの実行回数等など

かつてのUNIXはコンピュータをみんなで使って、
後で請求するために必要だった。

exit の処理順序7: プロセスツリーから除去
6. 統計情報を書き出す
7. 対象のプロセスをプロセスツリーから取り除く。
init (pid 1)

実行中の子プロセス群

exit()したプロセス

R

Z
ゾンビ状態

R

R
●

R

●

実行中の子プロセスは、initの子になる。
既にゾンビ状態であった子プロセスは削除される。

プロセス終了の待合せ

wait の実行

システムコール wait

pid = wait(stat_addr)
ゾンビ状態となった
子プロセスのPID

stat_addrは、子プロセスの
終了コードを格納する整数ポインタ

●

子プロセス終了との同期を取る為に使う。

●

子プロセスにゾンビ状態がいない場合、休眠する。

●

子プロセス終了シグナルによって、休眠より目覚め、
子プロセスのプロセス表領域の解放処理を行う。

wait の処理順序1: ゾンビ子プロセスの確認と休眠
1. ゾンビ子プロセスがなければ、休眠状態となる。

wait()
S

R
S
S

いずれの子プロセスも
実行中または休眠中

wait の処理順序2: ゾンビ状態の発生とシグナル送出
2. 子プロセスがexit() を実行してゾンビ状態となり、子プロセス終了シグナルを親に投げる。

wait()
S

R
S

子プロセス終了シグナル

Z
exit()によりゾンビ状態へ

wait の処理順序3: 親プロセスの目覚めと子プロセス解放
3. wait()していた親プロセスは目覚め、ゾンビ状態の子プロセスのプロセス表項目を解放する。

●
●

子プロセスのCPU使用量を親プロセスに加える
子プロセスのプロセス表の項目を解放する

wait()
R

R
S
Z

wait の処理順序4: wait()が応答を返す
3. wait()していた親プロセスは目覚め、ゾンビ状態の子プロセスのプロセス表項目を解放する。
4. 子プロセスIDと、子プロセスの終了状態コードをwait() 呼び出し元に返す。

pid = wait(stat_addr);
999

0

wait()
R

R
S
Z

pid: 999, exit status: 0

他のプログラムの起動

execve の実行

システムコール execve

execve(filename, argv, envp)
実行ファイル名

引数

環境変数

●

プロセスのメモリ空間を実行可能ファイルに置き換える

●

元の利用者レベルコンテキストは上書きされる
(テキスト、データ、スタック等)

execve の処理順序1: 実行可能ファイルヘッダの読み込み
1. iノードを割り当て、対象ファイルが実行可能であることを確認し、ヘッダを読み込む。
ヘッダから対象ファイルがロードモジュールか確認する。

基本ヘッダ

区分1ヘッダ

マジック数
区分の個数
レジスタの初期値
区分の型
区分の大きさ
仮想アドレス
.
.

区分1

テキスト

区分2

データ
.
.

区分n

その他の情報
実行可能ファイルの形式

【マジック数】
実行可のファイルの型を示す。
例えば『0x7f 'E' 'L' 'F'』など(ELF形式)

ヘッダ部分

execve の処理順序2: exec引数の避難
2. execの引数を置き換え対象のユーザ空間から避難する。
引数を退避する
仮想メモリ

execve()を
実行したプロセス

この後、メモリ解放してしまうので、
配列argsを避難する必要がある

execve

引数

execve の処理順序3: 古い領域の解放
3. プロセスの古い領域を解放する。

仮想メモリ
execve

引数

detachregアルゴリズムによる
古い領域の解放

execve の処理順序4: 実行可能ファイルのロード
4. 領域を確保し、実行可能ファイルをメモリにロードする。
退避していた引数を
bssに格納

仮想メモリ
.text

.data

.bss

実行可能ファイル

execve

引数

execve の処理順序5: シグナルのリセットとレジスタ初期化
5. シグナル受信のリセットと、レジスタを初期化する。
プログラムカウンタは実行ファイルのヘッダに設定された、先頭の命令に設定。
.text

.data

.bss

p領域
text

u区域

data

シグナル処理
ルーチン

stack

データ
スタック
PS
プログラム

スタック
ポインタ


execve の処理順序6: iノードの解放
5. シグナル受信のリセットと、レジスタを初期化する。
プログラムカウンタは実行ファイルのヘッダに設定された、先頭の命令に設定。
6. 実行可能ファイルを開くために割り当てたiノードを iput アルゴリズムで解放
新実行ファイル

旧実行ファイル

仮想メモリ
.text

.data

.bss

これで利用者レベルコンテキストの
入れ替わり処理が完了。

テキスト領域とデータ領域を分ける理由1
メモリ保護機構を使って、命令領域への書き込みを保護するため。
テキストとデータを
一緒の領域にした場合

テキストとデータを
一緒の領域にした場合

.text

.text

.data .bss
heap

命令領域への書込を
ブロックできない

.data
.bss
heap

stack

stack

×

保護領域なので
書き込めない
書き込み可能

テキスト領域とデータ領域を分ける理由2
●

text領域だけを再利用することも理論的には可能

●

再利用を意図して、sticky bit を設定した場合は、
プロセス終了後もtext領域を解放しないことも可能。

仮想メモリ
.text

/bin/date 1回目
.data

.bss

/bin/date 2回目
.data .bss

同じテキストであれば共有する

※現在のSolaris/FreeBSD/Linuxではsticky bitによってテキストを残すことはないらしい。
メモリ大容量化に伴い、明示的に残さなくても、ページが再利用されずにtextが残る。
http://ja.wikipedia.org/wiki/スティッキービット

実ユーザID(real user ID) と実効ユーザID (effective user ID)
実ユーザID
●

プログラムを起動したユーザのID

●

ps のUSER列に出てくるいつものユーザID

実効ユーザID
●

ファイルアクセス権の検査
●

●

ファイルアクセスの可否は実効ユーザIDで判断

kill システムコールでシグナルを送る許可の検査
$ ls -l /bin/ping
-rwsr-xr-x. 1 root root 40769 … ping

実効ユーザIDの例 (本書より)
login
●

ユーザIDがrootに設定で、実効ユーザもrootで動く

●

setuidで実効ユーザをログインしたユーザに変更してシェルをexecする

●

ユーザにシェルが返るときには、実効ユーザはログインユーザになる

mkdir
●

ディレクトリを作るのにrootが必要なので、実効ユーザがroot

●

ディレクトリ作成が終わった後に、実ユーザIDに所有者を変更する

プロセスの大きさの変更

brk の実行

システムコール brk

brk(endds)
プロセスのデータ領域の
最大仮想アドレス値(ブレーク値)

●

プロセスのデータ領域を末尾より拡張する。

●

メモリの解放にも使う

●

oldendds = sbrk(increment); で差分指定もできる。

ページ単位でのメモリ割り当ての罠
●

ブレイク値を超えてもSIGSEGVが出ないパターン
仮想メモリ
プロセスで
確保済み

sbrk(0) = 140924
現在の仮想アドレス終端の値
プロセスの終端を超えてアクセス
してもSIGSEGVにならない範囲。
(ページ単位では既に取得済みのため)

140924番地
141312番地
(69ページの終端)

アクセスするとSIGSEGV発生
未割当

システムの起動とinitプロセス

システムの起動1

起動ブロック
(MBR)

1. 起動ブロックから読み込む

起動プログラム
2. ファイルシステムからカーネルのロード

/unix
3. 内部データの初期化

バッファハッシュ

iノードハッシュ

領域/ページ

システムの起動2
4. ルートファイルシステムを/にマウント
プロセス表
state
R

5. プロセス0の環境を作る
●

u区域の作成

●

プロセス表の0番フィールドの初期化

●

pid
0

size
xxx

...

プロセスコンテキスト
p領域

u区域
ユーザのFD表

ルートをプロセス0のカレントディレクトリに設定

text

data

stack


6. プロセス0からforkして、子プロセスでinitを実行。/etc/inittabを読む。
●
●

端末を開始する getty プロセスを生成する。
gettyがloginを通し、ログインシェルをexecする。

/etc/initab
co::respawn:/etc/getty console console
46:2:respawn:/etc/getty -t 60 tty46 4800H
ラベル:ランレベル:アクション:コマンドの順番
※respawnはプロセスが終了したら再起動する意味

7. プロセス0はスワッパプロセスとして継続する

7. プロセスの制御のまとめ
●

fork は親プロセスのコンテキストを複写して子を作る

●

signal によって、シグナル受信時の振る舞いを定義

●

kill によって、シグナルを対象のプロセスに投げる

●

子プロセス終了シグナルを契機に、ゾンビ状態のプロセスを消去

●

wait をつかって子プロセスの終了と同期を取る

●

text領域は共有することでメモリ効率の向上を目指す

●

実ユーザIDと実効ユーザID。ファイルのアクセス権は実効ユーザID

●

起動時にinitが様々なプロセスを生成し、端末の制御を始める

●

最初のプロセス0はスワッパとして継続する

Unixカーネルの設計 7 プロセスの制御

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Unixカーネルの設計 7 プロセスの制御

Similar to Unixカーネルの設計 7 プロセスの制御 (20)

More from Norito Agetsuma

More from Norito Agetsuma (15)

Recently uploaded

Recently uploaded (12)

Unixカーネルの設計 7 プロセスの制御