Date: Fri, 24 Aug 2001 23:10:31 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Peter Wemm <peter@wemm.org> Cc: Julian Elischer <julian@elischer.org>, Alfred Perlstein <bright@mu.org>, David Greenman <dg@root.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible race in i386/i386/pmap.c:pmap_copy() Message-ID: <200108250610.f7P6AV404891@earth.backplane.com> References: <20010825055913.1ED783810@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:> Hmm. Ok, I think you are right. APTDpde is what is being loaded
:> and that points into the user page table directory page, which is
:> per-process. So APTDpde should be per-process.
:
:But it is! (sort-of) APTDpde was per-process but is now per-address-space
:with the advent of fork and RFMEM sharing (and KSE).
:
:When we context switch, PTD goes with the process^H^H^H^Haddress space, and
:APTD is merely mapped by the last entry in the per-process PTD
:(PTD[APTDPDTI] if memory serves correctly).
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
Oh !@#$#@$.. you're right! That means there *IS* a race, just that it
is a race in the case where you use rfork. APTDpde can be ripped out
from under one thread by another thread.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108250610.f7P6AV404891>
