* [PATCH V2] mm: check pfn_valid first in zero_resv_unavail
@ 2017-12-01 9:50 Dave Young
2017-12-05 9:46 ` Michal Hocko
0 siblings, 1 reply; 3+ messages in thread
From: Dave Young @ 2017-12-01 9:50 UTC (permalink / raw)
To: linux-kernel; +Cc: pasha.tatashin, linux-mm, akpm, Michal Hocko
With latest kernel I get below bug while testing kdump:
[ 0.000000] BUG: unable to handle kernel paging request at ffffea00034b1040
[ 0.000000] IP: zero_resv_unavail+0xbd/0x126
[ 0.000000] PGD 37b98067 P4D 37b98067 PUD 37b97067 PMD 0
[ 0.000000] Oops: 0002 [#1] SMP
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.15.0-rc1+ #316
[ 0.000000] Hardware name: LENOVO 20ARS1BJ02/20ARS1BJ02, BIOS GJET92WW (2.42 ) 03/03/2017
[ 0.000000] task: ffffffff81a0e4c0 task.stack: ffffffff81a00000
[ 0.000000] RIP: 0010:zero_resv_unavail+0xbd/0x126
[ 0.000000] RSP: 0000:ffffffff81a03d88 EFLAGS: 00010006
[ 0.000000] RAX: 0000000000000000 RBX: ffffea00034b1040 RCX: 0000000000000010
[ 0.000000] RDX: 0000000000000000 RSI: 0000000000000092 RDI: ffffea00034b1040
[ 0.000000] RBP: 00000000000d2c41 R08: 00000000000000c0 R09: 0000000000000a0d
[ 0.000000] R10: 0000000000000002 R11: 0000000000007f01 R12: ffffffff81a03d90
[ 0.000000] R13: ffffea0000000000 R14: 0000000000000063 R15: 0000000000000062
[ 0.000000] FS: 0000000000000000(0000) GS:ffffffff81c73000(0000) knlGS:0000000000000000
[ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.000000] CR2: ffffea00034b1040 CR3: 0000000037609000 CR4: 00000000000606b0
[ 0.000000] Call Trace:
[ 0.000000] ? free_area_init_nodes+0x640/0x664
[ 0.000000] ? zone_sizes_init+0x58/0x72
[ 0.000000] ? setup_arch+0xb50/0xc6c
[ 0.000000] ? start_kernel+0x64/0x43d
[ 0.000000] ? secondary_startup_64+0xa5/0xb0
[ 0.000000] Code: c1 e8 0c 48 39 d8 76 27 48 89 de 48 c1 e3 06 48 c7 c7 7a 87 79 81 e8 b0 c0 3e ff 4c 01 eb b9 10 00 00 00 31 c0 48 89 df 49 ff c6 <f3> ab eb bc 6a 00 49
c7 c0 f0 93 d1 81 31 d2 83 ce ff 41 54 49
[ 0.000000] RIP: zero_resv_unavail+0xbd/0x126 RSP: ffffffff81a03d88
[ 0.000000] CR2: ffffea00034b1040
[ 0.000000] ---[ end trace f5ba9e8f73c7ee26 ]---
This is introduced with commit a4a3ede2132a ("mm: zero reserved and
unavailable struct pages")
The reason is some efi reserved boot ranges is not reported in E820 ram.
In my case it is a bgrt buffer:
efi: mem00: [Boot Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x00000000d2c41000-0x00000000d2c85fff] (0MB)
Use "add_efi_memmap" can workaround the problem with another fix:
http://lkml.kernel.org/r/20171130052327.GA3500@dhcp-128-65.nay.redhat.com
In zero_resv_unavail it would be better to check pfn_valid first before zero
the page struct. This fixes the problem and potential other similar problems.
Also as Pavel Tatashin suggested checks pfn_valid at the beginning of the
section.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
v1->v2: Michal Hocko: patch log improvement
Pavel Tatashin: check pfn at the beginning of the section
mm/page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-x86.orig/mm/page_alloc.c
+++ linux-x86/mm/page_alloc.c
@@ -6253,6 +6253,8 @@ void __paginginit zero_resv_unavail(void
pgcnt = 0;
for_each_resv_unavail_range(i, &start, &end) {
for (pfn = PFN_DOWN(start); pfn < PFN_UP(end); pfn++) {
+ if (!pfn_valid(ALIGN_DOWN(pfn, pageblock_nr_pages)))
+ continue;
mm_zero_struct_page(pfn_to_page(pfn));
pgcnt++;
}
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH V2] mm: check pfn_valid first in zero_resv_unavail
2017-12-01 9:50 [PATCH V2] mm: check pfn_valid first in zero_resv_unavail Dave Young
@ 2017-12-05 9:46 ` Michal Hocko
2017-12-08 3:12 ` Dave Young
0 siblings, 1 reply; 3+ messages in thread
From: Michal Hocko @ 2017-12-05 9:46 UTC (permalink / raw)
To: Dave Young; +Cc: linux-kernel, pasha.tatashin, linux-mm, akpm
On Fri 01-12-17 17:50:48, Dave Young wrote:
> With latest kernel I get below bug while testing kdump:
> [ 0.000000] BUG: unable to handle kernel paging request at ffffea00034b1040
> [ 0.000000] IP: zero_resv_unavail+0xbd/0x126
> [ 0.000000] PGD 37b98067 P4D 37b98067 PUD 37b97067 PMD 0
> [ 0.000000] Oops: 0002 [#1] SMP
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.15.0-rc1+ #316
> [ 0.000000] Hardware name: LENOVO 20ARS1BJ02/20ARS1BJ02, BIOS GJET92WW (2.42 ) 03/03/2017
> [ 0.000000] task: ffffffff81a0e4c0 task.stack: ffffffff81a00000
> [ 0.000000] RIP: 0010:zero_resv_unavail+0xbd/0x126
> [ 0.000000] RSP: 0000:ffffffff81a03d88 EFLAGS: 00010006
> [ 0.000000] RAX: 0000000000000000 RBX: ffffea00034b1040 RCX: 0000000000000010
> [ 0.000000] RDX: 0000000000000000 RSI: 0000000000000092 RDI: ffffea00034b1040
> [ 0.000000] RBP: 00000000000d2c41 R08: 00000000000000c0 R09: 0000000000000a0d
> [ 0.000000] R10: 0000000000000002 R11: 0000000000007f01 R12: ffffffff81a03d90
> [ 0.000000] R13: ffffea0000000000 R14: 0000000000000063 R15: 0000000000000062
> [ 0.000000] FS: 0000000000000000(0000) GS:ffffffff81c73000(0000) knlGS:0000000000000000
> [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.000000] CR2: ffffea00034b1040 CR3: 0000000037609000 CR4: 00000000000606b0
> [ 0.000000] Call Trace:
> [ 0.000000] ? free_area_init_nodes+0x640/0x664
> [ 0.000000] ? zone_sizes_init+0x58/0x72
> [ 0.000000] ? setup_arch+0xb50/0xc6c
> [ 0.000000] ? start_kernel+0x64/0x43d
> [ 0.000000] ? secondary_startup_64+0xa5/0xb0
> [ 0.000000] Code: c1 e8 0c 48 39 d8 76 27 48 89 de 48 c1 e3 06 48 c7 c7 7a 87 79 81 e8 b0 c0 3e ff 4c 01 eb b9 10 00 00 00 31 c0 48 89 df 49 ff c6 <f3> ab eb bc 6a 00 49
> c7 c0 f0 93 d1 81 31 d2 83 ce ff 41 54 49
> [ 0.000000] RIP: zero_resv_unavail+0xbd/0x126 RSP: ffffffff81a03d88
> [ 0.000000] CR2: ffffea00034b1040
> [ 0.000000] ---[ end trace f5ba9e8f73c7ee26 ]---
>
> This is introduced with commit a4a3ede2132a ("mm: zero reserved and
> unavailable struct pages")
>
> The reason is some efi reserved boot ranges is not reported in E820 ram.
> In my case it is a bgrt buffer:
> efi: mem00: [Boot Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x00000000d2c41000-0x00000000d2c85fff] (0MB)
I am still confused. Could you clarify why does efi code reserve this
range when it is not backed by any real memory?
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH V2] mm: check pfn_valid first in zero_resv_unavail
2017-12-05 9:46 ` Michal Hocko
@ 2017-12-08 3:12 ` Dave Young
0 siblings, 0 replies; 3+ messages in thread
From: Dave Young @ 2017-12-08 3:12 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-kernel, pasha.tatashin, linux-mm, akpm
On 12/05/17 at 10:46am, Michal Hocko wrote:
> On Fri 01-12-17 17:50:48, Dave Young wrote:
> > With latest kernel I get below bug while testing kdump:
> > [ 0.000000] BUG: unable to handle kernel paging request at ffffea00034b1040
> > [ 0.000000] IP: zero_resv_unavail+0xbd/0x126
> > [ 0.000000] PGD 37b98067 P4D 37b98067 PUD 37b97067 PMD 0
> > [ 0.000000] Oops: 0002 [#1] SMP
> > [ 0.000000] Modules linked in:
> > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.15.0-rc1+ #316
> > [ 0.000000] Hardware name: LENOVO 20ARS1BJ02/20ARS1BJ02, BIOS GJET92WW (2.42 ) 03/03/2017
> > [ 0.000000] task: ffffffff81a0e4c0 task.stack: ffffffff81a00000
> > [ 0.000000] RIP: 0010:zero_resv_unavail+0xbd/0x126
> > [ 0.000000] RSP: 0000:ffffffff81a03d88 EFLAGS: 00010006
> > [ 0.000000] RAX: 0000000000000000 RBX: ffffea00034b1040 RCX: 0000000000000010
> > [ 0.000000] RDX: 0000000000000000 RSI: 0000000000000092 RDI: ffffea00034b1040
> > [ 0.000000] RBP: 00000000000d2c41 R08: 00000000000000c0 R09: 0000000000000a0d
> > [ 0.000000] R10: 0000000000000002 R11: 0000000000007f01 R12: ffffffff81a03d90
> > [ 0.000000] R13: ffffea0000000000 R14: 0000000000000063 R15: 0000000000000062
> > [ 0.000000] FS: 0000000000000000(0000) GS:ffffffff81c73000(0000) knlGS:0000000000000000
> > [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 0.000000] CR2: ffffea00034b1040 CR3: 0000000037609000 CR4: 00000000000606b0
> > [ 0.000000] Call Trace:
> > [ 0.000000] ? free_area_init_nodes+0x640/0x664
> > [ 0.000000] ? zone_sizes_init+0x58/0x72
> > [ 0.000000] ? setup_arch+0xb50/0xc6c
> > [ 0.000000] ? start_kernel+0x64/0x43d
> > [ 0.000000] ? secondary_startup_64+0xa5/0xb0
> > [ 0.000000] Code: c1 e8 0c 48 39 d8 76 27 48 89 de 48 c1 e3 06 48 c7 c7 7a 87 79 81 e8 b0 c0 3e ff 4c 01 eb b9 10 00 00 00 31 c0 48 89 df 49 ff c6 <f3> ab eb bc 6a 00 49
> > c7 c0 f0 93 d1 81 31 d2 83 ce ff 41 54 49
> > [ 0.000000] RIP: zero_resv_unavail+0xbd/0x126 RSP: ffffffff81a03d88
> > [ 0.000000] CR2: ffffea00034b1040
> > [ 0.000000] ---[ end trace f5ba9e8f73c7ee26 ]---
> >
> > This is introduced with commit a4a3ede2132a ("mm: zero reserved and
> > unavailable struct pages")
> >
> > The reason is some efi reserved boot ranges is not reported in E820 ram.
> > In my case it is a bgrt buffer:
> > efi: mem00: [Boot Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x00000000d2c41000-0x00000000d2c85fff] (0MB)
>
> I am still confused. Could you clarify why does efi code reserve this
> range when it is not backed by any real memory?
Michal, maybe I did not describe it clearly. The range *is* backed by
real memory. The memory range is efi "Boot Service Data", that means
after ExitBootServices() these ranges can be used as system ram. But some
of them need to be reserved, for example the bgrt image address in
an acpi table, if the image memory is freed then kexec reboot will
fail because kexec inherit same acpi table to initialize the driver.
> --
> Michal Hocko
> SUSE Labs
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-12-08 3:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-01 9:50 [PATCH V2] mm: check pfn_valid first in zero_resv_unavail Dave Young
2017-12-05 9:46 ` Michal Hocko
2017-12-08 3:12 ` Dave Young
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).