Date: Fri, 14 Nov 2008 18:26:33 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
       Pavel Emelyanov <xemul@openvz.org>, daniel@hozac.com,
       Nadia Derbey <Nadia.Derbey@bull.net>, serue@us.ibm.com, clg@fr.ibm.com,
       Containers <containers@lists.osdl.org>, sukadev@us.ibm.com,
       linux-kernel@vger.kernel.org
Subject: Re: Signals to cinit
Message-ID: <20081114172633.GA10508@redhat.com>
References: <20081101180505.GA24268@us.ibm.com> <20081110173839.GA11121@redhat.com> <20081110193228.GA15519@redhat.com> <20081111022405.GB20891@us.ibm.com> <20081112150555.GB13269@redhat.com> <20081112190421.GE3230@us.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20081112190421.GE3230@us.ibm.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1944
Lines: 55

On 11/12, Sukadev Bhattiprolu wrote:
>
> Oleg Nesterov [oleg@redhat.com] wrote:
>
> | On 11/10, sukadev@linux.vnet.ibm.com wrote:
> | >
> | > Also, what happens if a fatal signal is first received from a descendant
> | > and while that is still pending, the same signal is received from ancestor
> | > ns ?  Won't the second one be ignored by legacy_queue() for the non-rt case ?
>
> On second thoughts, cinit is a normal process in its ancestor ns so it
> might very well ignore the second instance of the signal (as long as it
> does not ignore SIGKILL/SIGSTOP)
>
> |
> | Please see my another email:
> |
> | 	We must also change sig_ignored() to drop SIGKILL/SIGSTOP early when
> | 	it comes from the same ns. Otherwise, it can mask the next SIGKILL
> | 	from the parent ns.
>
> Ok.
>
> |
> | 	But this perhaps makes sense anyway, even without containers.
> | 	Currently, when the global init has the pending SIGKILL, we can't
> | 	trust __wait_event_killable/etc, and this is actually wrong.
> |
> | We can drop other SIG_DFL signals from the same namespace early as well.
>
> I think Eric's patchset did this and iirc, we ran into the problem of
> blocked SIG_DFL signals ?

Yes sure, I meant unblocked SIG_DFL signals. But SIGKILL can't be
blocked fortunately.

Again, the parent ns can't rely on, say, SIGTERM. It can be missed
if cinit has a handler, we can do nothing in this case. And if it
is blocked, most probably cinit already has a handler, or it will
set it later, say, after exec. Or it can be just ignored.

> | Or, we can just ignore this (imho) minor problem.
>
> I think so too.

Great, so perhaps we can ignore the problem for now, and fix it
later if the need arises.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/