Forkシステムコールを作りたいが予期せぬ警告が出る

[keisuke713]

概要

fork システムコールを作成しているのですが、いざユーザーアプリケーションからシステムコールを呼び出そうとすると下記のような警告が出ます。プロセス間通信がうまくいっていないように思うのですが、原因がはっきりしません。お手数ですがご教示いただきたいです。

[vm] Oops: Unexpected error (Operation Would Block)
[vm] WARN:     #0: 38007d6e ipc_reply()+0x52
[vm] WARN:     #1: 38000394 main()+0x38c
[vm] WARN:     #2: 380094c2 start()+0x12

カーネル側のコードはこちらで、上記警告の再現方法は以下です。

microkernel-book % make run
shell > start fork

開発環境

No response

ソースコードのURL

keisuke713#11

[nuta]

Would Blockが返ってくる原因はこの変更です。

diff --git a/servers/vm/main.c b/servers/vm/main.c
index f38e34d..8d094c0 100644
--- a/servers/vm/main.c
+++ b/servers/vm/main.c
@@ -129,7 +129,9 @@ void main(void) {
 
                 m.type = SPAWN_TASK_REPLY_MSG;
                 m.spawn_task_reply.task = task_or_err;
-                ipc_reply(m.src, &m);
+                // ipc_reply(m.src, &m);
+                // 暫定的。通常のアプリケーションを起動するときにもwarnを吐くようになってしまうので別のメッセージタイプを用意する必要あり？
+                ipc_reply(task_or_err, &m);
                 break;
             }
             case DESTROY_TASK_MSG: {

SPAWN_TASKはVMサーバに新しいタスクの生成を要求し、作成されたタスクのID (task_or_err) を返すRPCです。この変更によって、SPAWN_TASK_REPLY_MSGを待っているメッセージ送信元 (m.src) ではなく、新しく作成されたタスク (task_or_err) に送るようになっています。新しいタスクはメッセージを待っていない (つまり、VMサーバのメインループがブロックされてしまう) ので、警告を出してメッセージ送信を中断しています。

[keisuke713]

分かりました、返信先が送信元と一致していなかったということですね。
こちらの関数を読む限り、先に送信を行なった関数はブロック状態となり返信を待つという処理の流れになるのでしょうか？

[nuta]

先に送信を行なった関数はブロック状態となり返信を待つ

重箱の隅をつつくと、call操作をするときの recv_message 関数で受信状態に入ります。カーネルは単一ロック（Big Kernel Lock）で動作するため、送信操作とそれが完了した後の受信操作が一気に行われます。

fork処理で発生するメッセージの流れを、シーケンス図で考えるとバグの原因が分かりやすいかもしれません。

現状の流れ

sequenceDiagram
    親タスク->>VMサーバ: FORK_TASK_MSG
    VMサーバ-->>子タスク: タスクを新規作成
    VMサーバ->>子タスク: FORK_TASK_REPLY_MSG (would blockで失敗)
    親タスク->>親タスク: VMサーバからの返信を待ち続ける (フリーズ状態)

Loading

期待される流れ

sequenceDiagram
    親タスク->>VMサーバ: FORK_TASK_MSG
    VMサーバ-->>子タスク: タスクを新規作成
    VMサーバ->>親タスク: FORK_TASK_REPLY_MSG

Loading

ただし、以下で説明するようにforkシステムコールの方で処理を実装する際は、VMサーバへのメッセージは必要ないかもしれません。

補足: fork処理の実装に必要なもの

実装したいforkは、親タスクの複製を作るものだと思います。この場合、2つコピーするものがあります。

• メモリ: alloc_pages関数で割り当て・マップされるもの。例えばforkシステムコールハンドラ内で、新しいタスクを生成し、struct taskのpagesをコピーする。
• CPUレジスタ: riscv32_trap_frame構造体に入っているfork時の親タスクの実行状態。デフォルトではriscv32_user_entry関数でゼロクリアされているので、そこを変更する必要がある。
• forkシステムコールからの戻り値の変更: CPUレジスタのうち、戻り値として使われるレジスタ (a0) に子タスクの値 (-1) をセットする。

[keisuke713]

なるほど、シーケンス図で表して考えると確かに分かりやすいですね。

実装したいforkは、親タスクの複製を作るものだと思います。この場合、2つコピーするものがあります。

riscv32_trap_frame の情報をコピーするのは理解できました。おそらくこれをコピーしないとユーザーモードに戻るときに割り込み前の状態に正しく復元できないためだと思うので。
しかし alloc_pages に関しては割り当てられるものは処理を追う限りドライバの設定( driver_alloc_pages )でのみ使われている印象だったのでコピー不要かと思ったのですがそんなことないんですかね？

また現状taskはカーネルとvm両方で構造体を作って管理していると思っているのですが、task_spawnで両方の構造体の初期化をしているのでそれを利用するためにvmにメッセージを送って実装するのが一番シンプルかと思ったのですが、(メッセージを送らずにカーネル上で実装するとなるとおそらくどうやってvm上で管理するためのtask構造体を作るかも考える必要が出てくると思ったので)、どう思われますでしょうか？
僕自身どういう設計で進めていくかで詰まっているのでアドバイス頂けると助かります！

[nuta]

ドライバかどうかに関わらず、VMサーバが各タスクに割り当てるメモリ領域をコピーする必要があります。できるだけVMサーバ側に実装を寄せたい場合、例えば次のアプローチがあると思います。

1. VMサーバ: タスク管理構造体に「どの物理ページが、どの仮想アドレスにマップされたか」のリストを保持しておく。ページフォルト時 (handle_page_fault関数) にそのリストを更新する。
2. fork元タスク: 専用システムコール (sys_fork) を呼び出す。
3. カーネル: コピーされたレジスタを初期状態として持つ、新しいタスクを作成する。また、VMサーバにFORK_MSGをcallする。
4. VMサーバ: 新しいタスク管理構造体を作成する。メッセージに記載された親タスクのIDを元に前述のリストを取得し、新しいページの割り当て・コピー・マップを行い、FORK_REPLY_MSGを返す。
5. カーネル: 返信が返ってきたので実行再開。新しいタスクの実行を開始し、システムコールから親タスクへ返る。

[keisuke713]

Mサーバが各タスクに割り当てるメモリ領域をコピーする必要があります。

あ、分かりました。メモリにロードされているセグメント(e.g. 実行コード、ローカル変数)をコピーしないと親プロセスの状態を正しく複製できないということですね。

アプローチ方法についてもご教授いただきたありがとうございます！
一旦上記方法でやってみようと思います！