• Alex Smith's avatar
    recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules · 91ad11d7
    Alex Smith authored
    On MIPS calls to _mcount in modules generate 2 instructions to load
    the _mcount address (and therefore 2 relocations). The mcount_loc
    table should only reference the first of these, so the second is
    filtered out by checking the relocation offset and ignoring ones that
    immediately follow the previous one seen.
    
    However if a module has an _mcount call at offset 0, the second
    relocation would not be filtered out due to old_r_offset == 0
    being taken to mean that the current relocation is the first one
    seen, and both would end up in the mcount_loc table.
    
    This results in ftrace_make_nop() patching both (adjacent)
    instructions to branches over the _mcount call sequence like so:
    
      0xffffffffc08a8000:  04 00 00 10     b       0xffffffffc08a8014
      0xffffffffc08a8004:  04 00 00 10     b       0xffffffffc08a8018
      0xffffffffc08a8008:  2d 08 e0 03     move    at,ra
      ...
    
    The second branch is in the delay slot of the first, which is
    defined to be unpredictable - on the platform on which this bug was
    encountered, it triggers a reserved instruction exception.
    
    Fix by initializing old_r_offset to ~0 and using that instead of 0
    to determine whether the current relocation is the first seen.
    Signed-off-by: default avatarAlex Smith <alex.smith@imgtec.com>
    Cc: linux-kernel@vger.kernel.org
    Cc: stable@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/7098/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
    91ad11d7
recordmcount.h 16.4 KB