[Ksummit-2013-discuss] [ATTEND] stable patches; cgroup changes

Li Zefan lizefan at huawei.com
Thu Jul 18 13:25:22 UTC 2013


Hi,

I would like to attend this year's Kernel Summit.

I'm co-maintaining cgroup and cpuset with Tejun. In Huawei I'm working in
the kernel team, and I'm responsible for maintaining our kernels.

I'm mostly interested in the following two topics.

(1) stable patches

Some departments have been analyzing upstream commits and see if some of them
are not in stable tree but can/should be backported, but they never feedback
the result to the community.

While in the kernel team I'm working in, we have been much more open, and we've
started to help patch backport in stable mailing list.

While Greg has been doing great, one of my observation is we do have some upstream
commits missing from stable tree for various reasons:

- some developers/maintainers don't care about stable branches;
- people have different criterion on what patches should be queued for stable;
- the patch can't be applied cleanly, and then no one pays attention to the
notice sent by Greg;
- if the patch can be applied to most recent stable version, but failed on earlier
verions, you won't be warned.

For example, the bugs fixed in these two commits can crash the kernel, but they are
not tagged for stable:

	9c5da09d266ca9b32eb16cf940f8161d949c2fe5
	a6572f84c5b135d9b6df279ed3c8de028bd1edd9

commit 6a76f8c0ab19f215af2a3442870eeb5f0e81998d is a CVE fix and was queued for 3.8,
but missing from 3.4. (then I did the backport)

commit 14611e51a57df10240817d8ada510842faf0ec51 has been queued for 3.10 only, but
actually the bug exists in older verions too. (I'm planning to do the backport)

So are we happy with the current status, or do we need to do something so that
less bug fixes are missing in stable?


(2) cgroup changes

>From my eyes, the most contentious issues are:

a) unified hierarchy

When unified hierarchy was proposed last year, we didn't get many/strong objections.
As we're getting closer to this plan, more and more people stand up and express their
objections/concerns/worries. This will change user interface, though some users can
adapt the new interface but they may be reluctant or can't for some reason. The
most difficult part is, some users (e.g. Google) claim multi hierarhy is a must.

b) disallow threads be put in different cgroups

At least Libvirt has strong feeling against this planned change.

c) a central daemon to monopolize cgroups

As cgroup knobs are too tied to the internal implementation (similar with sysctl),
we want a userspace daemon to access cgroupfs exclusvely, and others can talk with
this daemon only. Two issues are concerened:

- Can this daemon satisfy all the workloads/requirements?
- Will this daemon be systemd?

Other changes or planned changes in cgroup are generally welcomed I think.


More information about the Ksummit-2013-discuss mailing list