Date: Thu, 10 Sep 2009 15:08:11 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: MingyanGuo <guomingyan@gmail.com> Cc: freebsd-hackers@freebsd.org, LI Xin <delphij@delphij.net> Subject: Re: How to prevent other CPU from accessing a set of pages before calling pmap_remove_all function Message-ID: <20090910120811.GH47688@deviant.kiev.zoral.com.ua> In-Reply-To: <1fa17f810909092357x8625182q970f8fb6aa76e7a9@mail.gmail.com> References: <1fa17f810909092326l1271df94t1dea5ac9d5deba1b@mail.gmail.com> <1fa17f810909092357x8625182q970f8fb6aa76e7a9@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--spzFwWfYKRzjK1rH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Sep 09, 2009 at 11:57:24PM -0700, MingyanGuo wrote:
> On Wed, Sep 9, 2009 at 11:26 PM, MingyanGuo <guomingyan@gmail.com> wrote:
>=20
> > Hi all,
> >
> > I find that function pmap_remove_all for arch amd64 works with a time
> > window between reading & clearing the PTE flags(access flag and dirty f=
lag)
> > and invalidating its TLB entry on other CPU. After some discussion with=
Li
> > Xin(cced), I think all the processes that are using the PTE being remov=
ed
> > should be blocked before calling pmap_remove_all, or other CPU may dirt=
y the
> > page but does not set the dirty flag before the TLB entry is flushed. B=
ut I
> > can not find how to block them to call the function. I read the function
> > vm_pageout_scan in file vm/vm_pageout.c but can not find the exact meth=
od it
> > used. Or I just misunderstood the semantics of function pmap_remove_al=
l ?
> >
> > Thanks in advance.
> >
> > Regards,
> > MingyanGuo
> >
>=20
> Sorry for the noise. I understand the logic now. There is no time window
> problem between reading & clearing the PTE and invalidating it on other C=
PU,
> even if other CPU is using the PTE. I misunderstood the logic.
Hmm. What would happen for the following scenario.
Assume that the page m is mapped by vm map active on CPU1, and that
CPU1 has cached TLB entry for some writable mapping of this page,
but neither TLB entry not PTE has dirty bit set.
Then, assume that the following sequence of events occur:
CPU1: CPU2:
call pmap_remove_all(m)
clear pte
write to the address mapped
by m [*]
invalidate the TLB,
possibly making IPI to CPU1
I assume that at the point marked [*], we can
- either loose the dirty bit, while CPU1 (atomically) sets the dirty bit
in the cleared pte.
Besides not properly tracking the modification status of the page,
it could also cause the page table page to be modified, that would
create non-zero page with PG_ZERO flag set.
- or CPU1 re-reads the PTE entry when setting the dirty bit, and generates
#pf since valid bit in PTE is zero.
Intel documentation mentions that dirty or accessed bits updates are done
with locked cycle, that definitely means that PTE is re-read, but I cannot
find whether valid bit is rechecked.
--spzFwWfYKRzjK1rH
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkqo7CoACgkQC3+MBN1Mb4gRGgCgscvKZFeh4uPhTADH2tERZtVh
Y98AnR/9HAbNm6DqTmKYv+LtC/FaJGMW
=gKPs
-----END PGP SIGNATURE-----
--spzFwWfYKRzjK1rH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090910120811.GH47688>