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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
