Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031664AbaGDWt2 (ORCPT ); Fri, 4 Jul 2014 18:49:28 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:57338 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030527AbaGDWUS (ORCPT ); Fri, 4 Jul 2014 18:20:18 -0400 From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alex Smith , linux-mips@linux-mips.org, Ralf Baechle Subject: [PATCH 3.14 14/59] recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules Date: Fri, 4 Jul 2014 15:19:03 -0700 Message-Id: <20140704221540.209045415@linuxfoundation.org> X-Mailer: git-send-email 2.0.1 In-Reply-To: <20140704221539.544876024@linuxfoundation.org> References: <20140704221539.544876024@linuxfoundation.org> User-Agent: quilt/0.63-1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alex Smith commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream. 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: Alex Smith Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7098/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman --- scripts/recordmcount.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/scripts/recordmcount.h +++ b/scripts/recordmcount.h @@ -163,11 +163,11 @@ static int mcount_adjust = 0; static int MIPS_is_fake_mcount(Elf_Rel const *rp) { - static Elf_Addr old_r_offset; + static Elf_Addr old_r_offset = ~(Elf_Addr)0; Elf_Addr current_r_offset = _w(rp->r_offset); int is_fake; - is_fake = old_r_offset && + is_fake = (old_r_offset != ~(Elf_Addr)0) && (current_r_offset - old_r_offset == MIPS_FAKEMCOUNT_OFFSET); old_r_offset = current_r_offset; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/