Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace

Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace

[Subrata Modak]

On Mon, 2009-02-16 at 10:59 +0530, Subrata Modak wrote: 
> Thanks Suka,
> 
> On Sat, 2009-02-14 at 12:31 -0800, Sukadev Bhattiprolu wrote:
> > Subrata Modak [subrata@linux.vnet.ibm.com] wrote:
> > | 
> > | > > pidns21:
> > | > >    The pidns21.c testcase verifies that container-init is terminated
> > | > >    by SIGUSR1 when:
> > | > >       - a handler is specified for SIGUSR1,
> > | > >       - container-init blocks SIGUSR1,
> > | > >       - parent queues SIGUSR1 and
> > | > >       - handler for SIGUSR1 is set to system default before SIGUSR1 is 
> > | > > unblocked.
> > 
> > I know I had acked this test before, but back then the actual implementation
> > of the signal semantics in the kernel were not complete.
> > 
> > To simplify the implementation of the semantics, it was decided that
> > SIGKILL/SIGSTOP would be the only reliable signals from a parent
> > container. IOW, container-init would ignore SIGUSR1 or SIGINT, SIGQUIT
> > etc even if sent from a parent container.
> > 
> > See patchset/discussion:
> > 
> > 	http://lkml.org/lkml/2009/1/17/131
> > 
> > (which is not yet merged, but appears to be close to consensus)
> > 
> > The  rationale for this simplification is that any serious
> > 'container-init' would explicitly SIG_IGN all signals that it is
> > not interested in. So the only signals that would be in SIG_DFL
> > state would be SIGKILL/SIGSTOP.
> > 
> > Effectively, testcase pidns21 will fail if/when the above patchset
> > (specifically, patch 5/6) is merged.
> 
> Gowri,
> 
> Kindly update this test when the patch makes into next stable kernel
> release.

Suka/Gowri,

Are we still looking into these tests ?

Regards--
Subrata

> 
> Regards--
> Subrata
> 
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace

[Rishikesh]

Subrata Modak wrote:
> On Mon, 2009-02-16 at 10:59 +0530, Subrata Modak wrote: 
>   
>> Thanks Suka,
>>
>> On Sat, 2009-02-14 at 12:31 -0800, Sukadev Bhattiprolu wrote:
>>     
>>> Subrata Modak [subrata@linux.vnet.ibm.com] wrote:
>>> | 
>>> | > > pidns21:
>>> | > >    The pidns21.c testcase verifies that container-init is terminated
>>> | > >    by SIGUSR1 when:
>>> | > >       - a handler is specified for SIGUSR1,
>>> | > >       - container-init blocks SIGUSR1,
>>> | > >       - parent queues SIGUSR1 and
>>> | > >       - handler for SIGUSR1 is set to system default before SIGUSR1 is 
>>> | > > unblocked.
>>>
>>> I know I had acked this test before, but back then the actual implementation
>>> of the signal semantics in the kernel were not complete.
>>>
>>> To simplify the implementation of the semantics, it was decided that
>>> SIGKILL/SIGSTOP would be the only reliable signals from a parent
>>> container. IOW, container-init would ignore SIGUSR1 or SIGINT, SIGQUIT
>>> etc even if sent from a parent container.
>>>
>>> See patchset/discussion:
>>>
>>> 	http://lkml.org/lkml/2009/1/17/131
>>>
>>> (which is not yet merged, but appears to be close to consensus)
>>>
>>> The  rationale for this simplification is that any serious
>>> 'container-init' would explicitly SIG_IGN all signals that it is
>>> not interested in. So the only signals that would be in SIG_DFL
>>> state would be SIGKILL/SIGSTOP.
>>>
>>> Effectively, testcase pidns21 will fail if/when the above patchset
>>> (specifically, patch 5/6) is merged.
>>>       
>> Gowri,
>>
>> Kindly update this test when the patch makes into next stable kernel
>> release.
>>     
>
> Suka/Gowri,
>
> Are we still looking into these tests ?
>   


Anyone still looking into it ? Still i am getting failure for pidns21 
with latest ltp release.

-Rishi
> Regards--
> Subrata
>
>   
>> Regards--
>> Subrata
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Ltp-list mailing list
>> Ltp-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ltp-list
>>     
>
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
>   


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace

[Serge E. Hallyn]

