Date: Fri, 24 Aug 2001 17:32:37 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: 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: <Pine.BSF.4.21.0108241601520.59663-100000@InterJet.elischer.org> In-Reply-To: <200108241645.f7OGjgX96286@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0108241601520.59663-100000>