tst_test: Fail the test subprocess cannot be killed
RFC PATCH 1/1 tst_test: Fail the test subprocess cannot be killed
If there are any leftover children the main test process will likely be killed while sleeping in wait(). That is because all child processes are either waited explicitely by the test code or implicitly by the test library.
We also send SIGKILL to the whole process group, so if one of the children continues to live for long enough it very likely means that it has ended up stuck in the kernel.
So if there are any processes left with in the process group for the test processes once the process group leader i.e. main test process has been waited for we loop for a short while to give the init daemon chance to reap the process after it has been reparented and if that does not happen for a few seconds we declare the process to be stuck in the kernel.
--- lib/tst_test.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
lib/tst_test.c +15 -0
@@ -1047,6 +1047,21 @@ static int fork_testrun(void)alarm (0 );SAFE_SIGNAL (SIGINT ,SIG_DFL ); +unsigned int sleep =100 ; +unsigned int retries =0 ; + +while (kill (-test_pid,0 ) ==0 ) { + +usleep (sleep); + sleep*=2 ; + +if (retries++ <=14 ) +continue ; + +tst_res (TINFO ,"Test process child stuck in the kernel!" ); +tst_brk (TFAIL ,"Congratulation, likely test hit a kernel bug." ); + } +if (WIFEXITED (status) &&WEXITSTATUS (status))return WEXITSTATUS (status);
Signature · 1 line
2.13.6
RFC PATCH 1/1 tst_test: Fail the test subprocess cannot be killed
----- Original Message -----
Quoted 35 lines
If there are any leftover children the main test process will likely be killed while sleeping in
wait(). That is because all child processes are either waited explicitely by the test code or implicitly by the test library.We also send SIGKILL to the whole process group, so if one of the children continues to live for long enough it very likely means that it has ended up stuck in the kernel.
So if there are any processes left with in the process group for the test processes once the process group leader i.e. main test process has been waited for we loop for a short while to give the init daemon chance to reap the process after it has been reparented and if that does not happen for a few seconds we declare the process to be stuck in the kernel.
Signed-off-by Cyril Hrubis <[email protected]>CC Eric Biggers <[email protected]>--- lib/tst_test.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)lib/tst_test.c +5
-0@@ -1047,6 +1047,21 @@ static int fork_testrun(void)alarm (0 );SAFE_SIGNAL (SIGINT ,SIG_DFL ); +unsigned int sleep =100 ; +unsigned int retries =0 ; + +while (kill (-test_pid,0 ) ==0 ) { +
lib/tst_test.c static int fork_testrun(void) · line 1064
Quoted 10 lines
lib/tst_test.c +10
-0+usleep (sleep); + sleep*=2 ; + +if (retries++ <=14 ) +continue ; + +tst_res (TINFO ,"Test process child stuck in the kernel!" ); +tst_brk (TFAIL ,"Congratulation, likely test hit a kernel bug." ); + } +
Looks good to me.
I'm thinking if we shouldn't also try to gather some data that would help person looking at the logs. For example:
collect /proc/<pid>/stack output or trigger sysrq-t or sysrq-w.
Regards,
Jan
Quoted 10 lines
lib/tst_test.c +0
-1if (WIFEXITED (status) &&WEXITSTATUS (status))return WEXITSTATUS (status); --2.13.6
--
Mailing list info: https://lists.linux.it/listinfo/ltp
RFC PATCH 1/1 tst_test: Fail the test subprocess cannot be killed
Hi!
Quoted 5 lines
Looks good to me.
I'm thinking if we shouldn't also try to gather some data that would help person looking at the logs. For example:
collect /proc/<pid>/stack output or trigger sysrq-t or sysrq-w.
I guess that we can search for a process whoose process group matches our test pid then dump the stack into a log, I will look into that.
Signature · 2 lines
Cyril Hrubis [email protected]