x86: mm: Check if PUD is large when validating a kernel address

PATCH In review Mel Gorman 7 participants 13 messages Feb 11, 2013 – Mar 1, 2013

Subsystems (3)

Memory management x86 x86 MM

lore

Share & tools

lore

Mel Gorman

author

2013-02-11 14:52 UTC #0 lore raw

PATCH 1/1 x86: mm: Check if PUD is large when validating a kernel address

A user reported the following oops when a backup process read /proc/kcore.

 BUG: unable to handle kernel paging request at ffffbb00ff33b000
 IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 PGD 0
 Oops: 0000 [#1] SMP
 CPU 6
 Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod

Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614

 RIP: 0010:[<ffffffff8103157e>]  [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 RSP: 0018:ffff88094165fe80  EFLAGS: 00010246
 RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
 RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
 RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
 R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
 R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
 FS:  00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
 Stack:
  ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
  ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
  0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
 Call Trace:
  [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
  [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
  [<ffffffff81151687>] vfs_read+0xc7/0x130
  [<ffffffff811517f3>] sys_read+0x53/0xa0
  [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Investigation determined that the bug triggered when reading system RAM at the 4G mark. On this system, that was the first address using 1G pages for the virt->phys direct mapping so the PUD is pointing to a physical address, not a PMD page. The problem is that the page table walker in kern_addr_valid() is not checking pud_large() and treats the physical address as if it was a PMD. If it happens to look like pmd_none then it'll silently fail, probably returning zeros instead of real data. If the data happens to look like a present PMD though, it will be walked resulting in the oops above. This patch adds the necessary pud_large() check.

Unfortunately the problem was not readily reproducible and now they are running the backup program without accessing /proc/kcore so the patch has not been validated but I think it makes sense. If reviewers agree then it should also be included in -stable back as far as 3.0-stable.

Cc [email protected]

Signed-off-by Mel Gorman <[email protected]>

---
 arch/x86/include/asm/pgtable.h |    5 +++++
 arch/x86/mm/init_64.c          |    3 +++
 2 files changed, 8 insertions(+)

arch/x86/include/asm/pgtable.h +5 -0

index 5199db2..1c1a955 100644
@@ -142,6 +142,11 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
 	return (pmd_val(pmd) & PTE_PFN_MASK) >> PAGE_SHIFT;
 }
 
+static inline unsigned long pud_pfn(pud_t pud)
+{
+	return (pud_val(pud) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
 #define pte_page(pte)	pfn_to_page(pte_pfn(pte))
 
 static inline int pmd_large(pmd_t pte)

arch/x86/mm/init_64.c +3 -0

index 2ead3c8..75c9a6a 100644
@@ -831,6 +831,9 @@ int kern_addr_valid(unsigned long addr)
 	if (pud_none(*pud))
 		return 0;
 
+	if (pud_large(*pud))
+		return pfn_valid(pud_pfn(*pud));
+
 	pmd = pmd_offset(pud, addr);
 	if (pmd_none(*pmd))
 		return 0;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Rik van Riel

Reviewed-by on v1 1/1

2013-02-11 19:41 UTC #1 lore raw

Quoted 15 lines · Mel Gorman

A user reported the following oops when a backup process read /proc/kcore.
  BUG: unable to handle kernel paging request at ffffbb00ff33b000
Investigation determined that the bug triggered when reading system RAM at the 4G mark. On this system, that was the first address using 1G pages for the virt->phys direct mapping so the PUD is pointing to a physical address, not a PMD page. The problem is that the page table walker in kern_addr_valid() is not checking pud_large() and treats the physical address as if it was a PMD. If it happens to look like pmd_none then it'll silently fail, probably returning zeros instead of real data. If the data happens to look like a present PMD though, it will be walked resulting in the oops above. This patch adds the necessary pud_large() check.

Quoted 7 lines

Unfortunately the problem was not readily reproducible and now they are running the backup program without accessing /proc/kcore so the patch has not been validated but I think it makes sense. If reviewers agree then it should also be included in -stable back as far as 3.0-stable.
Cc [email protected]
Signed-off-by Mel Gorman <[email protected]>

Reviewed-by Rik van Riel <[email protected]>

Johannes Weiner

Acked-by on v1 1/1

2013-02-12 06:41 UTC #2 lore raw

In reply to Mel Gorman

Quoted 45 lines · Mel Gorman

A user reported the following oops when a backup process read /proc/kcore.

 BUG: unable to handle kernel paging request at ffffbb00ff33b000
 IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 PGD 0
 Oops: 0000 [#1] SMP
 CPU 6
 Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod

Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614

 RIP: 0010:[<ffffffff8103157e>]  [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 RSP: 0018:ffff88094165fe80  EFLAGS: 00010246
 RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
 RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
 RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
 R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
 R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
 FS:  00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
 Stack:
  ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
  ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
  0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
 Call Trace:
  [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
  [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
  [<ffffffff81151687>] vfs_read+0xc7/0x130
  [<ffffffff811517f3>] sys_read+0x53/0xa0
  [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Quoted 7 lines

Unfortunately the problem was not readily reproducible and now they are running the backup program without accessing /proc/kcore so the patch has not been validated but I think it makes sense. If reviewers agree then it should also be included in -stable back as far as 3.0-stable.
Cc [email protected]
Signed-off-by Mel Gorman <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Agreed also on the backporting to -stable as far as possible.

Michal Hocko

Reviewed-by on v1 1/1

2013-02-12 17:43 UTC #3 lore raw

In reply to Mel Gorman

Quoted 45 lines · Mel Gorman

A user reported the following oops when a backup process read /proc/kcore.

 BUG: unable to handle kernel paging request at ffffbb00ff33b000
 IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 PGD 0
 Oops: 0000 [#1] SMP
 CPU 6
 Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod

Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614

 RIP: 0010:[<ffffffff8103157e>]  [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 RSP: 0018:ffff88094165fe80  EFLAGS: 00010246
 RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
 RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
 RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
 R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
 R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
 FS:  00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
 Stack:
  ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
  ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
  0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
 Call Trace:
  [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
  [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
  [<ffffffff81151687>] vfs_read+0xc7/0x130
  [<ffffffff811517f3>] sys_read+0x53/0xa0
  [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Quoted 7 lines

Unfortunately the problem was not readily reproducible and now they are running the backup program without accessing /proc/kcore so the patch has not been validated but I think it makes sense. If reviewers agree then it should also be included in -stable back as far as 3.0-stable.
Cc [email protected]
Signed-off-by Mel Gorman <[email protected]>

Reviewed-by Michal Hocko <[email protected]>

Quoted 41 lines

---
 arch/x86/include/asm/pgtable.h |    5 +++++
 arch/x86/mm/init_64.c          |    3 +++
 2 files changed, 8 insertions(+)

arch/x86/include/asm/pgtable.h +5 -0

index 5199db2..1c1a955 100644
@@ -142,6 +142,11 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
 	return (pmd_val(pmd) & PTE_PFN_MASK) >> PAGE_SHIFT;
 }
 
+static inline unsigned long pud_pfn(pud_t pud)
+{
+	return (pud_val(pud) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
 #define pte_page(pte)	pfn_to_page(pte_pfn(pte))
 
 static inline int pmd_large(pmd_t pte)

arch/x86/mm/init_64.c +3 -1

index 2ead3c8..75c9a6a 100644
@@ -831,6 +831,9 @@ int kern_addr_valid(unsigned long addr)
 	if (pud_none(*pud))
 		return 0;
 
+	if (pud_large(*pud))
+		return pfn_valid(pud_pfn(*pud));
+
 	pmd = pmd_offset(pud, addr);
 	if (pmd_none(*pmd))
 		return 0;
 
--

To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Signature · 8 lines

Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Mel Gorman

author

2013-02-13 11:02 UTC #4 lore raw

PATCH 1/1 x86: mm: Check if PUD is large when validating a kernel address v2

In reply to Mel Gorman

Andrew or Ingo, please pick up.

Changelog since v1
o Add reviewed-bys and acked-bys

A user reported a bug whereby a backup process accessing /proc/kcore caused an oops.

 BUG: unable to handle kernel paging request at ffffbb00ff33b000
 IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 PGD 0
 Oops: 0000 [#1] SMP
 CPU 6
 Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod

Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614

 RIP: 0010:[<ffffffff8103157e>]  [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 RSP: 0018:ffff88094165fe80  EFLAGS: 00010246
 RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
 RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
 RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
 R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
 R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
 FS:  00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
 Stack:
  ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
  ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
  0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
 Call Trace:
  [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
  [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
  [<ffffffff81151687>] vfs_read+0xc7/0x130
  [<ffffffff811517f3>] sys_read+0x53/0xa0
  [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Cc [email protected]

Signed-off-by Mel Gorman <[email protected]>

Reviewed-by Rik van Riel <[email protected]>

Reviewed-by Michal Hocko <[email protected]>

Acked-by Johannes Weiner <[email protected]>

---
 arch/x86/include/asm/pgtable.h |    5 +++++
 arch/x86/mm/init_64.c          |    3 +++
 2 files changed, 8 insertions(+)

arch/x86/include/asm/pgtable.h +5 -0

index 5199db2..1c1a955 100644
@@ -142,6 +142,11 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
 	return (pmd_val(pmd) & PTE_PFN_MASK) >> PAGE_SHIFT;
 }
 
+static inline unsigned long pud_pfn(pud_t pud)
+{
+	return (pud_val(pud) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
 #define pte_page(pte)	pfn_to_page(pte_pfn(pte))
 
 static inline int pmd_large(pmd_t pte)

arch/x86/mm/init_64.c +3 -0

index 2ead3c8..75c9a6a 100644
@@ -831,6 +831,9 @@ int kern_addr_valid(unsigned long addr)
 	if (pud_none(*pud))
 		return 0;
 
+	if (pud_large(*pud))
+		return pfn_valid(pud_pfn(*pud));
+
 	pmd = pmd_offset(pud, addr);
 	if (pmd_none(*pmd))
 		return 0;

Ingo Molnar

2013-02-13 11:10 UTC #5 lore raw

Re: [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2

Quoted 1 line · Mel Gorman

Andrew or Ingo, please pick up.

Already did - will push it out later today.

Thanks,

Ingo

Mel Gorman

author

2013-02-13 11:14 UTC #6 lore raw

Re: [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2

Quoted 7 lines · Ingo Molnar

Quoted 1 line · Mel Gorman
Andrew or Ingo, please pick up.
Already did - will push it out later today.

Whoops, thanks. Sorry for the noise.

Signature · 8 lines

Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Simon Jeons

2013-03-01 06:44 UTC #7 lore raw

Re: [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2

In reply to Mel Gorman

Quoted 40 lines · Mel Gorman

Andrew or Ingo, please pick up.

Changelog since v1
o Add reviewed-bys and acked-bys

A user reported a bug whereby a backup process accessing /proc/kcore caused an oops.

  BUG: unable to handle kernel paging request at ffffbb00ff33b000
  IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
  PGD 0
  Oops: 0000 [#1] SMP
  CPU 6
  Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod

Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614

  RIP: 0010:[<ffffffff8103157e>]  [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
  RSP: 0018:ffff88094165fe80  EFLAGS: 00010246
  RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
  RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
  RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
  R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
  R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
  FS:  00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
  Stack:
   ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
   ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
   0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
  Call Trace:
   [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
   [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
   [<ffffffff81151687>] vfs_read+0xc7/0x130
   [<ffffffff811517f3>] sys_read+0x53/0xa0
   [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Quoted 2 lines

Investigation determined that the bug triggered when reading system RAM at the 4G mark. On this system, that was the first address using 1G pages

Do you mean there is one page which is 1G?

Quoted 50 lines

for the virt->phys direct mapping so the PUD is pointing to a physical address, not a PMD page. The problem is that the page table walker in kern_addr_valid() is not checking pud_large() and treats the physical address as if it was a PMD. If it happens to look like pmd_none then it'll silently fail, probably returning zeros instead of real data. If the data happens to look like a present PMD though, it will be walked resulting in the oops above. This patch adds the necessary pud_large() check.
Cc [email protected]
Signed-off-by Mel Gorman <[email protected]>
Reviewed-by Rik van Riel <[email protected]>
Reviewed-by Michal Hocko <[email protected]>
Acked-by Johannes Weiner <[email protected]>
---
  arch/x86/include/asm/pgtable.h |    5 +++++
  arch/x86/mm/init_64.c          |    3 +++
  2 files changed, 8 insertions(+)
arch/x86/include/asm/pgtable.h +5 -0
index 5199db2..1c1a955 100644
@@ -142,6 +142,11 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
  	return (pmd_val(pmd) & PTE_PFN_MASK) >> PAGE_SHIFT;
  }
 
+static inline unsigned long pud_pfn(pud_t pud)
+{
+	return (pud_val(pud) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
  #define pte_page(pte)	pfn_to_page(pte_pfn(pte))
 
  static inline int pmd_large(pmd_t pte)
arch/x86/mm/init_64.c +3 -1
index 2ead3c8..75c9a6a 100644
@@ -831,6 +831,9 @@ int kern_addr_valid(unsigned long addr)
  	if (pud_none(*pud))
  		return 0;
 
+	if (pud_large(*pud))
+		return pfn_valid(pud_pfn(*pud));
+
  	pmd = pmd_offset(pud, addr);
  	if (pmd_none(*pmd))
  		return 0;
 
--

Quoted 4 lines

To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Chen Gong

2013-03-01 09:17 UTC #8 lore raw

Re: [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2

Quoted 52 lines · Simon Jeons

Date: Fri, 01 Mar 2013 14:43:53 +0800
From: Simon Jeons <[email protected]>
To: Mel Gorman <[email protected]>
CC: Ingo Molnar <[email protected]>, Andrew Morton
<[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] x86: mm: Check if PUD is large when validating a
kernel address v2
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221
Thunderbird/17.0.3

Quoted 40 lines · Mel Gorman

Andrew or Ingo, please pick up.

Changelog since v1
o Add reviewed-bys and acked-bys

A user reported a bug whereby a backup process accessing /proc/kcore caused an oops.

 BUG: unable to handle kernel paging request at ffffbb00ff33b000
 IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 PGD 0
 Oops: 0000 [#1] SMP
 CPU 6
 Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod

Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614

 RIP: 0010:[<ffffffff8103157e>]  [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 RSP: 0018:ffff88094165fe80  EFLAGS: 00010246
 RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
 RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
 RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
 R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
 R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
 FS:  00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
 Stack:
  ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
  ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
  0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
 Call Trace:
  [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
  [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
  [<ffffffff81151687>] vfs_read+0xc7/0x130
  [<ffffffff811517f3>] sys_read+0x53/0xa0
  [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Quoted 5 lines

Quoted 2 lines
Investigation determined that the bug triggered when reading system RAM at the 4G mark. On this system, that was the first address using 1G pages
Do you mean there is one page which is 1G?

1GB support in native kernel is started from 2.6.27 with these 2 commits:
39c11e6 and b4718e6. For Intel CPU, from Westmere it supports 1GB page. BTW, IBM System x3550 M3 is a Westmere based system.

Simon Jeons

2013-03-01 09:21 UTC #9 lore raw

Re: [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2

Quoted 53 lines · Chen Gong

Quoted 52 lines · Simon Jeons

Quoted 40 lines · Mel Gorman

Andrew or Ingo, please pick up.

Changelog since v1
o Add reviewed-bys and acked-bys

A user reported a bug whereby a backup process accessing /proc/kcore caused an oops.

  BUG: unable to handle kernel paging request at ffffbb00ff33b000
  IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
  PGD 0
  Oops: 0000 [#1] SMP
  CPU 6
  Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod

Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614

  RIP: 0010:[<ffffffff8103157e>]  [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
  RSP: 0018:ffff88094165fe80  EFLAGS: 00010246
  RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
  RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
  RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
  R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
  R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
  FS:  00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
  Stack:
   ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
   ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
   0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
  Call Trace:
   [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
   [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
   [<ffffffff81151687>] vfs_read+0xc7/0x130
   [<ffffffff811517f3>] sys_read+0x53/0xa0
   [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Quoted 5 lines

Quoted 4 lines
Quoted 2 lines
Investigation determined that the bug triggered when reading system RAM at the 4G mark. On this system, that was the first address using 1G pages
Do you mean there is one page which is 1G?
1GB support in native kernel is started from 2.6.27 with these 2 commits:

Why call kernel native? Which kend of kernel is not native?

Quoted 2 lines

39c11e6 and b4718e6. For Intel CPU, from Westmere it supports 1GB page. BTW, IBM System x3550 M3 is a Westmere based system.

Is it only used in hugetlbfs page?

Chen Gong

2013-03-01 09:37 UTC #10 lore raw

Re: [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2

Quoted 64 lines · Simon Jeons

Date: Fri, 01 Mar 2013 17:21:35 +0800
From: Simon Jeons <[email protected]>
To: Mel Gorman <[email protected]>, Ingo Molnar <[email protected]>, Andrew
Morton <[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] x86: mm: Check if PUD is large when validating a
kernel address v2
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221
Thunderbird/17.0.3
Quoted 53 lines · Chen Gong
Quoted 52 lines · Simon Jeons
Date: Fri, 01 Mar 2013 14:43:53 +0800
From: Simon Jeons <[email protected]>
To: Mel Gorman <[email protected]>
CC: Ingo Molnar <[email protected]>, Andrew Morton
<[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] x86: mm: Check if PUD is large when validating a
kernel address v2
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221
Thunderbird/17.0.3
Quoted 40 lines · Mel Gorman
Andrew or Ingo, please pick up.
Changelog since v1
o Add reviewed-bys and acked-bys
A user reported a bug whereby a backup process accessing /proc/kcore caused an oops.
 BUG: unable to handle kernel paging request at ffffbb00ff33b000
 IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 PGD 0
 Oops: 0000 [#1] SMP
 CPU 6
 Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod
Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614
 RIP: 0010:[<ffffffff8103157e>]  [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 RSP: 0018:ffff88094165fe80  EFLAGS: 00010246
 RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
 RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
 RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
 R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
 R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
 FS:  00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
 Stack:
  ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
  ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
  0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
 Call Trace:
  [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
  [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
  [<ffffffff81151687>] vfs_read+0xc7/0x130
  [<ffffffff811517f3>] sys_read+0x53/0xa0
  [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Quoted 7 lines

Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
Investigation determined that the bug triggered when reading system RAM at the 4G mark. On this system, that was the first address using 1G pages
Do you mean there is one page which is 1G?
1GB support in native kernel is started from 2.6.27 with these 2 commits:
Why call kernel native? Which kend of kernel is not native?

relative to VMM like Xen.

Quoted 4 lines

Quoted 3 lines
39c11e6 and b4718e6. For Intel CPU, from Westmere it supports 1GB page. BTW, IBM System x3550 M3 is a Westmere based system.
Is it only used in hugetlbfs page?

Yes by now.

Simon Jeons

2013-03-01 09:40 UTC #11 lore raw

Re: [PATCH] x86: mm: Check if PUD is large when validating a kernel address v2

Quoted 65 lines · Chen Gong

Quoted 64 lines · Simon Jeons
Date: Fri, 01 Mar 2013 17:21:35 +0800
From: Simon Jeons <[email protected]>
To: Mel Gorman <[email protected]>, Ingo Molnar <[email protected]>, Andrew
Morton <[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] x86: mm: Check if PUD is large when validating a
kernel address v2
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221
Thunderbird/17.0.3
Quoted 53 lines · Chen Gong
Quoted 52 lines · Simon Jeons
Date: Fri, 01 Mar 2013 14:43:53 +0800
From: Simon Jeons <[email protected]>
To: Mel Gorman <[email protected]>
CC: Ingo Molnar <[email protected]>, Andrew Morton
<[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] x86: mm: Check if PUD is large when validating a
kernel address v2
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221
Thunderbird/17.0.3
Quoted 40 lines · Mel Gorman
Andrew or Ingo, please pick up.
Changelog since v1
o Add reviewed-bys and acked-bys
A user reported a bug whereby a backup process accessing /proc/kcore caused an oops.
  BUG: unable to handle kernel paging request at ffffbb00ff33b000
  IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
  PGD 0
  Oops: 0000 [#1] SMP
  CPU 6
  Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc 8021q garp stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod ioatdma ipv6 ipv6_lib igb dca i7core_edac edac_core i2c_i801 i2c_core cdc_ether usbnet bnx2 mii iTCO_wdt iTCO_vendor_support shpchp rtc_cmos pci_hotplug tpm_tis sg tpm pcspkr tpm_bios serio_raw button ext3 jbd mbcache uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif usb_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod
Pid: 16196, comm: Hibackp Not tainted 3.0.13-0.27-default #1 IBM System x3550 M3 -[7944 K3G]-/94Y7614
  RIP: 0010:[<ffffffff8103157e>]  [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
  RSP: 0018:ffff88094165fe80  EFLAGS: 00010246
  RAX: 00003300ff33b000 RBX: ffff880100000000 RCX: 0000000000000000
  RDX: 0000000100000000 RSI: ffff880000000000 RDI: ff32b300ff33b400
  RBP: 0000000000001000 R08: 00003ffffffff000 R09: 0000000000000000
  R10: 22302e31223d6e6f R11: 0000000000000246 R12: 0000000000001000
  R13: 0000000000003000 R14: 0000000000571be0 R15: ffff88094165ff50
  FS:  00007ff152d33700(0000) GS:ffff88097f2c0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: ffffbb00ff33b000 CR3: 00000009405a3000 CR4: 00000000000006e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Process Hibackp (pid: 16196, threadinfo ffff88094165e000, task ffff8808eb9ba600)
  Stack:
   ffffffff811b8aaa 0000000000004000 ffff880943fea480 ffff8808ef2bae50
   ffff880943d32980 fffffffffffffffb ffff8808ef2bae40 ffff88094165ff50
   0000000000004000 000000000056ebe0 ffffffff811ad847 000000000056ebe0
  Call Trace:
   [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
   [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
   [<ffffffff81151687>] vfs_read+0xc7/0x130
   [<ffffffff811517f3>] sys_read+0x53/0xa0
   [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Quoted 7 lines

Quoted 6 lines
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
Investigation determined that the bug triggered when reading system RAM at the 4G mark. On this system, that was the first address using 1G pages
Do you mean there is one page which is 1G?
1GB support in native kernel is started from 2.6.27 with these 2 commits:
Why call kernel native? Which kend of kernel is not native?
relative to VMM like Xen.

Oh, I see. Thanks. :)

Quoted 5 lines

Quoted 4 lines
Quoted 3 lines
39c11e6 and b4718e6. For Intel CPU, from Westmere it supports 1GB page. BTW, IBM System x3550 M3 is a Westmere based system.
Is it only used in hugetlbfs page?
Yes by now.

tip-bot for Mel Gorman

author

2013-02-13 12:14 UTC #12 lore raw

[tip:x86/urgent] x86/mm: Check if PUD is large when validating a kernel address

In reply to Mel Gorman

Commit-ID:  0ee364eb316348ddf3e0dfcd986f5f13f528f821
Gitweb:     http://git.kernel.org/tip/0ee364eb316348ddf3e0dfcd986f5f13f528f821
Author:     Mel Gorman <[email protected]>
AuthorDate: Mon, 11 Feb 2013 14:52:36 +0000
Committer:  Ingo Molnar <[email protected]>
CommitDate: Wed, 13 Feb 2013 10:02:55 +0100

x86/mm: Check if PUD is large when validating a kernel address

A user reported the following oops when a backup process reads /proc/kcore:

 BUG: unable to handle kernel paging request at ffffbb00ff33b000
 IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 [...]

 Call Trace:
  [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
  [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
  [<ffffffff81151687>] vfs_read+0xc7/0x130
  [<ffffffff811517f3>] sys_read+0x53/0xa0
  [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

The problem is that the page table walker in kern_addr_valid() is not checking pud_large() and treats the physical address as if it was a PMD. If it happens to look like pmd_none then it'll silently fail, probably returning zeros instead of real data. If the data happens to look like a present PMD though, it will be walked resulting in the oops above.

This patch adds the necessary pud_large() check.

Unfortunately the problem was not readily reproducible and now they are running the backup program without accessing /proc/kcore so the patch has not been validated but I think it makes sense.

Signed-off-by Mel Gorman <[email protected]>

Reviewed-by Rik van Riel <[email protected]>

Reviewed-by Michal Hocko <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Cc [email protected]

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

---
 arch/x86/include/asm/pgtable.h | 5 +++++
 arch/x86/mm/init_64.c          | 3 +++
 2 files changed, 8 insertions(+)

arch/x86/include/asm/pgtable.h +5 -0

index 5199db2..1c1a955 100644
@@ -142,6 +142,11 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
 	return (pmd_val(pmd) & PTE_PFN_MASK) >> PAGE_SHIFT;
 }
 
+static inline unsigned long pud_pfn(pud_t pud)
+{
+	return (pud_val(pud) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
 #define pte_page(pte)	pfn_to_page(pte_pfn(pte))
 
 static inline int pmd_large(pmd_t pte)

arch/x86/mm/init_64.c +3 -0

index 2ead3c8..75c9a6a 100644
@@ -831,6 +831,9 @@ int kern_addr_valid(unsigned long addr)
 	if (pud_none(*pud))
 		return 0;
 
+	if (pud_large(*pud))
+		return pfn_valid(pud_pfn(*pud));
+
 	pmd = pmd_offset(pud, addr);
 	if (pmd_none(*pmd))
 		return 0;