Date: Thu, 07 Oct 2010 12:03:28 -0500 From: Alan Cox <alc@rice.edu> To: Kurt Alstrup <kalstrup@verizon.net> Cc: freebsd-stable@freebsd.org Subject: Re: Panic: attempted pmap_enter on 2MB page Message-ID: <4CADFD60.9040005@rice.edu> In-Reply-To: <4CAC14DA.7050409@verizon.net> References: <4CAC14DA.7050409@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CADFD60.9040005>