From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 08:00:40 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5505C471; Sat, 4 Oct 2014 08:00:40 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0654FF88; Sat, 4 Oct 2014 08:00:38 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id s9480adI029482; Sat, 4 Oct 2014 17:00:36 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili17) with ESMTP id s9480aA28376; Sat, 4 Oct 2014 17:00:36 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi17) id s9480aRU013147; Sat, 4 Oct 2014 17:00:36 +0900 Received: from localhost by lomi17.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s9480aBG013127; Sat, 4 Oct 2014 17:00:36 +0900 Date: Sat, 04 Oct 2014 17:00:36 +0900 (JST) Message-Id: <20141004.170036.336251378907610162.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com Subject: Re: About pmap_mapdev() & pmap_unmapdev() From: Kohji Okuno In-Reply-To: <20141003215830.GK26076@kib.kiev.ua> References: <20141003.172533.863334695746935674.okuno.kohji@jp.panasonic.com> <20141003215830.GK26076@kib.kiev.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 08:00:40 -0000 Hi, Konstantin, Thank you for your comment. And, your change is better than mine. > 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? Regards, Kohji Okuno int vm_map_delete(vm_map_t map, vm_offset_t start, vm_offset_t end) { >> SNIP << /** this pmap_remove() does not change for mappings! **/ pmap_remove(map->pmap, entry->start, entry->end); /* * Delete the entry only after removing all pmap * entries pointing to its pages. (Otherwise, its * page frames may be reallocated, and any modify bits * will be set in the wrong object!) */ /** this calls vm_page_free_toq() and causes panic! **/ vm_map_entry_delete(map, entry); entry = next; } return (KERN_SUCCESS); } > On Fri, Oct 03, 2014 at 05:25:33PM +0900, Kohji Okuno wrote: >> Hi, >> >> At least in i386 && 9-stable, when we call pmap_mapdev() and >> pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased >> incorrectly. >> >> pmap_mapdev_attr()->pmap_kenter_attr(): >> In this path, kernel_pmap.pm_stats.resident_count is not increlmented. >> >> pmap_unmapdev()->kmem_free(kernel_map)->vm_map_remove()->pmap_remove(): >> But, in this path, kernel_pmap.pm_stats.resident_count is decreased in >> pmap_remove_pte(). >> >> While I called pmap_mapdev() and pmap_unmapdev() repeatedly and >> kernel_pmap.pm_stats.resident_count became `0', since pmap_remove() >> returned without removing ptes, I encountered various kernel panics. > I think you are right. > > The problem seems to be fixed in HEAD and 10, since mapdev was switched > to use kva_alloc/kva_free. I added stable@ to Cc:. > >> >> And, when I enabled INVARIANTS, I looked the following panic message. >> panic: vm_page_free_toq: freeing mapped page 0xXXXXXXXX. > Do you mean that this panic is related to missed pmap_remove() ? > I doubt it, since pmap_mapdev() does not establish managed mappings. > >> >> I think, I should change the following. >> What do you think about this? >> >> >> diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c >> index 2adc6f8..a0998e8 100644 >> --- a/sys/i386/i386/pmap.c >> +++ b/sys/i386/i386/pmap.c >> @@ -5061,6 +5061,7 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode) >> { >> vm_offset_t va, offset; >> vm_size_t tmpsize; >> + int kmem_allocated = 0; >> >> offset = pa & PAGE_MASK; >> size = roundup(offset + size, PAGE_SIZE); >> @@ -5068,13 +5069,18 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode) >> >> if (pa < KERNLOAD && pa + size <= KERNLOAD) >> va = KERNBASE + pa; >> - else >> + else { >> va = kmem_alloc_nofault(kernel_map, size); >> + kmem_allocated = 1; > > You could just do > PMAP_LOCK(kernel_pmap); > kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size); > PMAP_UNLOCK(kernel_pmap); > there. And, the same fix is needed for amd64. > >> + } >> if (!va) >> panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); >> >> - for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) >> + for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) { >> pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); >> + if (kmem_allocated) >> + kernel_pmap.pm_stats.resident_count++; >> + } >> pmap_invalidate_range(kernel_pmap, va, va + tmpsize); >> pmap_invalidate_cache_range(va, va + size); >> return ((void *)(va + offset)); >> _______________________________________________ >> 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-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"