* Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace [not found] ` <1234762145.7791.13.camel@subratamodak.linux.ibm.com> @ 2009-06-23 14:48 ` Subrata Modak 2009-11-10 5:16 ` Rishikesh 0 siblings, 1 reply; 4+ messages in thread From: Subrata Modak @ 2009-06-23 14:48 UTC (permalink / raw) To: Sukadev Bhattiprolu, Gowrishankar Cc: ltp-list, Nadia Derbey, gowrishankar.muthukrishna 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace 2009-06-23 14:48 ` [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace Subrata Modak @ 2009-11-10 5:16 ` Rishikesh 2009-11-11 0:10 ` Serge E. Hallyn 0 siblings, 1 reply; 4+ messages in thread From: Rishikesh @ 2009-11-10 5:16 UTC (permalink / raw) To: subrata Cc: ltp-list, Sukadev Bhattiprolu, Nadia Derbey, Gowrishankar, gowrishankar.muthukrishna 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace 2009-11-10 5:16 ` Rishikesh @ 2009-11-11 0:10 ` Serge E. Hallyn 2009-11-11 15:59 ` Subrata Modak 0 siblings, 1 reply; 4+ messages in thread From: Serge E. Hallyn @ 2009-11-11 0:10 UTC (permalink / raw) To: Rishikesh Cc: ltp-list, Gowrishankar, gowrishankar.muthukrishna, Sukadev Bhattiprolu, Nadia Derbey 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace 2009-11-11 0:10 ` Serge E. Hallyn @ 2009-11-11 15:59 ` Subrata Modak 0 siblings, 0 replies; 4+ messages in thread From: Subrata Modak @ 2009-11-11 15:59 UTC (permalink / raw) To: Serge E. Hallyn Cc: ltp-list, Gowrishankar, gowrishankar.muthukrishna, Sukadev Bhattiprolu, Nadia Derbey 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-11-11 16:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4948C6E4.8080801@linux.vnet.ibm.com>
[not found] ` <49491512.9000905@linux.vnet.ibm.com>
[not found] ` <1229578051.5149.11.camel@subratamodak.linux.ibm.com>
[not found] ` <20090214203139.GA10969@us.ibm.com>
[not found] ` <1234762145.7791.13.camel@subratamodak.linux.ibm.com>
2009-06-23 14:48 ` [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace Subrata Modak
2009-11-10 5:16 ` Rishikesh
2009-11-11 0:10 ` Serge E. Hallyn
2009-11-11 15:59 ` Subrata Modak
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox