Panic: attempted pmap_enter on 2MB page
Alan Cox
alc at rice.edu
Thu Oct 7 17:03:30 UTC 2010
Kurt Alstrup wrote:
> Up front disclaimer: I may very well be wrong on this..
>
>
At a high-level, I agree with much of what you say. In particular, if
pmap_enter() is applied to a virtual address that is already mapped by a
large page, the reported panic could result. However, barring bugs, for
example, in memory allocation by the upper levels of the kernel, the
panic inducing situation shouldn't occur.
At a lower-level, it appears that you are misinterpreting what
pmap_unuse_pt() does. It is not pmap_unuse_pt()'s responsibility to
clear page table entries, either for user-space page tables or the
kernel page table. When a region of the kernel virtual address space is
deallocated, we do clear the kernel page table entries. See, for
example, pmap_remove_pte() (or pmap_qremove()).
The special case for the kernel page table in pmap_unuse_pt() has a
different purpose. User-space page table pages are reference counted.
When there are no longer any valid mappings contained in a user-space
page table page, we remove that page from the page table and free it.
However, for the kernel page table, we never free unused page table
pages. Instead, they persist, but with all of their mappings marked
invalid. In other words, the special case for the kernel page table in
pmap_unuse_pt() is skipping the code that unmaps and frees the unused
page table page.
This special handling of the kernel page table does create another
special case when we destroy a large page mapping within the kernel
address space. We have to reinsert into the kernel page table the old
page table page (for small page mappings) that was sitting idle while
the kernel page table held a large page mapping in its place. At the
same time, all of the page table entries in this page must be
invalidated. This is handled by pmap_remove_pde().
I'm curious to know more about you were doing when you encountered this
panic. Were you also using ISO images containing large MFS roots?
Regards,
Alan
More information about the freebsd-stable
mailing list