From owner-freebsd-hackers Fri Aug 24 17:21:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id E235337B40C for ; Fri, 24 Aug 2001 17:21:38 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA60805; Fri, 24 Aug 2001 17:32:38 -0700 (PDT) Date: Fri, 24 Aug 2001 17:32:37 -0700 (PDT) From: Julian Elischer To: Matt Dillon Cc: Alfred Perlstein , David Greenman , freebsd-hackers@FreeBSD.ORG Subject: Re: Possible race in i386/i386/pmap.c:pmap_copy() In-Reply-To: <200108241645.f7OGjgX96286@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG wouldn't Giant be protecting this? On Fri, 24 Aug 2001, Matt Dillon wrote: > Alfred, DG, could you take a look at pmap_copy() in i386/i386/pmap.c > and tell me if what I think I'm seeing is what I'm seeing? > > My read of this code is that a global, APTDpde, is being set, and > then that pointer is being used in a loop later on in the routine. > the problem is that the pmap_allocpte() call can block and, by my > read, that means some other process can go in and change APTDpde out > from under the loop. > > This could also be related to problem Julian has been seeing with his > KSE patch set. > > There is a comment: > > /* > * We have to check after allocpte for the > * pte still being around... allocpte can > * block. > */ > dstmpte = pmap_allocpte(dst_pmap, addr); > if ((*dst_pte == 0) && (ptetemp = *src_pte)) { > /* > * Clear the modified and > ... > It seems real but it isn't causeing my problem as far as I can see. I added code to compare the Alternate PTD entry to the value set into it and it isn't changing.. > But I do not believe this check is sufficient if APTDpde gets ripped > out from under the loop. Is this race real or am I blowing smoke? > I read it through and you are correct in that pmap_allocpte() can block. (I followed it thropugh,, there are at least 2 tsleeps in the functions it calls. Despite that I'm stil getting the same errors as yesterday.. (only the printf shows more info now).. TPTE at 0xbfca0144 IS ZERO @ VA 28051000 TPTE at 0xbfca0188 IS ZERO @ VA 28062000 > -Matt > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message