test: Modify mng_mod/*/README

test/mng_mod/issues/1029/1029.patch

@@ -1,7 +1,7 @@
-diff --git a/kernel/include/process.h b/kernel/include/process.h
+diff --git kernel/include/process.h kernel/include/process.h
-index 1bd70e1..240fe03 100644
+index 1bf8f27..e55e40e 100644
---- a/kernel/include/process.h
+--- kernel/include/process.h
-+++ b/kernel/include/process.h
++++ kernel/include/process.h
 @@ -697,6 +697,9 @@ struct thread {
  	// for performance counter
  	unsigned long pmc_alloc_map;
@@ -12,11 +12,11 @@ index 1bd70e1..240fe03 100644
  };
  
  #define VM_RANGE_CACHE_SIZE	4
-diff --git a/kernel/process.c b/kernel/process.c
+diff --git kernel/process.c kernel/process.c
-index cdd4ab3..a3e6c8a 100644
+index 3dda3ea..eb65aa9 100644
---- a/kernel/process.c
+--- kernel/process.c
-+++ b/kernel/process.c
++++ kernel/process.c
-@@ -125,6 +125,7 @@ init_process(struct process *proc, struct process *parent)
+@@ -126,6 +126,7 @@ init_process(struct process *proc, struct process *parent)
  		proc->mpol_threshold = parent->mpol_threshold;
  		memcpy(proc->rlimit, parent->rlimit,
  		       sizeof(struct rlimit) * MCK_RLIM_MAX);
@@ -24,7 +24,7 @@ index cdd4ab3..a3e6c8a 100644
  #ifdef POSTK_DEBUG_TEMP_FIX_69 /* Fix problem not to inherit parent cpu_set. */
  		memcpy(&proc->cpu_set, &parent->cpu_set,
  		       sizeof(proc->cpu_set));
-@@ -3104,12 +3105,16 @@ out_schedule:
+@@ -3135,12 +3136,16 @@ out_schedule:
  	schedule();
  }
  
@@ -41,7 +41,7 @@ index cdd4ab3..a3e6c8a 100644
  
  	if (cpu_local_var(no_preempt)) {
  		kprintf("%s: WARNING can't schedule() while no preemption, cnt: %d\n",
-@@ -3139,6 +3144,62 @@ redo:
+@@ -3173,6 +3178,62 @@ redo:
  		}
  	}
  
@@ -101,10 +101,10 @@ index cdd4ab3..a3e6c8a 100644
 +	}
 +}
 +
