Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp1125671ybd; Wed, 26 Jun 2019 11:38:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqzjjg0Bw/gbFoKRzVVCrLijH4lQuAALWP+6RO3/BnvJPdj1A2JJzJ6smV/auO7dip8svIpD X-Received: by 2002:a17:902:bcc4:: with SMTP id o4mr6998526pls.90.1561574323220; Wed, 26 Jun 2019 11:38:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561574323; cv=none; d=google.com; s=arc-20160816; b=adV3lQdfTNCB+ROq76/eISwNXnKEdAQwDEPJjO17WbxqeHNpcP+Bk9ahGBWub/rmMi KMFCSoTDPrEoF2v/v1O4cPRe4YgvTm5+ZESx9OfbJyWCJYELpN/00+RO0NhUy8j8tEEN 3XeRWa6XXG0FBr1vteaH+LRkeYLrEJ3Yk5Zm5O5q7qSbWhp0VmMuUie1BBu8w1ad0lg2 Q+mgmD7vpV30UYFAhZ7b4DUTFQbCQ5sEVci42GQPn/8/UVYEsvjSDwAd/onUG8jTauxG EABxaCkt/2FHJ/AE9uoaOdWssqGS9PQzIGTQjkh2K+TKO/mibzzBIz6UeGNZ3KNw0fp1 ZW4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :mime-version:date:subject:cc:to:from; bh=i1+vc34i+uwPRe67UqA6FXLVvFBynMzQ67qHJ26N62g=; b=eoVVBaeWeEm7GcU2+Y0RLDG0mUx3ZJu2hFhuul4dUlfE6Vx7nvZf0P5n4TdL4/pnS1 d63vztAaQpo6eTpE5Q1VIQ4IZaagLhUzLZuYC1Tx5HCYB6fZLnpJ3/eJPDPyYr7zrggq ykFtSWrCHsNODmdmuZZHEZOlNCViqCBGlorbF7LOGK3A9c4kqrTAIdrJhYq60YaIzTM9 beAN88AnPGwoGOGY5Xb0aisnYR/9Rryi2f+gy/Yh6vuEtS8Y5Aasxcfz5YcpLpVBdIhu nxj3z5xGLenljLyRpQkVWoth8T26+QtbvN6xE86AhU5uEg5jcOxZwvan6WEwF74HjmGT 2P2g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d5si4048148pla.17.2019.06.26.11.38.26; Wed, 26 Jun 2019 11:38:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726439AbfFZSiU (ORCPT + 99 others); Wed, 26 Jun 2019 14:38:20 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:12792 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726104AbfFZSiU (ORCPT ); Wed, 26 Jun 2019 14:38:20 -0400 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5QIc0Tr063808 for ; Wed, 26 Jun 2019 14:38:19 -0400 Received: from e06smtp03.uk.ibm.com (e06smtp03.uk.ibm.com [195.75.94.99]) by mx0b-001b2d01.pphosted.com with ESMTP id 2tccxab3t2-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 26 Jun 2019 14:38:18 -0400 Received: from localhost by e06smtp03.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 26 Jun 2019 19:38:17 +0100 Received: from b06avi18626390.portsmouth.uk.ibm.com (9.149.26.192) by e06smtp03.uk.ibm.com (192.168.101.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 26 Jun 2019 19:38:14 +0100 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x5QIc38d38470086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Jun 2019 18:38:03 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 001FE42041; Wed, 26 Jun 2019 18:38:12 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 228E542047; Wed, 26 Jun 2019 18:38:11 +0000 (GMT) Received: from naverao1-tp.ibmuc.com (unknown [9.85.84.174]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 26 Jun 2019 18:38:10 +0000 (GMT) From: "Naveen N. Rao" To: Michael Ellerman , Steven Rostedt , Christophe Leroy Cc: , Subject: [PATCH] recordmcount: Fix spurious mcount entries on powerpc Date: Thu, 27 Jun 2019 00:08:01 +0530 X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 19062618-0012-0000-0000-0000032CA849 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19062618-0013-0000-0000-00002165E37F Message-Id: <20190626183801.31247-1-naveen.n.rao@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-26_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906260215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The recent change enabling HAVE_C_RECORDMCOUNT on powerpc started showing the following issue: # modprobe kprobe_example ftrace-powerpc: Not expected bl: opcode is 3c4c0001 WARNING: CPU: 0 PID: 227 at kernel/trace/ftrace.c:2001 ftrace_bug+0x90/0x318 Modules linked in: CPU: 0 PID: 227 Comm: modprobe Not tainted 5.2.0-rc6-00678-g1c329100b942 #2 NIP: c000000000264318 LR: c00000000025d694 CTR: c000000000f5cd30 REGS: c000000001f2b7b0 TRAP: 0700 Not tainted (5.2.0-rc6-00678-g1c329100b942) MSR: 900000010282b033 CR: 28228222 XER: 00000000 CFAR: c0000000002642fc IRQMASK: 0 NIP [c000000000264318] ftrace_bug+0x90/0x318 LR [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0 Call Trace: [c000000001f2ba40] [0000000000000004] 0x4 (unreliable) [c000000001f2bad0] [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0 [c000000001f2bb90] [c00000000020ff10] load_module+0x25b0/0x30c0 [c000000001f2bd00] [c000000000210cb0] sys_finit_module+0xc0/0x130 [c000000001f2be20] [c00000000000bda4] system_call+0x5c/0x70 Instruction dump: 419e0018 2f83ffff 419e00bc 2f83ffea 409e00cc 4800001c 0fe00000 3c62ff96 39000001 39400000 386386d0 480000c4 <0fe00000> 3ce20003 39000001 3c62ff96 ---[ end trace 4c438d5cebf78381 ]--- ftrace failed to modify [] 0xc0080000012a0008 actual: 01:00:4c:3c Initializing ftrace call sites ftrace record flags: 2000000 (0) expected tramp: c00000000006af4c Looking at the relocation records in __mcount_loc showed a few spurious entries: RELOCATION RECORDS FOR [__mcount_loc]: OFFSET TYPE VALUE 0000000000000000 R_PPC64_ADDR64 .text.unlikely+0x0000000000000008 0000000000000008 R_PPC64_ADDR64 .text.unlikely+0x0000000000000014 0000000000000010 R_PPC64_ADDR64 .text.unlikely+0x0000000000000060 0000000000000018 R_PPC64_ADDR64 .text.unlikely+0x00000000000000b4 0000000000000020 R_PPC64_ADDR64 .init.text+0x0000000000000008 0000000000000028 R_PPC64_ADDR64 .init.text+0x0000000000000014 The first entry in each section is incorrect. Looking at the relocation records, the spurious entries correspond to the R_PPC64_ENTRY records: RELOCATION RECORDS FOR [.text.unlikely]: OFFSET TYPE VALUE 0000000000000000 R_PPC64_REL64 .TOC.-0x0000000000000008 0000000000000008 R_PPC64_ENTRY *ABS* 0000000000000014 R_PPC64_REL24 _mcount The problem is that we are not validating the return value from get_mcountsym() in sift_rel_mcount(). With this entry, mcountsym is 0, but Elf_r_sym(relp) also ends up being 0. Fix this by ensuring mcountsym is valid before processing the entry. Fixes: c7d64b560ce80 ("powerpc/ftrace: Enable C Version of recordmcount") Signed-off-by: Naveen N. Rao --- scripts/recordmcount.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h index 13c5e6c8829c..47fca2c69a73 100644 --- a/scripts/recordmcount.h +++ b/scripts/recordmcount.h @@ -325,7 +325,8 @@ static uint_t *sift_rel_mcount(uint_t *mlocp, if (!mcountsym) mcountsym = get_mcountsym(sym0, relp, str0); - if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) { + if (mcountsym && mcountsym == Elf_r_sym(relp) && + !is_fake_mcount(relp)) { uint_t const addend = _w(_w(relp->r_offset) - recval + mcount_adjust); mrelp->r_offset = _w(offbase -- 2.22.0