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: