Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Nov 2007 16:26:57 -0600 (CST)
From:      Mark Tinguely <tinguely@casselton.net>
To:        freebsd-arm@freebsd.org
Subject:   rare pmap.c bug
Message-ID:  <200711142226.lAEMQvjv014802@casselton.net>

next in thread | raw e-mail | index | archive | help

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 ...

--Mark Tinguely.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711142226.lAEMQvjv014802>