From mboxrd@z Thu Jan 1 00:00:00 1970 From: tanxiaojun@huawei.com (Tan Xiaojun) Date: Mon, 24 Apr 2017 09:02:16 +0800 Subject: [arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top" In-Reply-To: <20170421093436.GD6406@leverpostej> References: <58F1D28B.6010107@huawei.com> <58F1DE6A.7050307@huawei.com> <8499425b-2b92-5b1f-a89f-6e7cd443232f@redhat.com> <20170419114935.GE27829@leverpostej> <58F810F8.5080502@huawei.com> <58F99CC3.9050507@huawei.com> <20170421093436.GD6406@leverpostej> Message-ID: <58FD4E98.7070709@huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 >> 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 >> Signed-off-by: Catalin Marinas >> >> 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. > . >