ptrace on linux 2.6.12 causes oops

[Anton Wöllert]

> 
> Yep, just that now its the ptraceing process which is faulting in the 
> page,
> instead of the (ptraced) process itself.
> 
> So Anton, can you move the _tlbie() call up to
> 
> && !test_bit(PG_arch_1, &page->flags)) {
> <---------- HERE
> if (vma->vm_mm == current->active_mm)
> __flush_dcache_icache((void *) address);
> else
> flush_dcache_icache_page(page);
> set_bit(PG_arch_1, &page->flags);
> 
> So that it covers both cases instead of just (vma->vm_mm == 
> current->active_mm) ?
> 
> Its safe to do it because the address space ID is ignored by tlbie 
> accordingly
> to the manual page:
> 
> The ASID value in the entry is ignored for the purpose of
> matching an invalidate address, thus multiple entries can be invalidated
> if they have the same effective address and different ASID values.



Well, unfortunately, that doesn't work :(. If i'm right, the 
__flush_dcache_icache((void *) address) should avoid that the cache says 
faulting address again.
The flush_dcache_icache_page(page) should flush the cache, where stands, 
page not mapped. but the flush_dcache_icache_page(page) oopses on my system. 
but instead of this call, the call __flush_dcache_icache(page_address(page)) 
works. for me, that also makes more sence. and also, the 
flush_dcache_icache_page(page) calls the flush_dcache_icache_phys, which 
turns off the data virtual address mapping. i found that a bit strange. any 
comments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050715/5a6ed5a4/attachment.htm