0

Recently I have met an error "Corrupted page table at address ffff88007eccb080" with the Oops: 0009 [#1]. With the information from http://lxr.linux.no/#linux+v3.9.4/arch/x86/mm/fault.c#L29

Page fault error code bits:
bit 0 ==    0: no page found       1: protection fault
bit 1 ==    0: read access         1: write access
bit 2 ==    0: kernel-mode access  1: user-mode access
bit 3 ==                           1: use of reserved bit detected
bit 4 ==                           1: fault was an instruction fetch

The error is due to protection fault and use of reserved bit detected. Do these sources really cause the corrupted page table at address ffff88007eccb080?

Is there anyway that I can identify which process this virtual address is mapped to and cause corrupted at that address?

Thank you

Armali
  • 18,255
  • 14
  • 57
  • 171
Naruto
  • 315
  • 2
  • 6
  • 13
  • You could check whether http://lkml.org/lkml/2013/4/14/107 applies (although it is about error code 000f, not 0009). – Armali Jun 10 '13 at 12:14

1 Answers1

0

From https://bugzilla.redhat.com/show_bug.cgi?id=859188#c43:

The "Corrupted page table" message happens when the error code has the PF_RSVD bit set.

So, the use of reserved bit detected bit causes the Oops.

The address ffff88007eccb080 belongs to kernel space (which is shared across all processes), not to the private virtual address space of any user process.

Armali
  • 18,255
  • 14
  • 57
  • 171
  • I dump the kernel page table and find that the address ffff88007eccb080 belongs to low memory kernel space as you also said. So you means since the address ffff88007eccb080 belongs to kernel space and shares for all processes. One of process has occupied this address and set PF_RSVD bit, then another process tries to write to this address and causes this error. – Naruto Jun 11 '13 at 02:54
  • When kernel memory is corrupted, this should be due to an error in the kernel itself, or a loadable module, or the hardware, etc. If you are lucky, it's a bug that is already fixed in a newer kernel version. – Armali Jun 11 '13 at 06:40
  • Another question is that do you know where the PR_RSVD is set in kernel source? – Naruto Jun 12 '13 at 02:41
  • Since modules run in kernel context, kernel memory is not protected against buggy modules, and one can corrupt any kernel data structure. – Armali Jun 12 '13 at 07:31
  • You have probably already searched the kernel source - e. g. at https://github.com/torvalds/linux - and seen that `PF_RSVD` is not set there. I'm not familiar with x86 memory management, but I think that this bit is set by the MM hardware. – Armali Jun 12 '13 at 07:34
  • Perhaps http://stackoverflow.com/questions/8788289/how-remap-pfn-range-remaps-kernel-memory-to-user-space is of note to you. – Armali Jun 12 '13 at 07:43