Patch looks good to me.
Reviewed-by: Kajol Jain <kj...@linux.ibm.com>
Thanks,
Kajol Jain
On 9/15/23 11:07, 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 <disg...@linux.ibm.com>
> Signed-off-by: Athira Rajeev <atraj...@linux.vnet.ibm.com>
> Tested-by: Disha Goel<disg...@linux.ibm.com>
> Reviewed-by: Adrian Hunter <adrian.hun...@intel.com>
> ---
> Changelog:
> v3 -> v4:
> Fixed indent in V3
>
> v2 -> v3:
> Used strtailcmp in comparison for module check and added Reviewed-by
> from Adrian, Tested-by from Disha.
>
> 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 | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
> index ed3815163d1b..9e6e6c985840 100644
> --- a/tools/perf/tests/code-reading.c
> +++ b/tools/perf/tests/code-reading.c
> @@ -269,6 +269,16 @@ 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 (!strtailcmp(dso->long_name, ".ko") && al.addr > dso->text_end) {
> + 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);
