From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758998AbcG1CBr (ORCPT ); Wed, 27 Jul 2016 22:01:47 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:56809 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754635AbcG1CBk (ORCPT ); Wed, 27 Jul 2016 22:01:40 -0400 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: gongss@linux.vnet.ibm.com Subject: Re: [PATCH] s390/perf: fix 'start' address of module's map To: Arnaldo Carvalho de Melo References: <1469070651-6447-1-git-send-email-gongss@linux.vnet.ibm.com> <1469070651-6447-2-git-send-email-gongss@linux.vnet.ibm.com> <20160726195039.GA5200@kernel.org> <5797C49A.1070402@de.ibm.com> <20160726202926.GB5200@kernel.org> <20160727130808.GD5200@kernel.org> Cc: Christian Borntraeger , jolsa@kernel.org, dsahern@gmail.com, linux-kernel@vger.kernel.org, Michael Ellerman From: Songshan Gong Date: Thu, 28 Jul 2016 10:01:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160727130808.GD5200@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16072802-0012-0000-0000-000010445D5A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005534; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000177; SDB=6.00736419; UDB=6.00345838; IPR=6.00509012; BA=6.00004625; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012091; XFM=3.00000011; UTC=2016-07-28 02:01:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16072802-0013-0000-0000-000044107451 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-28_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607280020 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 7/27/2016 9:08 PM, Arnaldo Carvalho de Melo 写道: > Em Wed, Jul 27, 2016 at 06:49:48PM +0800, Songshan Gong escreveu: >> >> >> 在 7/27/2016 4:29 AM, Arnaldo Carvalho de Melo 写道: >>> Em Tue, Jul 26, 2016 at 10:14:18PM +0200, Christian Borntraeger escreveu: >>>> On 07/26/2016 09:50 PM, Arnaldo Carvalho de Melo wrote: >>>>> Em Thu, Jul 21, 2016 at 11:10:51AM +0800, Song Shan Gong escreveu: >>>>>> 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. >>>>> >>>>> I'll apply this as it fixes the problem for you and we need to get fixes >>>>> in ASAP to get this into 4.8, but why can't we just use your method for >>>>> all arches and get rid of this arch__ hook? I.e. if I look here in my >>>>> x86_64 notebook I see: >>>>> >>>>> [acme@jouet linux]$ cat /sys/module/tun/sections/.text >>>>> 0xffffffffc0af2000 >>>>> [acme@jouet linux]$ grep tun /proc/modules >>>>> tun 28672 4 vhost_net, Live 0xffffffffc0af2000 >>>>> [acme@jouet linux]$ >>>>> >>>>> So I could as well use what is in /sys/module/tun/sections/.text instead >>>>> of reading it from /proc/modules and, in s390, reading it from >>>>> /sys/module/tun/sections/.text. >>>>> >>>>> Do you see any problem with using this approach for _all_ arches? >>>> >>>> I think it should work well for _all_ arches but it will probably be >>>> hard to test this without help. >>> >>> Well, we could check for the cases we don't know, i.e. read from both >>> and warn about cases where it is different, except for s390 where we now >>> which is the right one to pick. >>> >> One question: how to get arch info except machine->env->arch? It seems that >> machine->env->arch could be NULL sometimes. > > That is not what you want to look at, as it is related to perf.data, > which may not be related to what you want, which is the running machine. > > For that use uname() -> utsname.machine. > > But then, why would you need it for reading /sys/module/*/sections/.text? > The arch name isn't there :-) Yes, it's no use for this patch. Thanks a lot. > > - Arnaldo > -- SongShan Gong