From owner-freebsd-arm@FreeBSD.ORG Sat Nov 17 17:19:31 2007 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8895116A417 for ; Sat, 17 Nov 2007 17:19:31 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (dong.ci0.org [IPv6:2001:7a8:2066:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BB24D13C44B for ; Sat, 17 Nov 2007 17:19:30 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.14.1/8.13.8) with ESMTP id lAHIBFEX052621; Sat, 17 Nov 2007 19:11:15 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.14.1/8.13.8/Submit) id lAHIBE5h052620; Sat, 17 Nov 2007 19:11:14 +0100 (CET) (envelope-from mlfbsd) Date: Sat, 17 Nov 2007 19:11:14 +0100 From: Olivier Houchard To: Mark Tinguely Message-ID: <20071117181114.GA52582@ci0.org> References: <200711142226.lAEMQvjv014802@casselton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711142226.lAEMQvjv014802@casselton.net> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org Subject: Re: rare pmap.c bug X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2007 17:19:31 -0000 On Wed, Nov 14, 2007 at 04:26:57PM -0600, Mark Tinguely wrote: > > I think there is a small bug in the allocation of the L1 domain numbers ARM > pmap.c BUT it is my guess that no one should ever see in real life. > why? because you have to reuse the L1 9 times AT ONE TIME to trigger the > bug. My gut thinks reusing the L1 twice AT ONE TIME is rare. > > pmap_init_l1() allocates the array l1->l1_domain_free to equal: > > {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 0 } > l1->l1_domain_free[15] is the initial value. > > l1->l1_domain_first = 1 > > pmap_alloc_l1() allocated the odd domain numbers. > > domain = l1->l1_domain_first (1) > l1->l1_domain_first = l1->l1_domain_free[domain] (3) > > next pmap_alloc_l1() **without calling pmap_free_l1()**: > > domain = l1->l1_domain_first (3) > l1->l1_domain_first = l1->l1_domain_free[domain] (5) > > next pmap_alloc_l1() **without calling pmap_free_l1()**: > > domain = l1->l1_domain_first (5) > l1->l1_domain_first = l1->l1_domain_free[domain] (7) > > ... > > domain = l1->l1_domain_first (15) > l1->l1_domain_first = l1->l1_domain_free[domain] (0) > > on the 9th pmap_alloc_l1() **without calling pmap_free_l1()**: > > domain = l1->l1_domain_first (0) <- Kernel domain! > l1->l1_domain_first = l1->l1_domain_free[domain] (2) > > It is extremely unlikely that people are running enough processes on an ARM > machine to ever trigger the bug. A simple fix would be to increment the > l1->l1_domain_free array by 1. But the 15th call to pmap_alloc_l1() will > leave the l1->l1_domain_first wrong with could cause problems with the next > pmap_free_l1(). A zero value could be given a special meaning to pmap_free_l1(). > > I find it even more interesting idea to just pull the preallocated L1s out; > preallocate a couple L1 in an idleloop for perfomance; implement pmap_copy() > to decrease page faults after a fork ... > Hi, Indeed it can be a problem. I'll see how easy it would be to allocate the L1 tables when we need it. Thanks for reporting ! Olivier