All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rishikesh <risrajak@linux.vnet.ibm.com>
To: subrata@linux.vnet.ibm.com
Cc: ltp-list <ltp-list@lists.sourceforge.net>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
	Nadia Derbey <Nadia.Derbey@bull.net>,
	Gowrishankar <gowrishankar.m@linux.vnet.ibm.com>,
	gowrishankar.muthukrishna@gmail.com
Subject: Re: [LTP] [PATCH] testcase pidns20, pidns21 on pid namespace
Date: Tue, 10 Nov 2009 10:46:46 +0530	[thread overview]
Message-ID: <4AF8F73E.10506@linux.vnet.ibm.com> (raw)
In-Reply-To: <1245768501.4860.56.camel@subratamodak.linux.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.

-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

  reply	other threads:[~2009-11-10  5:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
2009-11-11  0:10             ` Serge E. Hallyn
2009-11-11 15:59               ` Subrata Modak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AF8F73E.10506@linux.vnet.ibm.com \
    --to=risrajak@linux.vnet.ibm.com \
    --cc=Nadia.Derbey@bull.net \
    --cc=gowrishankar.m@linux.vnet.ibm.com \
    --cc=gowrishankar.muthukrishna@gmail.com \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=subrata@linux.vnet.ibm.com \
    --cc=sukadev@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.