[Lxc-users] unstoppable container

[Ferenc Wagner]

"Serge E. Hallyn" <serge.hallyn at canonical.com> writes:

> Quoting Ferenc Wagner (wferi at niif.hu):
>> "Serge E. Hallyn" <serge.hallyn at canonical.com> writes:
>> 
>>> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>>>
>>>> On 08/31/2010 12:23 AM, Serge E. Hallyn wrote:
>>>>
>>>>> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>>>>>
>>>>>> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=13aa9a6b0f2371d2ce0de57c2ede62ab7a787157
>>>>>> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=dd34200adc01c5217ef09b55905b5c2312d65535
>>>>
>>>> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=614c517d7c00af1b26ded20646b329397d6f51a1
>>>>
>>>>>> Are they small enough for a SRU ?
>>>>>
>>>>> The first one looks trivial enough.  I'd be afraid the second one would be
>>>>> considered to have deep and subtle regression potential.  But, we can
>>>>> always try.  I'm not on the kernel team so am not likely to have any say
>>>>> on it myself :)
>>>> 
>>>> Shall we ask directly to the kernel-team@ mailing list? Or do we
>>>> have to do a SRU first ?
>>>
>>> Actually, first step would be for Papp to open a bug against both
>>> lxc and the kernel.  Papp, do you mind doing that?
>>>
>>> Without a bug, an SRU ain't gonna fly.
>> 
>> I'm not sure what an SRU is, is that something Ubuntu-specific?  I'd
>
> Yes, specific to Ubuntu LTS (long term support) releases.

Thanks for the clarification.

>> appreciate instead going through stable at kernel.org, so that everybody
>> benefits from this backporting effort.
>
> TBH, looking at the commit messages, it might be tough to make the case
> for -stable.  They sure make the patches sound fluffy.

I can't judge whether these patches (however small) bear a considerable
risk.  They change a small thing in the deep, as I see it.

> And since the problem can be worked around in userspace

Do you mean by hunting down the orphaned processes based on the cgroup
tasks files?

> I'm not sure the following rule:
>
> - It must fix a problem that causes a build error (but not for things
>   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>   security issue, or some "oh, that's not good" issue.  In short,
>   something critical.
>
> from Documentation/stable_kernel_rules.txt is satisfied.

Well, I really don't know.  Leaving stray processes in a container
sounds bad to me, but maybe not exactly critical...  I haven't got much
experience with -stable.

> But if you all prefer to try that route first I'll certainly not
> object.

It'd certainly help to present a concise and to-the-point summary why we
need this in -stable.  If you feel this is hopeless, then forget it,
otherwise I'd very much appreciate your help on this issue.
-- 
Thanks,
Feri.