From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by ozlabs.org (Postfix) with ESMTP id 8FF4167A79 for ; Fri, 15 Jul 2005 19:42:28 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 9so335409nzo for ; Fri, 15 Jul 2005 02:42:27 -0700 (PDT) Message-ID: Date: Fri, 15 Jul 2005 11:42:27 +0200 From: =?ISO-8859-1?Q?Anton_W=F6llert?= To: Marcelo Tosatti In-Reply-To: <20050714111941.GC5179@dmt.cnet> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_278_26635838.1121420547509" References: <42C1AAC1.4060702@gmail.com> <20050629085913.GA2153@logos.cnet> <20050701094438.GA11121@logos.cnet> <1120229717.21507.9.camel@jmcmullan.timesys> <20050701101713.GC11121@logos.cnet> <20050714202715.GS19321@oops.ghostprotocols.net> <20050714111941.GC5179@dmt.cnet> Cc: linux-ppc-embedded Subject: Re: ptrace on linux 2.6.12 causes oops Reply-To: =?ISO-8859-1?Q?Anton_W=F6llert?= List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , ------=_Part_278_26635838.1121420547509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline >=20 > Yep, just that now its the ptraceing process which is faulting in the=20 > 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 invalidated > if they have the same effective address and different ASID values. Well, unfortunately, that doesn't work :(. If i'm right, the=20 __flush_dcache_icache((void *) address) should avoid that the cache says=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 system= .=20 but instead of this call, the call __flush_dcache_icache(page_address(page)= )=20 works. for me, that also makes more sence. and also, the=20 flush_dcache_icache_page(page) calls the flush_dcache_icache_phys, which=20 turns off the data virtual address mapping. i found that a bit strange. any= =20 comments? ------=_Part_278_26635838.1121420547509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Yep, just th= at 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

  &= nbsp;           &nbs= p;     && !test_bit(PG_arch_1, &page->flags)) {
    &nb= sp;            =             &nb= sp;            =             &nb= sp;         <---------- HERE
           &= nbsp;           &nbs= p;if (vma->vm_mm =3D=3D current->active_mm)
    &nb= sp;            =             &nb= sp;  __flush_dcache_icache((void *) address);
          = ;            &n= bsp; else
         &nb= sp;            =           flush_dcache_ic= ache_page(page);
         &= nbsp;           &nbs= p;  set_bit(PG_arch_1, &page->flags);

So that it covers both cases instead of just (= vma->vm_mm =3D=3D current->active_mm) ?

Its safe to do it beca= use the address space ID is ignored by tlbie accordingly
to the manual p= age:

The ASID value in the entry is ignored for the purpose of
matchi= ng an invalidate address, thus multiple entries can be invalidated
if th= ey 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?

------=_Part_278_26635838.1121420547509--