On Fri, Feb 12, 2010 at 11:17 AM, Garrett Cooper <[email protected]> wrote:
> On Fri, Feb 12, 2010 at 9:51 AM, Serge E. Hallyn <[email protected]> wrote:
>> Quoting Mitani ([email protected]):
>>> Hi,
>>>
>>> I tried to test with "2010-02-11" cvs in RHEL5.4 system.
>>> But the test brings termination of connection.
>>>
>>> I examined the phenomenon and discovered that "pidns17" test made
>>> accident and sshd stopped after the test.
>>>
>>>
>>> I had some problems.
>>>
>>> 1. I think that "tst_exit()" must be added last of "cleanup()"
>>>    function.
>>> ============
>>> --- ./testcases/kernel/containers/pidns/pidns17.c       2009-12-07
>>> 05:55:16.000000000 +0900
>>> +++ ./testcases/kernel/containers/pidns/pidns17.c.new   2010-02-12
>>> 16:26:31.000000000 +0900
>>> @@ -104,7 +104,6 @@
>>>
>>>         /* cleanup and exit */
>>>         CLEANUP();
>>> -       tst_exit();
>>>  }
>>>
>>>  /***********************************************************************
>>> @@ -136,7 +135,6 @@
>>>
>>>         /* cleanup and exit */
>>>         CLEANUP();
>>> -       tst_exit();
>>>  }      /* End main */
>>>
>>>  /*
>>> @@ -147,4 +145,5 @@
>>>  {
>>>         /* Clean the test testcase as LTP wants*/
>>>         TEST_CLEANUP;
>>> +       tst_exit();
>>>  }
>>
>> Yeah I'm afraid I don't understand what CLEANUP and tst_exit exactly
>> do.  Hopefully Garrett can give an educated answer.
>
> Mitani's correct -- this is what should be done... CLEANUP is a
> constant that maps to cleanup in the event that tst_brkm is called,
> because linux_syscall_numbers.h's copy of syscall calls tst_brkm
> internally if ENOSYS is returned...
>
>>> ============
>>>
>>> After revision, connection termination didn't occur.
>>>
>>>
>>> 2. I cannot understand the purpose that "kill()" function whose
>>>    first parameter is "-1" is called.
>>> ------------
>>>         if (kill(-1, SIGUSR1) == -1) {
>>>                 tst_resm(TBROK | TERRNO, "cinit: kill(-1, SIGUSR1) failed");
>>>                 CLEANUP();
>>>         }
>>> ------------
>>>
>>> If kill()'s first option is "-1", "man kill" says that
>>> "All processes with pid larger than 1 will be signaled."
>>
>> Right, the test is checking whether kill -1 inside a private pidns
>> kills all processes besides init in the pid namespace.
>
> Yeah, that's just not smart...
>
>>> Therefore, not only the "sshd" but also the other processes were
>>> affected, I think.
>>
>> sshd is not in the private pid namespace and should not be killed.
>> If it is being killed by the pid -1 inside the container, then there
>> is a kernel bug.
>
> No, it isn't. If the test is being run as root it'll force a reboot on the 
> box:
>
>     If pid is -1:
>             If the user has super-user privileges, the signal is sent to all
>             processes excluding system processes (with P_SYSTEM flag set),
>             process with ID 1 (usually init(8)), and the process sending the
>             signal.  If the user is not the super user, the signal is sent to
>             all processes with the same uid as the user excluding the process
>             sending the signal.  No error is returned if any process could be
>             signaled.

Oh wait.. containers isolate PIDs and resources, correct (a weak form
of BSD jails or Solaris zones)? If so, then I'd watch the console //
/var/log/messages, etc and see whether or not things stay alive after
the signal is tossed...

>>> I'm glad if I could get some opinions.
>
>    I'll look at fixing this testcase once the cvs tree has been fully
> converted to git by Rishikesh, as the points you've made are important
> and valid...

Thanks,
-Garrett

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to