Re: [PATCH v2] EDAC: expose per-dimm error counts in sysfs

[Aaron Miller]

The EDAC drivers themselves are reporting the channel and slot counts and dimm config and also doing the decoding of MCEs to map them to a node/channel/slot. If one of those was reporting that an MCE came from a position it had reported earlier did not exist I would say that driver was buggy, since the MCE doesnât contain those as raw values from h/w, they have to be determined by the driver using what it knows about the current memory configuration.

Adding some bound checks might not be a bad idea in this does happen, but you can cause an oops like this by injecting out of bounds without this patch â only added reads it there shouldnât be a way to cause an out-of-bounds read with it.

On 10/28/16, 6:02 AM, "Borislav Petkov" <bp@xxxxxxxxx> wrote:

    On Thu, Oct 27, 2016 at 02:33:32PM -0700, Aaron Miller wrote:
    > The old 'csrowX' sysfs directories had per-csrow error counters, but the
    > new 'dimmX' directories do not currently expose error counts.
    > 
    > EDAC already keeps these counts, add them to sysfs so per-dimm counts
    > are still available when CONFIG_EDAC_LEGACY_SYSFS=n
    > 
    > Signed-off-by: Aaron Miller <aaronmiller@xxxxxx>
    > ---
    
    Hmm, so something's still broken in the adding of the error count,
    especially that dancing around with layers.
    
    Mauro, I think you should take a look. Here's what I did:
    
    EDAC_DFS=/sys/kernel/debug/edac/mc0/
    
    echo 24 > $EDAC_DFS/fake_inject_channel
    echo 0 > $EDAC_DFS/fake_inject_slot
    echo 3 > $EDAC_DFS/fake_inject_count
    
    echo 1 > $EDAC_DFS/fake_inject
    
    24 is the max channels the system reports during start:
    
    [ 4864.030901] EDAC MC: Removed device 0 for sbridge_edac.c Sandy Bridge Socket#0: DEV 0000:3f:0e.0
    [ 4865.867873] EDAC MC: Ver: 3.0.0
    [ 4866.081102] edac_mc_alloc: errcount layer 0 size 8
    [ 4866.086081] edac_mc_alloc: errcount layer 1 size 24
    [ 4866.091133] edac_mc_alloc: allocating 64 error counters
    [ 4866.096529] edac_mc_alloc: allocating 3320 bytes for mci data (24 dimms, 24 csrows/channels)
    								  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    [ 4866.105146] edac_mc_alloc: ce_per_layer[0]: ffff8928b7e918f8
    [ 4866.110979] edac_mc_alloc: ce_per_layer[1]: ffff8928b7e91938
    [ 4866.619521] slot 0 <7>[ 4866.621530] EDAC DEBUG: edac_create_dimm_object: creating rank/dimm device dimm0
    [ 4866.637405] slot 0 <7>[ 4866.639420] EDAC DEBUG: edac_create_dimm_object: creating rank/dimm device dimm3
    [ 4866.655282] slot 0 <7>[ 4866.657288] EDAC DEBUG: edac_create_dimm_object: creating rank/dimm device dimm6
    [ 4866.673168] slot 0 <7>[ 4866.675190] EDAC DEBUG: edac_create_dimm_object: creating rank/dimm device dimm9
    [ 4866.691114] EDAC MC0: Giving out device to module sbridge_edac.c controller Sandy Bridge Socket#0: DEV 0000:3f:0e.0 (INTERRUPT)
    
    and when I do that injection, there's boom, see below.
    
    It looks to me that indexing in edac_inc_ce_error() goes out of bounds:
    
                    mci->ce_per_layer[i][index] += count;
    
                    if (i < mci->n_layers - 1)
                            index *= mci->layers[i + 1].size;
    
    and it shouldn't.
    
    We need to be prepared to handle crap data coming from the hardware so
    those error count adding functions should check array lengths and scream
    if something's overflowing...