From owner-cvs-sys  Wed May  7 17:19:12 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id RAA27315
          for cvs-sys-outgoing; Wed, 7 May 1997 17:19:12 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA27293;
          Wed, 7 May 1997 17:18:38 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id KAA25971; Thu, 8 May 1997 10:10:38 +1000
Date: Thu, 8 May 1997 10:10:38 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199705080010.KAA25971@godzilla.zeta.org.au>
To: cvs-all@FreeBSD.ORG, CVS-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG,
        peter@FreeBSD.ORG
Subject: Re: cvs commit:  src/sys/i386/i386 mem.c
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  Modified:    sys/i386/i386  mem.c
>  Log:
>  Don't allow access to illegal addresses in /dev/kmem to panic kernel
>  (eg: above 0xffc00000).  Programs using /dev/kmem are implicitly racing
>  the kernel, and can get right up high in memory.  I've been running
>  these for some time now, but with printfs.  It's saved two panics at
>  least that I can remember.

Isn't the bug actually in pmap_extract() and/or kernacc()?

There seem to be some races for reading /dev/kmem in the kernel itself.
uiomove() can block, and there is nothing to keep the pages from becoming
unmapped.  Perhaps all checking should be deferred to copyin()/copyout()
when the pages are actually accessed.  Lazy checking for user pages is
already handled there and works well.

Bruce