lkml.org 
[lkml]   [2014]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [STABLE] find missing bug fixes in a stable kernel
    On Mon, Jan 13, 2014 at 03:28:11PM +0800, Li Zefan wrote:
    > We have several long-term and extended stable kernels, and it's possible
    > that a bug fix is in some stable versions but is missing in some other
    > versions, so I've written a script to find out those fixes.
    >
    > Take 3.4.xx and 3.2.xx for example. If a bug fix was merged into upstream
    > kernel after 3.4, and then it was backported to 3.2.xx, then it probably
    > needs to be backported to 3.4.xx.

    I agree.

    > The result is, there're ~430 bug fixes in 3.2.xx that probably need to be
    > backported to 3.4.xx. Given there're about 4500 commits in 3.2.xx, that
    > is ~10%, which is quite a big number for stable kernels.

    That's a really big number, how am I missing so many patches for the 3.4
    kernel? Is it because people are doing backports to 3.2 for patches
    that didn't apply to 3.4? Or are these patches being applied that do
    not have -stable markings on them? Or something else?

    > We (our team in Huawei) are going to go through the whole list to filter
    > out fixes that're applicable for 3.4.xx.
    >
    > I've attached the lists for 3.4 and 3.10.

    The list format doesn't seem to make much sense, care to explain it a
    bit better?

    >
    > If a commit ID appears more than once in changelogs, it's possible that's
    > because the commit was reverted later, so I tagged this kind of commits
    > in the lists.

    > [upstream commit] [stable commit] [occurrences]
    > 8c4f3c3fa968 874d3954a35c 2 1

    I'll use this as an example, this patch was not marked for -stable
    backporting, yet it showed up in the 3.2-stable tree. Why?

    And what does the [occurrences] column mean?

    confused,

    greg k-h


    \
     
     \ /
      Last update: 2014-01-13 19:41    [W:2.275 / U:0.552 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site