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

[Li Zefan]

On 2013/7/19 2:00, Greg KH wrote:
> On Thu, Jul 18, 2013 at 09:25:22PM +0800, Li Zefan wrote:
>> 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?
> 
> I want to do whatever is possible to ensure that known bug fixes for
> issues like what you have documented here, end up in the stable trees.

As we don't want to add extra burden to maintainers, that seems leave not much
space for improvement.

There's one improvement that I can think of. Most developers and maintainers
just tag a patch with "Cc: stable <...>" without caring about exactly which
versions are affected by the bug. I think when a commit in this kind can be
applied to not all but some versions, the patch sent for review can include a
note saying "The upstgream commit has a stable tag without specifying explicit
versions, but it can't be applied to 3.0 and 3.4, so you may want to check if
the fix is applicable to older versions...".

Take an example, there're 364 commits from 3.9 to 3.10 with stable tag, and
298 commits without specifying versions, and that's 82%, so there's always
possibility that a commit in this kind won't be applied to older kernels
and it's ignored because no notice is sent.

Another possible improvement is, we can teach checkpatch.pl to check invalid
stable tag format. I guess you'll have to manually handle the commit if your
script fails to parse the tag line?

> If there's anything I can do to talk to the team of people that you
> describe above as doing this type of work, yet not telling me about it,
> I would be more than willing to do so.

I think they are focusing on 2.6.32 and 2.6.34 kernels, which are not maintained
by you. :)