Quoting Rishikesh (risrajak@linux.vnet.ibm.com):
> Subrata Modak wrote:
> > On Mon, 2009-02-16 at 10:59 +0530, Subrata Modak wrote: 
> >   
> >> Thanks Suka,
> >>
> >> On Sat, 2009-02-14 at 12:31 -0800, Sukadev Bhattiprolu wrote:
> >>     
> >>> Subrata Modak [subrata@linux.vnet.ibm.com] wrote:
> >>> | 
> >>> | > > pidns21:
> >>> | > >    The pidns21.c testcase verifies that container-init is terminated
> >>> | > >    by SIGUSR1 when:
> >>> | > >       - a handler is specified for SIGUSR1,
> >>> | > >       - container-init blocks SIGUSR1,
> >>> | > >       - parent queues SIGUSR1 and
> >>> | > >       - handler for SIGUSR1 is set to system default before SIGUSR1 is 
> >>> | > > unblocked.
> >>>
> >>> I know I had acked this test before, but back then the actual implementation
> >>> of the signal semantics in the kernel were not complete.
> >>>
> >>> To simplify the implementation of the semantics, it was decided that
> >>> SIGKILL/SIGSTOP would be the only reliable signals from a parent
> >>> container. IOW, container-init would ignore SIGUSR1 or SIGINT, SIGQUIT
> >>> etc even if sent from a parent container.
> >>>
> >>> See patchset/discussion:
> >>>
> >>> 	http://lkml.org/lkml/2009/1/17/131
> >>>
> >>> (which is not yet merged, but appears to be close to consensus)
> >>>
> >>> The  rationale for this simplification is that any serious
> >>> 'container-init' would explicitly SIG_IGN all signals that it is
> >>> not interested in. So the only signals that would be in SIG_DFL
> >>> state would be SIGKILL/SIGSTOP.
> >>>
> >>> Effectively, testcase pidns21 will fail if/when the above patchset
> >>> (specifically, patch 5/6) is merged.
> >>>       
> >> Gowri,
> >>
> >> Kindly update this test when the patch makes into next stable kernel
> >> release.
> >>     
> >
> > Suka/Gowri,
> >
> > Are we still looking into these tests ?
> >   
> 
> 
> Anyone still looking into it ? Still i am getting failure for pidns21 
> with latest ltp release.

The patch in question is upstream, so pidns21.c will always
fail and should be removed from ltp.

It's worth testing that the container init survives SIGUSR1
from a child, but whether it survives or dies from a parent
we don't particularly care.

-serge

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace

[Subrata Modak]

On Tue, 2009-11-10 at 18:10 -0600, Serge E. Hallyn wrote: 
> Quoting Rishikesh (risrajak@linux.vnet.ibm.com):
> > Subrata Modak wrote:
> > > On Mon, 2009-02-16 at 10:59 +0530, Subrata Modak wrote: 
> > >   
> > >> Thanks Suka,
> > >>
> > >> On Sat, 2009-02-14 at 12:31 -0800, Sukadev Bhattiprolu wrote:
> > >>     
> > >>> Subrata Modak [subrata@linux.vnet.ibm.com] wrote:
> > >>> | 
> > >>> | > > pidns21:
> > >>> | > >    The pidns21.c testcase verifies that container-init is terminated
> > >>> | > >    by SIGUSR1 when:
> > >>> | > >       - a handler is specified for SIGUSR1,
> > >>> | > >       - container-init blocks SIGUSR1,
> > >>> | > >       - parent queues SIGUSR1 and
> > >>> | > >       - handler for SIGUSR1 is set to system default before SIGUSR1 is 
> > >>> | > > unblocked.
> > >>>
> > >>> I know I had acked this test before, but back then the actual implementation
> > >>> of the signal semantics in the kernel were not complete.
> > >>>
> > >>> To simplify the implementation of the semantics, it was decided that
> > >>> SIGKILL/SIGSTOP would be the only reliable signals from a parent
> > >>> container. IOW, container-init would ignore SIGUSR1 or SIGINT, SIGQUIT
> > >>> etc even if sent from a parent container.
> > >>>
> > >>> See patchset/discussion:
> > >>>
> > >>> 	http://lkml.org/lkml/2009/1/17/131
> > >>>
> > >>> (which is not yet merged, but appears to be close to consensus)
> > >>>
> > >>> The  rationale for this simplification is that any serious
> > >>> 'container-init' would explicitly SIG_IGN all signals that it is
> > >>> not interested in. So the only signals that would be in SIG_DFL
> > >>> state would be SIGKILL/SIGSTOP.
> > >>>
> > >>> Effectively, testcase pidns21 will fail if/when the above patchset
> > >>> (specifically, patch 5/6) is merged.
> > >>>       
> > >> Gowri,
> > >>
> > >> Kindly update this test when the patch makes into next stable kernel
> > >> release.
> > >>     
> > >
> > > Suka/Gowri,
> > >
> > > Are we still looking into these tests ?
> > >   
> > 
> > 
> > Anyone still looking into it ? Still i am getting failure for pidns21 
> > with latest ltp release.
> 
> The patch in question is upstream, so pidns21.c will always
> fail and should be removed from ltp.

Ok. I did that just now.

Regards--
Subrata

> 
> It's worth testing that the container init survives SIGUSR1
> from a child, but whether it survives or dies from a parent
> we don't particularly care.
> 
> -serge


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list