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

[Subrata Modak <subrata@linux.vnet.ibm.com>]

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