[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090519133245.GB14782@redhat.com>
Date: Tue, 19 May 2009 15:32:45 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kernel Testers List <kernel-testers@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Kumar Gala <galak@...nel.crashing.org>,
Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
Roland McGrath <roland@...hat.com>
Subject: Re: [Bug #13107] LTP 20080131 causes defunct processes w/2.6.30-rc1
On 05/19, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@...hat.com> wrote:
>
> > And I don't think the kernel is buggy, this is expected behaviour.
> > With this commit (actually, there were several patches) /sbin/init
> > respects SIGSTOP if the caller has rights to send it, this change
> > is intentional. I'd even say this is fix.
> >
> > Note that even root can't stop init, SIGSTOP should be sent from
> > the parent namespace, or from ptracer. And ptracer could obviously
> > ptrace_stop() init even before this patch.
>
> There's one important aspect here: _if_ a change results in
> user-space visible behavioral change, it does not matter how correct
> it is in the grand scheme of things. (beyond plain bugfixes solving
> crashes, etc.) What matters is whether there's any app out there
> that might possibly rely on the old behavior.
>
> The LTP testcase might be synthetic, and it could be fixed and the
> commit might even end up being correct - but some thought should be
> expended on compatibility and real-life impact (and scope) here -
> not just on strict 'correctness'.
Yes, agreed.
But hopefully in this case we can't break the user-space. Because the
tracing of /sbin/init is special, and this was forbidden till 2.6.25.
Not only you can make the system unusable, it is very easy to crash
the kernel if you trace init. I don't think any "good" app can rely
on the wrong old behaviour, but of course any behavioral change is
dangerous.
And please note that the old behaviour was known to be wrong. If we
take the sub-namespace inits into account, it was very wrong. Of course,
we can add the special is_global_init() hack to preserve the current
behaviour at least for the root namespace, but this doesn't look good.
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