Subject: port-i386/18244: pmap_enter(..., PMAP_CANFAIL) vs. DIAGNOSTIC Check in pmap_get_ptp()
To: None <gnats-bugs@gnats.netbsd.org>
From: Chris Jepeway <jepeway@blasted-heath.com>
List: netbsd-bugs
Date: 09/09/2002 18:11:13
>Number:         18244
>Category:       port-i386
>Synopsis:       pmap_enter(PMAP_CANFAIL) conflicts with DIAGNOSTIC pmap_get_ptp()
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 09 15:12:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Chris M. Jepeway
>Release:        NetBSD 1.5Y
>Organization:
    Blasted Heath Consulting, LLC
>Environment:
System: NetBSD pos 1.5Y NetBSD 1.5Y (POS) #8: Tue Aug 27 16:45:33 EDT 2002 jepeway@the-morrigan:/src/nss/src/sys/arch/i386/compile/POS i386
Architecture: i386
Machine: i386
>Description:
	pmap_enter() can be called with the PMAP_CANFAIL flag set.
	That tells pmap_enter() not to panic() when, eg, pmap_get_ptp()
	returns NULL.  However, when compiled with DIAGNOSTIC turned
	on, pmap_get_ptp() will panic() instead of failing.  So,
	PMAP_CANFAIL passed to pmap_enter() in a DIAGNOSTIC kernel
	really means PMAP_CANPANIC.
>How-To-Repeat:
	Hm.  By inspection, I guess.  Or, load a machine w/ 4G RAM,
	start using it all up, and see whether you can get pmap_get_ptp()
	to panic() a DIAGNOSTIC kernel.  That's how I first heard of the
	problem.

	Looks like -current will still have this problem, too.
>Fix:
	I think pmap_get_ptp() is only called from pmap_enter(), so
	it's safe to kill the DIAGNOSTIC code in pmap_get_ptp().  This,
	since pmap_enter() will panic() if pmap_get_ptp() fails but
	PMAP_CANFAIL isn't set.
>Release-Note:
>Audit-Trail:
>Unformatted: