+ mm-check-pfn_valid-first-in-zero_resv_unavail.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The patch titled
     Subject: mm: check pfn_valid first in zero_resv_unavail
has been added to the -mm tree.  Its filename is
     mm-check-pfn_valid-first-in-zero_resv_unavail.patch

This patch should soon appear at
    http://ozlabs.org/~akpm/mmots/broken-out/mm-check-pfn_valid-first-in-zero_resv_unavail.patch
and later at
    http://ozlabs.org/~akpm/mmotm/broken-out/mm-check-pfn_valid-first-in-zero_resv_unavail.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

The -mm tree is included into linux-next and is updated
there every 3-4 working days

------------------------------------------------------
From: Dave Young <dyoung@xxxxxxxxxx>
Subject: mm: check pfn_valid first in zero_resv_unavail

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 by 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@xxxxxxxxxxxxxxxxxxxxxxxxxx

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.

Link: http://lkml.kernel.org/r/20171201095048.GA3084@xxxxxxxxxxxxxxxxxxxxxxxxxx
Fixes: a4a3ede2132a ("mm: zero reserved and unavailable struct pages")
Signed-off-by: Dave Young <dyoung@xxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxxxx>
Cc: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---

 mm/page_alloc.c |    2 ++
 1 file changed, 2 insertions(+)

diff -puN mm/page_alloc.c~mm-check-pfn_valid-first-in-zero_resv_unavail mm/page_alloc.c
--- a/mm/page_alloc.c~mm-check-pfn_valid-first-in-zero_resv_unavail
+++ a/mm/page_alloc.c
@@ -6249,6 +6249,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++;
 		}
_

Patches currently in -mm which might be from dyoung@xxxxxxxxxx are

mm-check-pfn_valid-first-in-zero_resv_unavail.patch

--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux