Re: ptrace on linux 2.6.12 causes oops

Hi Anton,

On Fri, Jul 15, 2005 at 11:42:27AM +0200, Anton W=F6llert wrote:

quoted

=20
Yep, just that now its the ptraceing process which is faulting in the=

=20

quoted

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

ted

quoted

if they have the same effective address and different ASID values.

=20
=20
=20
Well, unfortunately, that doesn't work :(.=20

Oh doh, on the case where the process faulting in the page is not the own=
er of the
vma (which is the case with ptrace here), the flushing is done via the ph=
ysical address.

So its expected that the _tlbie() on the process virtual address will not=
 change=20
a thing, since flush_dcache_icache_page() is working on the physical addr=
ess.

If i'm right, the=20
__flush_dcache_icache((void *) address) should avoid that the cache say=

s=20

faulting address again.
The flush_dcache_icache_page(page) should flush the cache, where stands=

,=20

page not mapped. but the flush_dcache_icache_page(page) oopses on my sy=

stem.=20

but instead of this call, the call __flush_dcache_icache(page_address(p=

age))=20

works. for me, that also makes more sence.=20

Well, you end up flushing the page through its kernel virtual address map=
ping (returned
by page_address()).=20

It will be necessary for the kernel virtual map to be faulted in the TLB,=
 which is=20
certainly slower than doing the direct physical address flush (requires u=
pdating=20
the MSR twice (+isync) to turn the MMU on/off).

But other than that I see no problem with your suggestion really, as to w=
orkaround the=20
oops.

Still, we should try to understand what is going on...

and also, the flush_dcache_icache_page(page) calls the flush_dcache_ica=

che_phys, which=20

turns off the data virtual address mapping. i found that a bit strange.=

 any=20

comments?=20

It seems that the instruction at "__flush_dcache_icache_phys+0x38" is icb=
i - can you send=20
the disassembly of __flush_dcache_icache_phys? =20

We should figure out what is causing the oops.=20

What is causing DAR to be set to "00000010"? ie why the hell is it trying=
 to access=20
the 00000010 address.

Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tai=
nted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 00000010, DSISR: C2000000
TASK =3D c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
00000001
GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
00000001
GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
C01E0000
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30