[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081112161234.GC13269@redhat.com>
Date: Wed, 12 Nov 2008 17:12:34 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: sukadev@...ux.vnet.ibm.com
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Pavel Emelyanov <xemul@...nvz.org>, daniel@...ac.com,
Nadia Derbey <Nadia.Derbey@...l.net>, serue@...ibm.com,
clg@...ibm.com, Containers <containers@...ts.osdl.org>,
sukadev@...ibm.com, linux-kernel@...r.kernel.org
Subject: Re: Signals to cinit
On 11/12, Oleg Nesterov wrote:
>
> On 11/10, sukadev@...ux.vnet.ibm.com wrote:
> >
> > Oleg Nesterov [oleg@...hat.com] wrote:
> > | > Or something. yes, sys_rt_sigqueueinfo() is problematic...
> >
> > Yes, if user-space sets si_pid to 0.
> >
> > Can we change sys_rt_sigqueueinfo() to:
> >
> > if (!info->si_pid)
> > info->si_pid = getpid();
>
> I doubt very much we can do this. This can break the existing applications
> which can overload ->si_pid. I think it is better to pass ->si_pid as is.
> If user-space sends siginfo_t so sub-namespace, it must know what it does.
> I don't think the kernel can help, it just can't know what ->si_pid actually
> means. Unless this is documented somewhere, but I don't know.
On the second thought, I think perhaps we should do the following.
if sys_rt_sigqueueinfo() sends the signal to the sub-namespace, then clear
always ->sid_pid. Otherwise do not touch it.
This way we can't break the existing apps, and this simplifies send_signal()
which should take "is_it_from_ancestor_ns" into account.
What do you think?
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists