"Serge E. Hallyn" <serge.hal...@canonical.com> writes: > Quoting Ferenc Wagner (wf...@niif.hu): >> "Serge E. Hallyn" <serge.hal...@canonical.com> writes: >> >>> Quoting Daniel Lezcano (daniel.lezc...@free.fr): >>> >>>> On 08/31/2010 12:23 AM, Serge E. Hallyn wrote: >>>> >>>>> Quoting Daniel Lezcano (daniel.lezc...@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 sta...@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. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
