linux-kernel - Re: [PATCH] [RFC V1]s390/perf: fix 'start' address of module's map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <23f8fd4e-bf77-d6e0-b91d-2dbab7eba69b@linux.vnet.ibm.com>
Date:	Wed, 13 Jul 2016 11:32:11 +0800
From:	Songshan Gong <gongss@...ux.vnet.ibm.com>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	acme@...nel.org, jolsa@...nel.org, dsahern@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC V1]s390/perf: fix 'start' address of module's map

I send this email to test the connection to linux-kernel maillist. Just 
ignore.

在 7/11/2016 4:11 PM, Songshan Gong 写道:
>
>
> 在 7/8/2016 11:18 PM, Jiri Olsa 写道:
>> On Thu, Jul 07, 2016 at 09:49:36AM +0800, Song Shan Gong wrote:
>>> At preset, when creating module's map, perf gets 'start' address by
>>> parsing
>>> 'proc/modules', but it's module base address, isn't the start address of
>>> '.text' section. In most archs, it's OK. But for s390, it places
>>> 'GOT' and
>>> 'PLT' relocations before '.text' section. So there exists an offset
>>> between
>>> module base address and '.text' section, which will incur wrong symbol
>>> resolution for modules.
>>>
>>> Fix this bug by getting 'start' address of module's map from parsing
>>> '/sys/module/[module name]/sections/.text', not from '/proc/modules'.
>>
>> cool, does this fix the 'perf test 1' for s390? that'd be great
>
> I've checked, 'perf test 1' is still failed. But the test is for testing
> whether 'vmlinux symtab matches kallsyms'. For vmlinux, it's built when
> compiling linux-kernel, so there's no any symbol info about module. For
> kallsyms, when loading, it also splits kernel symbols with module
> symbols. But this patch is intended to fix wrong symbol resolution for
> modules, so I think there's no relationship between this patch and the
> testcase 'perf test 1'.
>
> I also debuged the reason why 'perf test 1' fails, there are two reasons
> at least:
> 1. perf gets kernel start address by finding the first no-zero value of
> symbols {'_text', '_stext'} in /proc/kallsyms; for s390, it's always
> '_stext', but actually, '_stext' is not the first symbol in s390, there
> are other symbols before '_stext', for example 'iplstart'.
> 2. In addition, when loading by parsing /proc/kallsyms, if the kernel
> map start value is a non-zero value getting from '_stext', because
> '_text' is zero, it will not be included in kernel map; but for vmlinux,
> it always add '_text' to kernel map whether '_text' is zero or not. So
> if '_text' is zero, whether adding '_text' to kernel map, it's
> non-consistent for loading by /proc/kallsyms and vmlinux.
>
> I'll try to fix this bug later.
>
> Thanks for your comments.
>
>> I'll send few coments shortly
>>
>> thanks,
>> jirka
>>
>

-- 
SongShan Gong