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");
Hi Konstantin, Thank you for your prompt response. I will test and report from next monday.>> 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.Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable? Could you please explain me? Regards, Kohji Okuno> 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-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"_______________________________________________ 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"
Hi Konstantin, I tested your patch. It was no problem. Thank you for your kind correspondence. Regards, Kohji Okuno> 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-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"_______________________________________________ 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"