+ 	/* Switch to idle() when prev is PS_EXITED since it always reaches release_thread() 
+ 	   because it always resumes from just after ihk_mc_switch_context() call. See #1029 */
  	if (v->flags & CPU_FLAG_NEED_MIGRATE ||
- 	    prev->status == PS_EXITED) {
+@@ -3208,6 +3269,58 @@ redo:
- 		next = &cpu_local_var(idle);
-@@ -3172,6 +3233,58 @@ redo:
  
  	set_timer();
  

test/mng_mod/issues/1029/README

@@ -2,17 +2,17 @@
 Issue#1029が解決され、既存機能にも影響がないことをストレステスト用いた確認（1項目）と、
 schedule()の基本動作確認（12項目）の計13項目のテストによって確認した。
 
-①ストレステストを用いた確認
+1. ストレステストを用いた確認
- 以下のコマンドを実行し、Issue#1029で報告された事象が発生せず、テストがパスすることを確認した。
+・Issue#1029 (https://postpeta.pccluster.org/redmine/issues/1029)
- # ./mck-mcexec.sh ./killit -np 16 -nosignal - ./signalonfutex
+報告で使用されたテストプログラムを用いて、現象が再現しないことを確認した。
  
-②schedule()の基本動作確認
+2. schedule()の基本動作確認
 schedule()実行時のコンテキストスイッチ前thread(prev)と、
 runqに積まれている実行待ちthreadの状態の組み合わせで、12項目のテストを実施した。
 
 基本動作確認の詳細を以下に示す。
 
-1. ファイルの説明
+(1) ファイルの説明
   1029.patch	動作確認用デバッグプリントを追加するパッチファイル
   sched_test.c	修正対象のschedule()の動作を確認するプログラム
 				複数の子プロセスをfork()し、それぞれの子プロセスでsched_setaffinity()を行う
@@ -20,19 +20,19 @@ runqに積まれている実行待ちthreadの状態の組み合わせで、12
 				sched_testプログラムを並列実行する
   result.log	go_testプログラムの実行結果
 
-2. テストの実行方法
+(2) テストの実行方法
- 以下の手順でテストを実行する
+以下の手順でテストを実行する
 	1. 1029.patch をMcKernelのソースコードに適用し、ビルドとインストールを行う
 	2. MakefileのMCK_DIR変数の内容を、McKernelがインストールされているディレクトリに変更する
-    3. McKernelを起動する
+	3. <mckernel-install>/bin/mcreboot.sh -c 2-7 -m 2G -O
 	4. sh make test を実行する
 
-3. テスト項目
+(3) テスト項目
 schedule()実行時のコンテキストスイッチ前thread(prev)と、
 runqに積まれている実行待ちthreadの状態の以下の組み合わせで、
 schedule()が想定どおりの動作をすることを確認する。
 
-◆prevがidleのケース
+・prevがidleのケース
 CT_001: runqが空 
         ⇒ コンテキストスイッチを行わない
 CT_002: runqに実行待ちのthreadが存在し、且つ、そのthreadが1度も実行状態になっていない
@@ -40,7 +40,7 @@ CT_002: runqに実行待ちのthreadが存在し、且つ、そのthreadが1度
 CT_003: runqに実行待ちのthreadが存在し、且つ、そのthreadが実行状態になったことがある
         ⇒ 非idleのthreadにスイッチする
 
-◆schedule時点で当該CPUのCPU_FLAGS_NEED_MIGRATEが活性化しているケース
+・schedule時点で当該CPUのCPU_FLAGS_NEED_MIGRATEが活性化しているケース
 CT_004: runqが空 
         ⇒ idleにスイッチする
 CT_005: runqに実行待ちのthreadが存在し、且つ、そのthreadが1度も実行状態になっていない
@@ -48,7 +48,7 @@ CT_005: runqに実行待ちのthreadが存在し、且つ、そのthreadが1度
 CT_006: runqに実行待ちのthreadが存在し、且つ、そのthreadが実行状態になったことがある
         ⇒ idleにスイッチする
 
-◆prevがidle以外で、statusがPS_EXITED以外：
+・prevがidle以外で、statusがPS_EXITED以外：
 CT_007: runqが空 
         ⇒ idleにスイッチする
 CT_008: runqに実行待ちのthreadが存在し、且つ、そのthreadが1度も実行状態になっていない
@@ -56,7 +56,7 @@ CT_008: runqに実行待ちのthreadが存在し、且つ、そのthreadが1度
 CT_009: runqに実行待ちのthreadが存在し、且つ、そのthreadが実行状態になったことがある
         ⇒ 非idleのthreadにスイッチする
 
-◆prevがidle以外で、statusがPS_EXITED：
+・prevがidle以外で、statusがPS_EXITED：
 CT_010: runqが空 
         ⇒ idleにスイッチする
 CT_011: runqに実行待ちのthreadが存在し、且つ、そのthreadが1度も実行状態になっていない
@@ -64,6 +64,6 @@ CT_011: runqに実行待ちのthreadが存在し、且つ、そのthreadが1度
 CT_012: runqに実行待ちのthreadが存在し、且つ、そのthreadが実行状態になったことがある
         ⇒ idleにスイッチする
 
-4. 結果
+(4) 結果
 テストプログラムの実行結果はresult.log に出力される。
 上記12項目で[OK]が出力されていることを確認した。

test/mng_mod/issues/1031/README

@@ -3,22 +3,22 @@ Issue#1031が解決され、既存機能に影響がないことをIssueで報
 McKernelでのsigaction()の基本動作確認（10項目）の計11項目のテストによって確認した。
 なお、各テストの実行結果は./result.log として格納している。
 
-①Issueで報告されたテストプログラムによる確認
+1. Issueで報告されたテストプログラムによる確認
- ・Issue#1031
+・Issue#1031 (https://postpeta.pccluster.org/redmine/issues/1031)
- 報告で使用されたテストプログラムを用いて、現象が再現しないことを確認した。
+報告で使用されたテストプログラムを用いて、現象が再現しないことを確認した。
- 実行時の出力を./result.log に記載している
+実行時の出力を./result.log に記載している
  
-②McKernelでのsigaction()の基本動作確認
+2. McKernelでのsigaction()の基本動作確認
 以下の内容で、Issue#1031による変更が既存機能に影響しないことを確認した。
 
 基本動作確認の詳細を以下に示す。
 
-1. テストの実行方法
+(1) テストの実行方法
  以下の手順でテストを実行する
 	1. Makefileの変数MCK_DIRの内容を、McKernelがインストールされているディレクトリに変更する
 	2. sh make test を実行する
 
-2. テスト項目
+(2) テスト項目
 CT_001: SIG_RESETHAND 指定時の動作
 	1. SIG_RESETHANDを指定したsigaction()でSIG_USR1にハンドラを設定
 	2. 自身にSIGUSR1を送る
@@ -87,6 +87,6 @@ CT_010: sig_numの有効確認
 	3. sigaction(SIGSTOP, NULL, NULL) が成功する（有効）
 	4. sigaction(_NSIG, NULL, NULL) が失敗する（無効）
 
-3. 結果
+(3) 結果
 テストプログラムの実行結果をresult.log に示す。
 上記の11項目がPASSしていることを確認した。

test/mng_mod/issues/1032-34/README

@@ -3,19 +3,21 @@ Issue#1032～#1034が解決され、既存機能に影響がないことをIssue
 McKernelでのgetrusage()の基本動作確認（10項目）の計13項目のテストによって確認した。
 なお、各テストの実行結果は./result.log として格納している。
 
-①Issueで報告されたテストプログラムによる確認
+1. Issueで報告されたテストプログラムによる確認
- ・Issue#1032, Issue#1033, Issue#1034
+・Issue#1032 (https://postpeta.pccluster.org/redmine/issues/1032)
- 報告で使用されたテストプログラムを100回ずつ実行し、現象が再現しないことを確認した。
+・Issue#1033 (https://postpeta.pccluster.org/redmine/issues/1033)
- 実行時の出力の1回分を./result.log に記載している。
+・Issue#1034 (https://postpeta.pccluster.org/redmine/issues/1034)
+報告で使用されたテストプログラムを100回ずつ実行し、現象が再現しないことを確認した。
+実行時の出力の1回分を./result.log に記載している。
  
-②McKernelでのgetrusage()の基本動作確認
+2. McKernelでのgetrusage()の基本動作確認
 以下の内容で、Issue#1032～#1034による変更が既存機能に影響しないことを確認した。
 各項目はそれぞれ100回ずつ実行し、すべてでPASSすることを確認した。
 テストプログラムの1回分の実行結果をresult.log に記載している。
 
 基本動作確認の詳細を以下に示す。
 
-1. テストの実行方法
+(1) テストの実行方法
  以下の手順でテストを実行する
 	1. Makefileの変数MCK_DIRの内容を、McKernelがインストールされているディレクトリに変更する
 	2. sh make を実行する
@@ -23,14 +25,14 @@ McKernelでのgetrusage()の基本動作確認（10項目）の計13項目のテ
 	4. sh make test を実行する
 	5. ./rm_test_driver.sh を実行し、テスト用のデバイスドライバをアンロードする
 
-2. 前提
+(2) 前提
  テスト中でのCPU時間の加算処理は以下のようにして行っている。
   utime：alarm(2)とSIGALRMハンドラを用いて、SIGALRM受信をcpu_pause()で待つ
   stime：テスト用のデバイスドライバファイル(/dev/test_rusage) へのioctl発行
          上記ioctlはrequest番号秒だけシステム内で処理を行う
          (Linuxでの実行時はタスクがスイッチされるため想定通りの結果は得られない)
 
-3. テスト項目
+(3) テスト項目
 CT_001: 単一プロセスでのRUSAGE_SELFの utime, stime計測動作
   観点：自プロセスのutime, stime計測を確認する
 	1. getrusage(RUSAGE_SELF) を実行し、以下を確認

test/mng_mod/issues/863/README

@@ -1,10 +1,8 @@
 【Issue#863 動作確認】
-1. Issue#863で指摘されたテストプログラムを用いて現象が解消されていることを
+1. Issue#863 (https://postpeta.pccluster.org/redmine/issues/863)
+   で指摘されたテストプログラムを用いて現象が解消されていることを
    確認した。(2件)
 
-Issue#863の再現方法は以下を参照。
-https://postpeta.pccluster.org/redmine/issues/863#テスト手順
-
 確認項目は、以下の通り。
 (1) プログラムがSIGTERMで終了すること。
     → The TEST process is terminated by the signal 15 の表示があれば OK

test/mng_mod/issues/870/README

@@ -1,10 +1,8 @@
 【Issue#870 動作確認】
-1. Issue#870で指摘されたテストプログラムを用いて現象が解消されていることを
+1. Issue#870 (https://postpeta.pccluster.org/redmine/issues/870)
+   で指摘されたテストプログラムを用いて現象が解消されていることを
    確認した。(2件)
 
-Issue#870の再現方法は以下を参照。
-https://postpeta.pccluster.org/redmine/issues/870#再現方法
-
 確認項目は、以下の通り。
 (1) プログラムがシステムコールオフロード完了前にLinuxから送付されたシグナルに
     応答すること。
@@ -24,7 +22,7 @@ CT1001.txt Issue#870の指摘で使用されたテストプログラムの実行
       MCKERNEL_DIR=<mckernel-install>
   (2) 以下のコマンドを実行
       make
-      sudo <mckernel-install>/sbin/mcreboot.sh -c 2-7
+      sudo <mckernel-install>/sbin/mcreboot.sh -c 2-7 -m 4G
       ./CT200x.sh
 
 確認内容は以下の通り。

test/mng_mod/issues/882/README

@@ -1,10 +1,8 @@
 【Issue#882 動作確認】
-1. Issue#882で指摘されたテストプログラムを用いて現象が解消されていることを
+1. Issue#882 (https://postpeta.pccluster.org/redmine/issues/882)
+   に記載のテストプログラムを用いて現象が解消されていることを
    確認した。(テストプログラム1本、確認項目3件)
 
-Issue#882の再現方法は以下を参照。
-https://postpeta.pccluster.org/redmine/issues/882#再現方法
-
 実行結果(エビデンス)は以下の通り。
 
 CT1001-3.txt Issue#882の指摘で使用されたテストプログラムの実行結果
@@ -32,7 +30,7 @@ fork08 fork08
 (2) 以下のコマンドを実行
 
   cd <ltp-top>
-  sudo <mckernel-install>/sbin/mcreboot.sh -c 2,3,4,5,6,7
+  sudo <mckernel-install>/sbin/mcreboot.sh -c 2-7 -m 2G -O
   sudo sh -c 'LTPMCEXEC=<mckernel-install>/bin/mcexec install/runltp -f mylist'
 
 実行結果(エビデンス)は以下の通り。

test/mng_mod/issues/885/README

@@ -3,22 +3,22 @@ Issue#885が解決され、既存機能に影響がないことをIssueで報告
 McKernelでのptraceのattach/detach操作の基本動作確認（9項目）の計11項目のテストによって確認した。
 なお、各テストの実行結果は./result.log として格納している。
 
-①Issueで報告されたテストプログラムによる確認
+1. Issueで報告されたテストプログラムによる確認
- ・Issue#885
+・Issue#885 (https://postpeta.pccluster.org/redmine/issues/885) 
- 報告で使用されたテストプログラムを用いて、現象が再現しないことを確認した。
+報告で使用されたテストプログラムを用いて、現象が再現しないことを確認した。
- 実行時の出力を./result.log に記載している
+実行時の出力を./result.log に記載している
  
-②McKernelでのptraceのattach/detachの基本動作確認
+2. McKernelでのptraceのattach/detachの基本動作確認
 以下の内容で、Issue#885による変更が既存機能に影響しないことを確認した。
 
 基本動作確認の詳細を以下に示す。
 
-1. テストの実行方法
+(1) テストの実行方法
- 以下の手順でテストを実行する
+以下の手順でテストを実行する
 	1. Makefileの変数MCK_DIRの内容を、McKernelがインストールされているディレクトリに変更する
 	2. sh make test を実行する
 
-2. テスト項目
+(2) テスト項目
 CT_001: 通常のattach detach 操作
 	1. 親プロセスが子プロセスにattach
 	2. 親プロセスがwait()で子プロセスの停止を回収
@@ -77,6 +77,6 @@ CT_010: 親子関係ではないプロセス間でのattach
 	8. tracerプロセスが終了
 	9. 親プロセスがwait()でtracee,tracerプロセスの終了を回収
 
-3. 結果
+(3) 結果
 テストプログラムの実行結果をresult.log に示す。
 上記の11項目がPASSしていることを確認した。

test/mng_mod/issues/898_928/README

@@ -2,36 +2,32 @@
 Issue#898, #928が解決され、既存機能に影響がないことをihklibテストスイートを用いた確認（2項目）と、
 McKernelの起動/終了の基本動作確認（9項目）の計11項目のテストによって確認した。
 
-①ihklibテストスイートを用いた確認
+1. ihklibテストスイートを用いた確認
- ・Issue#898
+・Issue#898 (https://postpeta.pccluster.org/redmine/issues/898)
- ihklibテストスイートのihklib001_lin.c を以下のように修正して1000回繰り返し実行し、
+報告で使用されたテストプログラムを1000回繰り返し実行して、現象が再現しないことを確認した。
- すべての実行においてテストをパスすることを確認した。
-  - McKernelのブート処理の直後にgoto文を追加し、シャットダウン処理の直前に移動する
 
- ・Issue#928
+・Issue#928 (https://postpeta.pccluster.org/redmine/issues/928)
- ihklibテストスイートのihklib001_lin.c を以下のように修正して1000回繰り返し実行し、
+報告で使用されたテストプログラムを1000回繰り返し実行して、現象が再現しないことを確認した。
- すべての実行においてテストをパスすることを確認した。
-  - McKernelプロセス(mcexec)の実行直後にgoto文を追加し、シャットダウン処理の直前に移動する
  
-②McKernelの起動/終了の基本動作確認
+2. McKernelの起動/終了の基本動作確認
 McKernelの状態と、終了処理(shutdown, destroy)の組み合わせで、
 9項目のテストを実施した。
 
 基本動作確認の詳細を以下に示す。
 
-1. ファイルの説明
+(1) ファイルの説明
   CT_xxx.c              各テスト項目のテストプログラム
   force_shutdown.patch  McKernelの状態がRUNNINGにならなかった場合に行う強制シャットダウン処理を
                         発生させるパッチファイル
   result.log            テストプログラムの実行結果
 
-2. テストの実行方法
+(2) テストの実行方法
  以下の手順でテストを実行する
 	1. Makefileの変数MCK_DIRの内容を、McKernelがインストールされているディレクトリに変更する
 	2. CT_xxx.c の定数MCK_DIRの内容を、McKernelがインストールされているディレクトリに変更する
 	3. sh make test を実行する
 
-3. テスト項目
+(3) テスト項目
 以下の条件でMcKernelの起動/終了が正常に行われることを確認する
 なお、McKernelの起動、終了の操作はihklibを用いて実施する
 
@@ -88,6 +84,6 @@ CT_009:
 	2. 起動の直後にMcKernelを終了(ihk_os_shutdown)する
 	⇒ ihk_os_shutdownが0を返す
 
-4. 結果
+(4) 結果
 テストプログラムの実行結果はresult.log に出力される。
 上記9項目で[OK]が出力されていることを確認した。

test/mng_mod/issues/923/README

@@ -1,6 +1,7 @@
 【Issue#923 動作確認】
-1. Issue#923 に報告されている手順で現象が解消したことを確認した。(1件)
+1. Issue#923 (https://postpeta.pccluster.org/redmine/issues/923) に報告され
-   実行結果(エビデンス)は以下の通り。
+  ている手順で現象が解消したことを確認した。(1件)
+  実行結果(エビデンス)は以下の通り。
 
 CT01001.txt Issue#923 に報告されている手順の実行結果(OK 1件、NG 0件)
 

test/mng_mod/issues/925/README

@@ -3,23 +3,23 @@ Issue#925が解決され、既存機能に影響がないことをIssueで報告
 McKernelでのXPMEM操作の基本動作確認（11項目）の計12項目のテストによって確認した。
 なお、各テストの実行結果は./result.log として格納している。
 
-①Issueで報告されたテストプログラムによる確認
+1. Issueで報告されたテストプログラムによる確認
- ・Issue#925
+・Issue#925 (https://postpeta.pccluster.org/redmine/issues/925)
- 報告で使用されたテストプログラムを用いて、現象が再現しないことを確認した。
+報告で使用されたテストプログラムを用いて、現象が再現しないことを確認した。
- 実行時の出力を./result.log に記載している
+実行時の出力を./result.log に記載している
  
-②McKernelでのXPMEM操作の基本動作確認
+2. McKernelでのXPMEM操作の基本動作確認
 以下の内容で、Issue#925による変更が既存機能(XPMEM)に影響しないことを確認した。
 
 基本動作確認の詳細を以下に示す。
 
-1. テストの実行方法
+(1) テストの実行方法
  以下の手順でテストを実行する
 	1. Makefileの変数MCK_DIRの内容を、McKernelがインストールされているディレクトリに変更する
 	2. Makefileの変数XPMEM_DIRの内容を、XPMEMライブラリがインストールされているディレクトリに変更する
 	3. sh make test を実行する
 
-2. テスト項目
+(2) テスト項目
 CT_001: 単一プロセスでのXPMEM操作
 	1. 実行したプロセスがxpmem_make -> xpmem_get -> xpmem_attach -> xpmem_detach -> xpmem_remove
 
@@ -78,6 +78,6 @@ CT_011: xpmem_remove 呼び出しの異常系
 	1. xpmem_remove の第1引数に不正なsegidを指定する (失敗)
 	2. 1度xpmem_remove を実施したsegidで、再度xpmem_remove を行う (失敗)
 
-3. 結果
+(3) 結果
 テストプログラムの実行結果をresult.log に示す。
 上記の11項目がPASSしていることを確認した。