Re: Panic: attempted pmap_enter on 2MB page

Kurt Alstrup wrote:
> Apologies for late response, wanted to check the code again.
>
>
> On 10/07/2010 10:03 AM, Alan Cox wrote:
>   
>> Alan Cox wrote:
>> 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.
>>     
> Calls to malloc() of items larger than a page takes a turn through UMA and
> eventually ends up in kmem_malloc() via its page_alloc() routine.
> Kmem_malloc() in turn gets the pages from vm_page_alloc(), parks them in
> the kmem_object and maps them into the kernel_pmap in a loop callings
> pmap_enter() for each page. The assigned VA's are pulled from kmem_map.
> Pages acquired through vm_page_alloc() may be backed by a super page
> reservation and thus are eligible for auto-promotion.
>
> Calls to free() initially take a similar route, ending up on kmem_free()
> via UMAs page_free() routine. From there the call path is vm_map_remove(),
> vm_map_remove(), vm_map_delete() to pmap_remove().
>
> This logic indicate, that from the kernel/vm perspective the malloc/free()
> pair will map/unmap pages as needed. However, the pmapper never unmaps
> these pages as far as I can tell. The call path is pmap_remove(),
> pmap_remove_pte() to pmap_unuse_pt() who ignores the removal because the
> VA >= VM_MAXUSER_ADDRESS.
>
>   

No, consider:

static int
pmap_remove_pte(pmap_t pmap, pt_entry_t *ptq, vm_offset_t va,
    pd_entry_t ptepde, vm_page_t *free)
{
        pt_entry_t oldpte;
        vm_page_t m;

        PMAP_LOCK_ASSERT(pmap, MA_OWNED);
        oldpte = pte_load_clear(ptq);

pte_load_clear() zeroes the PTE, regardless of whether it is a kernel or 
user PTE.

I'm afraid that I need to catch an airplane.  I'll follow up to the rest 
of your message later.

Regards,
Alan

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"