Hi, Konstantin,

> At the end of the mail is commit candidate.  I did not even compiled this.
> Can you test and report back, please ?

Could you check the following?
(1) should use kernel_pmap->pm_stats.resident_count
                          ^^^
    I'm sorry. My patch was wrong. 

(2) should use pmap_resident_count_inc() in amd64.


I will test, later.

In addtion, I have one question.
In current and 10-stable, is vm_map_delete() called by kva_free()?
If vm_map_delete() is called, this fix is needed in current and
10-stable, I think.

Regards,
 Kohji Okuno

> On Sat, Oct 04, 2014 at 05:00:36PM +0900, Kohji Okuno wrote:
>> Hi, Konstantin,
>> 
>> Thank you for your comment.
>> And, your change is better than mine.
> At the end of the mail is commit candidate.  I did not even compiled this.
> Can you test and report back, please ?
> 
>> 
>> > Do you mean that this panic is related to missed pmap_remove() ?
>> > I doubt it, since pmap_mapdev() does not establish managed mappings.
>> 
>> Yes, pmap_mapdev() does not establish managed mappings. But, if
>> kernel_pmap.pm_stats.resident_count is zero, then any managed pages
>> (for example pipe_map, exec_map, or etc.) are not able to change
>> unmanaged status, because pmap_remove() returns without calling
>> pmap_remove_pte().
>> 
>> In this result, I encounterd the panic. Could you refer the following?
> Yes, kmem_back() indeed uses managed mapping.
> 
> Index: amd64/amd64/pmap.c
> ===================================================================
> --- amd64/amd64/pmap.c        (revision 272506)
> +++ amd64/amd64/pmap.c        (working copy)
> @@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
>       pa = trunc_page(pa);
>       for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE)
>               pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
> +     PMAP_LOCK(kernel_pmap);
> +     kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size);
> +     PMAP_UNLOCK(kernel_pmap);
>       pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
>       pmap_invalidate_cache_range(va, va + tmpsize);
>       return ((void *)(va + offset));
> Index: i386/i386/pmap.c
> ===================================================================
> --- i386/i386/pmap.c  (revision 272506)
> +++ i386/i386/pmap.c  (working copy)
> @@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
>       size = roundup(offset + size, PAGE_SIZE);
>       pa = pa & PG_FRAME;
>  
> -     if (pa < KERNLOAD && pa + size <= KERNLOAD)
> +     if (pa < KERNLOAD && pa + size <= KERNLOAD) {
>               va = KERNBASE + pa;
> -     else
> +     } else {
>               va = kmem_alloc_nofault(kernel_map, size);
> +             PMAP_LOCK(kernel_pmap);
> +             kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size);
> +             PMAP_UNLOCK(kernel_pmap);
> +     }
>       if (!va)
>               panic("pmap_mapdev: Couldn't alloc kernel virtual memory");
>  
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to