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");
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 at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote:> 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.As well as mine.> > (2) should use pmap_resident_count_inc() in amd64.Correct.> > > I will test, later. > > In addtion, I have one question. > In current and 10-stable, is vm_map_delete() called by kva_free()?No, kva_free() only releases the vmem backing, leaving the page tables intact. This is why I only did the stable/9 patch.> If vm_map_delete() is called, this fix is needed in current and > 10-stable, I think.Updated patch below. 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); + pmap_resident_count_inc(kernel_pmap, 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"