From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3605CEEAA5D for ; Thu, 14 Sep 2023 18:24:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231720AbjINSYY (ORCPT ); Thu, 14 Sep 2023 14:24:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239368AbjINSYX (ORCPT ); Thu, 14 Sep 2023 14:24:23 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCC951FD7 for ; Thu, 14 Sep 2023 11:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694715859; x=1726251859; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=vQEad+iVRYrnSICTqMKn5SStFtxk1n6bfGZFb++F47I=; b=B51vo/T8jO33IhhMrTbv5uQ1YkSV3ohbvGXw06S/OPm/KdaasI1C261I 0l7ScxXaQh9nO6Fz5wmb3uzAozpXhmCVBuBsaQI7W0tXfkGxa92wFz6T9 dNEUMHmGzHD1lNBidVsLfPBlUTZ9uvBxX2fVXo3yr/PSvr/iKiMwxBsQo jpEM3NBLSoqOYYqi71t2M3A34z7n0P8v08lgTNkEbsb6O9eXI1jpqXfYR wRgTSnFlc1t+puvXYezCuno4Kj2TdWhmeb1KC2QZrV02llJWkIHMIPmtj MA95L1arsvW1ueg1grIN/HKZqAweuwZKiNrdr+wJ7jzZSQoUCktV2PokW Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10833"; a="378958687" X-IronPort-AV: E=Sophos;i="6.02,146,1688454000"; d="scan'208";a="378958687" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2023 11:24:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10833"; a="814824645" X-IronPort-AV: E=Sophos;i="6.02,146,1688454000"; d="scan'208";a="814824645" Received: from ahunter6-mobl1.ger.corp.intel.com (HELO [10.0.2.15]) ([10.252.36.59]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2023 11:24:10 -0700 Message-ID: Date: Thu, 14 Sep 2023 21:24:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.15.0 Subject: Re: [V2 2/2] tools/perf/tests: Fix object code reading to skip address that falls out of text section Content-Language: en-US To: Athira Rajeev , acme@kernel.org, jolsa@kernel.org, irogers@google.com, namhyung@kernel.org Cc: linux-perf-users@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, maddy@linux.ibm.com, kjain@linux.ibm.com, disgoel@linux.vnet.ibm.com, Disha Goel References: <20230907164529.36222-1-atrajeev@linux.vnet.ibm.com> <20230907164529.36222-2-atrajeev@linux.vnet.ibm.com> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki In-Reply-To: <20230907164529.36222-2-atrajeev@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-perf-users@vger.kernel.org On 7/09/23 19:45, Athira Rajeev wrote: > The testcase "Object code reading" fails in somecases > for "fs_something" sub test as below: > > Reading object code for memory address: 0xc008000007f0142c > File is: /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko > On file address is: 0x1114cc > Objdump command is: objdump -z -d --start-address=0x11142c --stop-address=0x1114ac /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko > objdump read too few bytes: 128 > test child finished with -1 > > This can alo be reproduced when running perf record with > workload that exercises fs_something() code. In the test > setup, this is exercising xfs code since root is xfs. > > # perf record ./a.out > # perf report -v |grep "xfs.ko" > 0.76% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc008000007de5efc B [k] xlog_cil_commit > 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc008000007d5ae18 B [k] xfs_btree_key_offset > 0.74% a.out /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko 0xc008000007e11fd4 B [k] 0x0000000000112074 > > Here addr "0xc008000007e11fd4" is not resolved. since this is a > kernel module, its offset is from the DSO. Xfs module is loaded > at 0xc008000007d00000 > > # cat /proc/modules | grep xfs > xfs 2228224 3 - Live 0xc008000007d00000 > > And size is 0x220000. So its loaded between  0xc008000007d00000 > and 0xc008000007f20000. From objdump, text section is: > text 0010f7bc 0000000000000000 0000000000000000 000000a0 2**4 > > Hence perf captured ip maps to 0x112074 which is: > ( ip - start of module ) + a0 > > This offset 0x112074 falls out .text section which is up to 0x10f7bc > In this case for module, the address 0xc008000007e11fd4 is pointing > to stub instructions. This address range represents the module stubs > which is allocated on module load and hence is not part of DSO offset. > > To address this issue in "object code reading", skip the sample if > address falls out of text section and is within the module end. > Use the "text_end" member of "struct dso" to do this check. > > To address this issue in "perf report", exploring an option of > having stubs range as part of the /proc/kallsyms, so that perf > report can resolve addresses in stubs range > > However this patch uses text_end to skip the stub range for > Object code reading testcase. > > Reported-by: Disha Goel > Signed-off-by: Athira Rajeev > --- > Changelog: > v1 -> v2: > Updated comment to add description on which arch has stub and > reason for skipping as suggested by Adrian > > tools/perf/tests/code-reading.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c > index ed3815163d1b..3cf6c2d42416 100644 > --- a/tools/perf/tests/code-reading.c > +++ b/tools/perf/tests/code-reading.c > @@ -269,6 +269,18 @@ static int read_object_code(u64 addr, size_t len, u8 cpumode, > if (addr + len > map__end(al.map)) > len = map__end(al.map) - addr; > > + /* > + * Some architectures (ex: powerpc) have stubs (trampolines) in kernel > + * modules to manage long jumps. Check if the ip offset falls in stubs > + * sections for kernel modules. And skip module address after text end > + */ > + if (strstr(dso->long_name, ".ko")) { Sorry for slow reply !strtailcmp() is slightly better here > + if (al.addr > dso->text_end) { We normally avoid nesting if-statements e.g. if (!strtailcmp(dso->long_name, ".ko") && al.addr > dso->text_end) Make those changes and you can add: Reviewed-by: Adrian Hunter > + pr_debug("skipping the module address %#"PRIx64" after text end\n", al.addr); > + goto out; > + } > + } > + > /* Read the object code using perf */ > ret_len = dso__data_read_offset(dso, maps__machine(thread__maps(thread)), > al.addr, buf1, len);