From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Bhupesh Sharma <bhsharma-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ard Biesheuvel
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
kexec mailing list
<kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Bhupesh SHARMA
<bhupesh.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-arm-kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [Bug Report] kdump crashes after latest EFI memblock changes on arm64 machines with large number of CPUs
Date: Tue, 6 Nov 2018 01:30:23 +0000 [thread overview]
Message-ID: <20181106013022.GA27793@brain-police> (raw)
In-Reply-To: <CACi5LpOyy0YkhEzWWqt8hAQfKku2Vzp5+da_dGS23JMyHReNew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Nov 02, 2018 at 02:44:10AM +0530, Bhupesh Sharma wrote:
> With the latest EFI changes for memblock reservation across kdump
> kernel from Ard (Commit 71e0940d52e107748b270213a01d3b1546657d74
> ["efi: honour memory reservations passed via a linux specific config
> table"]), we hit a panic while trying to boot the kdump kernel on
> machines which have large number of CPUs.
>
> I have a arm64 board which has 224 CPUS:
> # lscpu
> <..snip..>
> CPU(s): 224
> On-line CPU(s) list: 0-223
> <..snip..>
>
> Here are the crash logs in the kdump kernel on this machine:
>
> [ 0.000000] Unable to handle kernel paging request at virtual
> address ffff80003ffe0000
> val____)nt EL), IL ata abort info:
> [ 0.or: Oops: 960000inted 4.18.0+ #3
> [ 0.000000] pstate: 20400089 (nzCv daIf +PAN -UAO)
> [ 0.000000] pc : __memcpy+0x110/0x180
> [ 0.000000] lr : memblock_double_array+0x240/0x348
> [ 0.000000] sp : ffff0000092efc80 x28: 00000000bffe0000
> [ 0.000000] x27: 0000000000001800 x26: ffff000009d59000
> [ 0.000000] x25: ffff80003ffe0000 x24: 0000000000000000
> [ 0.000000] x23: 0000000000010000 x22: ffff000009d594e8
> [ 0.000000] x21: ffff000009d594f4 x20: ffff0000093c7268
> [ 0.000000] x19: 0000000000000c00 x18: 0000000000000010
> [ 0.000000] x17: 0000000000000000 x16: 0000000000000000
> [ 0.000000] x15: ffffffffffffffff3: 0000000fc18d0000 x12: 0000000800000000
> [ 0.000000] x11: 0000000000000018 x10: 00000000ddab9e18
> [ 0.000000] x9 : 0000000800000000 x8 : 00000000000002c1
> [ 0.000000] x7 : 0000000091b90000 x6 : ffff80003ffe0000
> [ 0.000000] x5 : 0000000000000001 x4 : 0000000000000000
> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000b80
> [ 0.000000] x1 : ffff000009d59540 x0 : ffff80003ffe0000
> [ 0.000000] Process swapper)
> [ 0.000000] Call trace:
> [ 0.000000] __memcpy+0x110/0x180
> [ 0.000000] memblock_add_range+0x134/0x2e8
> [ 0.000000] memblock_reserve+0x70/0xb8
> [ 0.000000] memblock_alloc_base_nid+0x6c/0x88
> [ 0.000000] __memblock_alloc_base+0x3c/0x4c
> [ 0.000000] memblock_alloc_base+0x28/0x4c
> [ 0.000000] memblock_alloc+0x2c/0x38
> [ 0.000000] early_pgtable_alloc+0x20/0xb0
Hmm, so this seems to be the crux of the issue: early_pgtable_alloc() relies
on memblock to allocate page-table memory, but this can be called before the
linear mapping is up and running (or even as part of creating the linear
mapping itself!) so the use of __va in memblock_double_array() actually
returns an unmapped address.
So I guess we either need to implement early_pgtable_alloc() some other way
(how?) or get memblock_double_array() to use a fixmap if it's called too
early (yuck). Alternatively, would it be possible to postpone processing of
the EFI mem_reserve entries until after we've created the linear mapping?
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [Bug Report] kdump crashes after latest EFI memblock changes on arm64 machines with large number of CPUs
Date: Tue, 6 Nov 2018 01:30:23 +0000 [thread overview]
Message-ID: <20181106013022.GA27793@brain-police> (raw)
In-Reply-To: <CACi5LpOyy0YkhEzWWqt8hAQfKku2Vzp5+da_dGS23JMyHReNew@mail.gmail.com>
On Fri, Nov 02, 2018 at 02:44:10AM +0530, Bhupesh Sharma wrote:
> With the latest EFI changes for memblock reservation across kdump
> kernel from Ard (Commit 71e0940d52e107748b270213a01d3b1546657d74
> ["efi: honour memory reservations passed via a linux specific config
> table"]), we hit a panic while trying to boot the kdump kernel on
> machines which have large number of CPUs.
>
> I have a arm64 board which has 224 CPUS:
> # lscpu
> <..snip..>
> CPU(s): 224
> On-line CPU(s) list: 0-223
> <..snip..>
>
> Here are the crash logs in the kdump kernel on this machine:
>
> [ 0.000000] Unable to handle kernel paging request at virtual
> address ffff80003ffe0000
> val____)nt EL), IL ata abort info:
> [ 0.or: Oops: 960000inted 4.18.0+ #3
> [ 0.000000] pstate: 20400089 (nzCv daIf +PAN -UAO)
> [ 0.000000] pc : __memcpy+0x110/0x180
> [ 0.000000] lr : memblock_double_array+0x240/0x348
> [ 0.000000] sp : ffff0000092efc80 x28: 00000000bffe0000
> [ 0.000000] x27: 0000000000001800 x26: ffff000009d59000
> [ 0.000000] x25: ffff80003ffe0000 x24: 0000000000000000
> [ 0.000000] x23: 0000000000010000 x22: ffff000009d594e8
> [ 0.000000] x21: ffff000009d594f4 x20: ffff0000093c7268
> [ 0.000000] x19: 0000000000000c00 x18: 0000000000000010
> [ 0.000000] x17: 0000000000000000 x16: 0000000000000000
> [ 0.000000] x15: ffffffffffffffff3: 0000000fc18d0000 x12: 0000000800000000
> [ 0.000000] x11: 0000000000000018 x10: 00000000ddab9e18
> [ 0.000000] x9 : 0000000800000000 x8 : 00000000000002c1
> [ 0.000000] x7 : 0000000091b90000 x6 : ffff80003ffe0000
> [ 0.000000] x5 : 0000000000000001 x4 : 0000000000000000
> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000b80
> [ 0.000000] x1 : ffff000009d59540 x0 : ffff80003ffe0000
> [ 0.000000] Process swapper)
> [ 0.000000] Call trace:
> [ 0.000000] __memcpy+0x110/0x180
> [ 0.000000] memblock_add_range+0x134/0x2e8
> [ 0.000000] memblock_reserve+0x70/0xb8
> [ 0.000000] memblock_alloc_base_nid+0x6c/0x88
> [ 0.000000] __memblock_alloc_base+0x3c/0x4c
> [ 0.000000] memblock_alloc_base+0x28/0x4c
> [ 0.000000] memblock_alloc+0x2c/0x38
> [ 0.000000] early_pgtable_alloc+0x20/0xb0
Hmm, so this seems to be the crux of the issue: early_pgtable_alloc() relies
on memblock to allocate page-table memory, but this can be called before the
linear mapping is up and running (or even as part of creating the linear
mapping itself!) so the use of __va in memblock_double_array() actually
returns an unmapped address.
So I guess we either need to implement early_pgtable_alloc() some other way
(how?) or get memblock_double_array() to use a fixmap if it's called too
early (yuck). Alternatively, would it be possible to postpone processing of
the EFI mem_reserve entries until after we've created the linear mapping?
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-efi@vger.kernel.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
kexec mailing list <kexec@lists.infradead.org>,
Bhupesh SHARMA <bhupesh.linux@gmail.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [Bug Report] kdump crashes after latest EFI memblock changes on arm64 machines with large number of CPUs
Date: Tue, 6 Nov 2018 01:30:23 +0000 [thread overview]
Message-ID: <20181106013022.GA27793@brain-police> (raw)
In-Reply-To: <CACi5LpOyy0YkhEzWWqt8hAQfKku2Vzp5+da_dGS23JMyHReNew@mail.gmail.com>
On Fri, Nov 02, 2018 at 02:44:10AM +0530, Bhupesh Sharma wrote:
> With the latest EFI changes for memblock reservation across kdump
> kernel from Ard (Commit 71e0940d52e107748b270213a01d3b1546657d74
> ["efi: honour memory reservations passed via a linux specific config
> table"]), we hit a panic while trying to boot the kdump kernel on
> machines which have large number of CPUs.
>
> I have a arm64 board which has 224 CPUS:
> # lscpu
> <..snip..>
> CPU(s): 224
> On-line CPU(s) list: 0-223
> <..snip..>
>
> Here are the crash logs in the kdump kernel on this machine:
>
> [ 0.000000] Unable to handle kernel paging request at virtual
> address ffff80003ffe0000
> val____)nt EL), IL ata abort info:
> [ 0.or: Oops: 960000inted 4.18.0+ #3
> [ 0.000000] pstate: 20400089 (nzCv daIf +PAN -UAO)
> [ 0.000000] pc : __memcpy+0x110/0x180
> [ 0.000000] lr : memblock_double_array+0x240/0x348
> [ 0.000000] sp : ffff0000092efc80 x28: 00000000bffe0000
> [ 0.000000] x27: 0000000000001800 x26: ffff000009d59000
> [ 0.000000] x25: ffff80003ffe0000 x24: 0000000000000000
> [ 0.000000] x23: 0000000000010000 x22: ffff000009d594e8
> [ 0.000000] x21: ffff000009d594f4 x20: ffff0000093c7268
> [ 0.000000] x19: 0000000000000c00 x18: 0000000000000010
> [ 0.000000] x17: 0000000000000000 x16: 0000000000000000
> [ 0.000000] x15: ffffffffffffffff3: 0000000fc18d0000 x12: 0000000800000000
> [ 0.000000] x11: 0000000000000018 x10: 00000000ddab9e18
> [ 0.000000] x9 : 0000000800000000 x8 : 00000000000002c1
> [ 0.000000] x7 : 0000000091b90000 x6 : ffff80003ffe0000
> [ 0.000000] x5 : 0000000000000001 x4 : 0000000000000000
> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000b80
> [ 0.000000] x1 : ffff000009d59540 x0 : ffff80003ffe0000
> [ 0.000000] Process swapper)
> [ 0.000000] Call trace:
> [ 0.000000] __memcpy+0x110/0x180
> [ 0.000000] memblock_add_range+0x134/0x2e8
> [ 0.000000] memblock_reserve+0x70/0xb8
> [ 0.000000] memblock_alloc_base_nid+0x6c/0x88
> [ 0.000000] __memblock_alloc_base+0x3c/0x4c
> [ 0.000000] memblock_alloc_base+0x28/0x4c
> [ 0.000000] memblock_alloc+0x2c/0x38
> [ 0.000000] early_pgtable_alloc+0x20/0xb0
Hmm, so this seems to be the crux of the issue: early_pgtable_alloc() relies
on memblock to allocate page-table memory, but this can be called before the
linear mapping is up and running (or even as part of creating the linear
mapping itself!) so the use of __va in memblock_double_array() actually
returns an unmapped address.
So I guess we either need to implement early_pgtable_alloc() some other way
(how?) or get memblock_double_array() to use a fixmap if it's called too
early (yuck). Alternatively, would it be possible to postpone processing of
the EFI mem_reserve entries until after we've created the linear mapping?
Will
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2018-11-06 1:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-01 21:14 [Bug Report] kdump crashes after latest EFI memblock changes on arm64 machines with large number of CPUs Bhupesh Sharma
2018-11-01 21:14 ` Bhupesh Sharma
2018-11-01 21:14 ` Bhupesh Sharma
2018-11-05 11:11 ` Ard Biesheuvel
2018-11-05 11:11 ` Ard Biesheuvel
2018-11-05 11:11 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_1PNiGbgRqd3_0k6CGzh-2P+iAmqk=oSSek69kBCnb8Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-11-05 11:31 ` Marc Zyngier
2018-11-05 11:31 ` Marc Zyngier
2018-11-05 11:31 ` Marc Zyngier
[not found] ` <CACi5LpOyy0YkhEzWWqt8hAQfKku2Vzp5+da_dGS23JMyHReNew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-11-06 1:30 ` Will Deacon [this message]
2018-11-06 1:30 ` Will Deacon
2018-11-06 1:30 ` Will Deacon
2018-11-06 8:44 ` Ard Biesheuvel
2018-11-06 8:44 ` Ard Biesheuvel
2018-11-06 8:44 ` Ard Biesheuvel
2018-11-08 5:58 ` Bhupesh Sharma
2018-11-08 5:58 ` Bhupesh Sharma
2018-11-08 5:58 ` Bhupesh Sharma
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=20181106013022.GA27793@brain-police \
--to=will.deacon-5wv7dgnigg8@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=bhsharma-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=bhupesh.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.