Fix pidns14 test case

PATCH In review M. Mohan Kumar 4 participants 6 messages Jul 1, 2009 – Jul 8, 2009

lore

Share & tools

lore

M. Mohan Kumar

author

2009-07-01 17:13 UTC #0 lore raw

PATCH 1/1 Fix pidns14 test case

[PATCH] pidns14

Container-init may be immune to unhandled fatal signals (like SIGUSR1) even if they are from ancestor namespace. SIGKILL/SIGSTOP are the only reliable signals to a container-init from ancestor namespace. Make sure that container-init will not respond to signals other than SIGKILL/SIGSTOP

Signed-off-by M. Mohan Kumar <[email protected]>

---
 testcases/kernel/containers/pidns/pidns14.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

testcases/kernel/containers/pidns/pidns14.c +7 -6

index e95bf95..41602cd 100644
@@ -67,9 +67,8 @@ int child_fn(void *ttype)
 		tst_resm(TBROK, "pidns is not created.");
 		cleanup();
 	}
-	pause();
-	tst_resm(TFAIL, "Oops! Container init resumed after receiving SIGUSR1");
-	return -1;
+	sleep(10);
+	return 0;
 }
 
 /*

@@ -111,9 +110,11 @@ int main(int argc, char *argv[])
 	if (waitpid(cpid, &status, 0) < 0)
 		tst_resm(TWARN, "waitpid() failed.");
 
-	if ((WIFSIGNALED(status)) && (WTERMSIG(status) == SIGUSR1))
-		tst_resm(TPASS, "Container init is killed as expected, "
-				" when the SIGUSR1 is passed from parent\n");
+	if (WIFEXITED(status))
+		tst_resm(TPASS, "Container init returned as expected\n");
+	else if ((WIFSIGNALED(status)) && (WTERMSIG(status) == SIGUSR1))
+		tst_resm(TFAIL, "Container init is killed when the SIGUSR1 "
+		       		"is passed from parent\n");
 	 else
 		tst_resm(TFAIL, "After sending signal kill -USR1, "
 				"returned unexpected error\n");

Signature · 8 lines

1.6.0.2


------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Serge E. Hallyn

2009-07-03 09:06 UTC #1 lore raw

Quoted 7 lines · M. Mohan Kumar

[PATCH] pidns14
Container-init may be immune to unhandled fatal signals (like SIGUSR1) even if they are from ancestor namespace. SIGKILL/SIGSTOP are the only reliable signals to a container-init from ancestor namespace. Make sure that container-init will not respond to signals other than SIGKILL/SIGSTOP

Hmm? This may or may not be right... but you start out by saying 'may be immune to', then provide a patch making the testcase TFAIL if is not immune to. So at the very least anyone on a slightly older kernel will get TFAILs.

I don't think that immunity to SIGUSR1 from ancestor pidns is something we want to guarantee, it's just what is happening. The proper thing is to not depend on either getting or not getting SIGUSR1, in my opinion. Suka?

-serge

Quoted 45 lines

Signed-off-by M. Mohan Kumar <[email protected]>

---
 testcases/kernel/containers/pidns/pidns14.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

testcases/kernel/containers/pidns/pidns14.c +7 -6

index e95bf95..41602cd 100644
@@ -67,9 +67,8 @@ int child_fn(void *ttype)
 		tst_resm(TBROK, "pidns is not created.");
 		cleanup();
 	}
-	pause();
-	tst_resm(TFAIL, "Oops! Container init resumed after receiving SIGUSR1");
-	return -1;
+	sleep(10);
+	return 0;
 }
 
 /*

@@ -111,9 +110,11 @@ int main(int argc, char *argv[])
 	if (waitpid(cpid, &status, 0) < 0)
 		tst_resm(TWARN, "waitpid() failed.");
 
-	if ((WIFSIGNALED(status)) && (WTERMSIG(status) == SIGUSR1))
-		tst_resm(TPASS, "Container init is killed as expected, "
-				" when the SIGUSR1 is passed from parent\n");
+	if (WIFEXITED(status))
+		tst_resm(TPASS, "Container init returned as expected\n");
+	else if ((WIFSIGNALED(status)) && (WTERMSIG(status) == SIGUSR1))
+		tst_resm(TFAIL, "Container init is killed when the SIGUSR1 "
+		       		"is passed from parent\n");
 	 else
 		tst_resm(TFAIL, "After sending signal kill -USR1, "
 				"returned unexpected error\n");

Signature · 8 lines

1.6.0.2


------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Sukadev Bhattiprolu

2009-07-02 17:28 UTC #2 lore raw

Serge E. Hallyn [[email protected]] wrote:

| Quoting M. Mohan Kumar ([email protected]):
| > [PATCH] pidns14
| > 
| > Container-init may be immune to unhandled fatal signals (like SIGUSR1)
| > even if they are from ancestor namespace. SIGKILL/SIGSTOP are the only
| > reliable signals to a container-init from ancestor namespace. Make sure
| > that container-init will not respond to signals other than
| > SIGKILL/SIGSTOP
| 
| Hmm?  This may or may not be right...  but you start out by saying 'may be
| immune to', then provide a patch making the testcase TFAIL if is not immune
| to.  So at the very least anyone on a slightly older kernel will get TFAILs.
| 
| I don't think that immunity to SIGUSR1 from ancestor pidns is something we
| want to guarantee, it's just what is happening.  The proper thing is to
| not depend on either getting or not getting SIGUSR1, in my opinion.  Suka?

Yes we did confirm that there is a test for SIGKILL from parent ns. We discussed in the bug report on whether to drop or modify the test, but leaned towards modifying the test bc if SIGUSR1 does kill a container init, then something has changed in the sig_ignored() checks in the kernel.

Hmm, not a very strong reason to keep the test. Lets just drop the test :-)

Sukadev

Subrata Modak

2009-07-06 15:50 UTC #3 lore raw

Suka,

So, what should i do finally ?? Drop this ?

Regards--
Subrata

Quoted 18 lines · Sukadev Bhattiprolu

Serge E. Hallyn [[email protected]] wrote:

| Quoting M. Mohan Kumar ([email protected]):
| > [PATCH] pidns14
| > 
| > Container-init may be immune to unhandled fatal signals (like SIGUSR1)
| > even if they are from ancestor namespace. SIGKILL/SIGSTOP are the only
| > reliable signals to a container-init from ancestor namespace. Make sure
| > that container-init will not respond to signals other than
| > SIGKILL/SIGSTOP
| 
| Hmm?  This may or may not be right...  but you start out by saying 'may be
| immune to', then provide a patch making the testcase TFAIL if is not immune
| to.  So at the very least anyone on a slightly older kernel will get TFAILs.
| 
| I don't think that immunity to SIGUSR1 from ancestor pidns is something we
| want to guarantee, it's just what is happening.  The proper thing is to
| not depend on either getting or not getting SIGUSR1, in my opinion.  Suka?

Quoted 8 lines

Yes we did confirm that there is a test for SIGKILL from parent ns. We discussed in the bug report on whether to drop or modify the test, but leaned towards modifying the test bc if SIGUSR1 does kill a container init, then something has changed in the sig_ignored() checks in the kernel.
Hmm, not a very strong reason to keep the test. Lets just drop the test :-)
Sukadev

Sukadev Bhattiprolu

2009-07-07 16:48 UTC #4 lore raw

Subrata Modak [[email protected]] wrote:

| Suka,
| 
| So, what should i do finally ?? Drop this ?

Yes, please.

Thanks,

Sukadev

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Subrata Modak

2009-07-08 18:34 UTC #5 lore raw

Quoted 6 lines · Sukadev Bhattiprolu

Subrata Modak [[email protected]] wrote:
| Suka,
| 
| So, what should i do finally ?? Drop this ?
Yes, please.

Done. Thanks.

Regards--
Subrata

Quoted 4 lines

Thanks,
Sukadev

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list