【问题标题】:Kernel Oops page fault with corrupted page table内核糟糕的页面错误,页表损坏
【发布时间】:2013-06-07 10:24:28
【问题描述】:

最近我遇到了一个错误“地址 ffff88007eccb080 的页表损坏”,Oops: 0009 [#1]。来自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

错误是由于保护故障和检测到保留位的使用。这些来源真的会导致地址 ffff88007eccb080 处的页表损坏吗?

我是否可以确定该虚拟地址映射到哪个进程并导致该地址损坏?

谢谢

【问题讨论】:

标签: linux virtual-memory


【解决方案1】:

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

当错误代码包含 PF_RSVD 位设置。

所以,use of reserved bit detected 位会导致 Oops。

地址ffff88007eccb080属于内核空间(所有进程共享),不属于任何用户进程的私有虚拟地址空间。

【讨论】:

  • 我转储内核页表,发现地址 ffff88007eccb080 属于低内存内核空间,如您所说。所以你的意思是因为地址 ffff88007eccb080 属于内核空间并为所有进程共享。一个进程占用了这个地址并设置了PF_RSVD位,然后另一个进程试图写入这个地址并导致这个错误。
  • 当内核内存损坏时,这应该是由于内核本身的错误,或者可加载的模块,或者硬件等。如果幸运的话,这是一个已经修复的错误更新的内核版本。
  • 另一个问题是你知道PR_RSVD在内核源代码中的设置位置吗?
  • 由于模块在内核上下文中运行,内核内存没有受到保护以防止有缺陷的模块,并且可以破坏任何内核数据结构。
  • 您可能已经搜索过内核源代码 - e。 G。在github.com/torvalds/linux - 并看到PF_RSVD 没有设置在那里。我不熟悉x86内存管理,但我认为这个位是由MM硬件设置的。
猜你喜欢
  • 2012-10-29
  • 2013-11-08
  • 2020-04-28
  • 1970-01-01
  • 2020-12-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多