lkml.org 
[lkml]   [2012]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 3.6-rc6
    Hi Linus,

    Em 22-09-2012 15:57, Linus Torvalds escreveu:
    > On Fri, Sep 21, 2012 at 5:59 PM, Shaun Ruffell <sruffell@digium.com> wrote:
    >>
    >> I posted patches [1,2,3] that resolve the issue for me. Shaohui Xie
    >> also hit the issue and posted a slightly different patch [4]. The
    >> patches are currently waiting for Mauro, who I understand is
    >> catching up since returning from San Diego, to check them out.
    >>
    >> [1] http://marc.info/?l=linux-kernel&m=134764595921752&w=2
    >> [2] http://marc.info/?l=linux-kernel&m=134764594721747&w=2
    >> [3] http://marc.info/?l=linux-kernel&m=134764597921761&w=2
    >> [4] http://marc.info/?l=linux-kernel&m=134753579818528&w=2
    >
    > That first patch needs a sign-off from you, since you are passing on
    > somebody elses patch.
    >
    > Looking at that patch, the patch seems to be a memory leak (?) leaking
    > the "channels" allocation, along with fixing an odd and incorrect
    > kfree (and access) of mci->csrows[i]. If that is correct, please write
    > a proper changelog. The current changelog for that thing is totally
    > pointless, and doesn't actually explain what the patch *does*.
    >
    > I'd also like some ack's from people, and I'd love to know which
    > commit introduced the problem(s). If this problem is new to 3.6, I
    > want to know what caused it, and if it is *not* new, then the thing
    > needs to be marked for stable. Please?

    This was caused by the edac core rewrite I made, merged for 3.6, that
    replaced the usage of raw kobj in order to use, instead, struct device.

    I tested the patches on several machines and they're OK. It took
    me some time to test them, as I got flooded with ~400 patches for
    review while I was out for KS/2012... It is taking some time for me to
    dig into each of them, especially since I hit into some internal dead
    lines.

    The good news is that we are equipping several machines at Red Hat labs
    with different memory configurations, with is allowing us to do a
    comprehensive testset on the EDAC x86 drivers. We've got already
    some longstanding bugs there, as well as a few recent regressions.

    So, in addition to the bugs noticed by Shaun and Fengguang,
    I also got bug fixes for 3 EDAC drivers (sb_edac, i3200 and i5000).

    > Finally, if I'm supposed to apply patches, I really *really* want to
    > see the patches sent to me explicitly, instead of having people post
    > pointers to them on the web. I don't apply random stuff on the web, I
    > want the "please take this patch" to be a case of people *explicitly*
    > sending it to me with the proper sign-offs in place etc.
    >
    > IOW, the "hey, you should apply that random patch that wasn't even
    > sent to you" approach is not something I accept.

    I just updated the patches today on my git tree (so, they should be
    popping up tomorrow at -next).

    So, I will send you tomorrow a pull request with all fixes I'm aware
    of for edac, after the -next merging.

    If you prefer otherwise to merge them today, you can get those patches
    with my SOB at:

    git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac.git master


    Thanks!
    Mauro

    -

    The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:

    Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)

    are available in the git repository at:

    git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac.git master

    for you to fetch changes up to ded6223cfb75c4b5f61a285eee10df98a0291460:

    sb_edac: Avoid overflow errors at memory size calculation (2012-09-23 10:16:36 -0300)

    ----------------------------------------------------------------
    Fengguang Wu (1):
    edac_mc: fix kfree calls in the error path

    Mauro Carvalho Chehab (3):
    i3200_edac: Fix memory rank size
    i5000: Fix the memory size calculation with 2R memories
    sb_edac: Avoid overflow errors at memory size calculation

    Shaun Ruffell (2):
    edac: edac_mc_free() cannot assume mem_ctl_info is registered in sysfs
    edac: edac_mc no longer deals with kobjects directly




    \
     
     \ /
      Last update: 2012-09-23 16:01    [W:0.029 / U:1.068 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site