From owner-freebsd-stable@FreeBSD.ORG Mon Aug 25 21:26:56 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08EEF16A4BF for ; Mon, 25 Aug 2003 21:26:56 -0700 (PDT) Received: from bricore.com (adsl-64-168-71-68.dsl.snfc21.pacbell.net [64.168.71.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BF5143FE3 for ; Mon, 25 Aug 2003 21:26:55 -0700 (PDT) (envelope-from lchen@briontech.com) Received: from lchenpc (lchen-pc.bricore.com [192.168.1.130]) (authenticated bits=0) by bricore.com (8.12.6/8.12.6) with ESMTP id h7Q4QkSg064912; Mon, 25 Aug 2003 21:26:46 -0700 (PDT) (envelope-from lchen@briontech.com) From: "Luoqi Chen" To: "David G. Lawrence" , "Peter Wemm" Date: Mon, 25 Aug 2003 21:27:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20030826034451.GD61917@nexus.dglawrence.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Virus-Scanned: by amavisd-milter (http://amavis.org/) cc: Mike Silbersack cc: stable@freebsd.org Subject: RE: PAE removal patch for testing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2003 04:26:56 -0000 > > > > I've reviewed it as well and it definitely is a bug that > needs to be fixed > > ASAP. Basically, the pmap_remove code in -stable doesn't handle > the case of > > crossing a page table boundry properly. If the next page table > page isn't > > currently mapped, then the kernel will [fatally] fault when > trying to access > > it. > > Hmmm...after pushing send I'm wondering if I'm mistaken about > the problem. > Nevermind. :-) > > -DG > The real problem is pmap_remove_pte() code could block (when releasing a pte page), allowing another process to come in and change the temporary pde mapping (PMAP1). The old pmap code used APTD for this mapping, so theoretically had the same problem, but APTD was much less frequently used... -lq