public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: tanxiaojun@huawei.com (Tan Xiaojun)
To: linux-arm-kernel@lists.infradead.org
Subject: [arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top"
Date: Mon, 24 Apr 2017 09:02:16 +0800	[thread overview]
Message-ID: <58FD4E98.7070709@huawei.com> (raw)
In-Reply-To: <20170421093436.GD6406@leverpostej>

On 2017/4/21 17:34, Mark Rutland wrote:
> Hi,
> 
> On Fri, Apr 21, 2017 at 01:46:43PM +0800, Tan Xiaojun wrote:
>> On 2017/4/20 9:38, Tan Xiaojun wrote:
>>> On 2017/4/19 19:49, Mark Rutland wrote:
>>>> Hi,
>>>>
>>>> Ard, this sseems to be a nomap issue. Please see below.
>>>>
>>>> Xiaojun, for some reason, the first message in this thread didn't seem
>>>> to make it to LAKML (or to me). In future could you please Cc me for
>>>> emails regarding perf on arm/arm64?
>>>>
>>>
>>> Sorry, this is my negligence.
>>>
>>>> On Wed, Apr 19, 2017 at 09:44:56AM +0530, Pratyush Anand wrote:
>>>>> On Saturday 15 April 2017 02:18 PM, Tan Xiaojun wrote:
>>>>>> My test server is Hisilicon D03/D05 (arm64).
>>>>>> Kernel source code is 4.11-rc6 (up to date) and config (as an attachment in the end) is generated by defconfig.
>>>>>> (Old version does not seem to have this problem. Linux-4.1 is fine and other versions I have not tested yet.)
>>>>>
>>>>> I tested with mustang(ARM64) and 4.11-rc6 and could not reproduce it.
>>>>>
>>
>> Hi, 
>> Pratyush,
>>
>> Sorry, could you test it again? Because I tested it many times and found it is not triggered every time.
>> And you can run "perf top -U" and try more kernel symbols to increase the probability of occurrence, or 
>> maybe you can try Mark's way "cat /proc/kcore > /dev/null".
>>
>> I would like to confirm whether this is hardware related, but I have no other arm64 boards except the
>> boards of Hisilicon.
> 
> As I mentioned in my prior reply, this is a bug in the way we handle
> nomap memory in the kernel.
> 
> This is not hardware related, and this is not specific to perf.
> 
> The kcore code expects that if a vmalloc mapping has a corresponding
> struct page, that it can be accessed via the linear mapping. However,
> this is not true for nomap memory.
> 

Yes, you are right. 

>> I found the patch which introduced the problem.
>> The commit is:
>>
>> commit f9040773b7bbbd9e98eb6184a263512a7cfc133f
>> Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Date:   Tue Feb 16 13:52:40 2016 +0100
>>
>>     arm64: move kernel image to base of vmalloc area
>>
>>     This moves the module area to right before the vmalloc area, and moves
>>     the kernel image to the base of the vmalloc area. This is an intermediate
>>     step towards implementing KASLR, which allows the kernel image to be
>>     located anywhere in the vmalloc area.
>>
>>     Since other subsystems such as hibernate may still need to refer to the
>>     kernel text or data segments via their linears addresses, both are mapped
>>     in the linear region as well. The linear alias of the text region is
>>     mapped read-only/non-executable to prevent inadvertent modification or
>>     execution.
>>
>>     Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>     Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>>
>> It can work well without this patch in Linux-4.5-rc4. And it can
>> trigger an OOPS with this patch in Linux-4.5-rc4.
>>
>> I try to revert it in v4.11-rc6, but it involves too much conflict.
>> So I need to understand this patch fist. Then I can known where the problem is.
> 
> Reverting this patch is not the correct fix.
> 
> The fix will either be changing the way we set things up for nomap
> memory, or with additions to the kcore or vread code to cater for nomap.
> 

It seems that the problem is serious and I want to fix it as soon as possible. But I know little
about nomap memory. So if you can give a fix patch, I am glad to test it. ^-^

Thanks.
Xiaojun.

> Thanks,
> Mark.
> .
> 

      reply	other threads:[~2017-04-24  1:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <58F1D28B.6010107@huawei.com>
     [not found] ` <58F1DE6A.7050307@huawei.com>
2017-04-19  4:14   ` [arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top" Pratyush Anand
2017-04-19  8:01     ` Tan Xiaojun
2017-04-19 11:49     ` Mark Rutland
2017-04-20  1:38       ` Tan Xiaojun
2017-04-21  5:46         ` Tan Xiaojun
2017-04-21  9:34           ` Mark Rutland
2017-04-24  1:02             ` Tan Xiaojun [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58FD4E98.7070709@huawei.com \
    --to=tanxiaojun@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox