Re: M68k ColdFire ptrace/cache fix

Re: M68k ColdFire ptrace/cache fix

[Michael Eager]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On 07/13/2012 01:06 PM, Geert Uytterhoeven wrote:
> Hi Michael,
>
> On Fri, Jul 13, 2012 at 9:14 PM, Michael Eager <eager@eagercon.com> wrote:
>> I've tracked down a problem in gdb/gdbserver to ptrace() not
>> clearing the i/d cache after modifying memory.
>>
>> To reproduce:
>>    m68k-gcc -g -o cf-gdb-test-no-io cf-gdb-test-no-io.c
>>    scp cf-gdb-test-no-io <target>:/
>>    on target:   gdbserver :1234 cf-gdb-test-no-io
>>    m68k-gcc cf-gdb-test-no-io
>>    (gdb) b 8
>>    (gdb) b 10
>>    (gdb) tar rem <target>:1234
>>    (gdb) c
>>    (gdb) c
>>
>> Program will hit first breakpoint, but not second breakpoint.
>>
>> It appears that the instruction at the last breakpoint location
>> is in the icache and does not get flushed when the bp is written.
>>
>> After applying the attached patch, gdb/gdbserver behavior is correct.
>
> Thanks for your report and patch!

I attached the test program, which I previously forgot.

> Does this happen only in 2.6.29, or also in current kernels?
> The first hunk of your patch no longer applies, as the affected code is
> gone and those cases are now handled purely by the generic code.

I'm working with a client's environment using 2.6.29, so I can't verify
that the same failure occurs in recent kernels.  But I don't see anything
in ptrace.c in the latest kernel which would clear the i/d caches when
writing to memory.

>
> If yes, feel free to take this to linux-m68k@lists.linux-m68k.org.

Done.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077



[-- Attachment #2: cf-gdb-test-no-io.c --]
[-- Type: text/x-csrc, Size: 135 bytes --]

int work (int a)
{
  return a * 2;
}

int main (void)
{
  int a = 10;
  int b = work (a);
  b = work (b);

  a = b * a;

  return 0;
}

[-- Attachment #3: ptrace-cache.patch --]
[-- Type: text/x-patch, Size: 944 bytes --]

--- linux-2.6.29/arch/m68k/kernel/ptrace.c-orig	2012-06-30 06:37:34.000000000 -0700
+++ linux-2.6.29/arch/m68k/kernel/ptrace.c	2012-07-13 11:25:24.000000000 -0700
@@ -24,6 +24,7 @@
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/processor.h>
+#include <asm/cacheflush_mm.h>
 
 /*
  * does not yet catch signals sent when the child dies.
@@ -157,6 +158,8 @@ long arch_ptrace(struct task_struct *chi
 	case PTRACE_POKETEXT:	/* write the word at location addr. */
 	case PTRACE_POKEDATA:
 		ret = generic_ptrace_pokedata(child, addr, data);
+		flush_dcache ();
+		flush_icache ();
 		break;
 
 	case PTRACE_POKEUSR:	/* write the word at location addr in the USER area */
@@ -183,6 +186,8 @@ long arch_ptrace(struct task_struct *chi
 			child->thread.fp[addr - 21] = data;
 		} else
 			goto out_eio;
+		flush_dcache ();
+		flush_icache ();
 		break;
 
 	case PTRACE_SYSCALL:	/* continue and stop at next (return from) syscall */

Re: M68k ColdFire ptrace/cache fix

[Geert Uytterhoeven]

Hi Michael,

On Fri, Jul 13, 2012 at 10:18 PM, Michael Eager <eager@eagercon.com> wrote:
> On 07/13/2012 01:06 PM, Geert Uytterhoeven wrote:
>> On Fri, Jul 13, 2012 at 9:14 PM, Michael Eager <eager@eagercon.com> wrote:
>>> I've tracked down a problem in gdb/gdbserver to ptrace() not
>>> clearing the i/d cache after modifying memory.
>>>
>>> To reproduce:
>>>    m68k-gcc -g -o cf-gdb-test-no-io cf-gdb-test-no-io.c
>>>    scp cf-gdb-test-no-io <target>:/
>>>    on target:   gdbserver :1234 cf-gdb-test-no-io
>>>    m68k-gcc cf-gdb-test-no-io
>>>    (gdb) b 8
>>>    (gdb) b 10
>>>    (gdb) tar rem <target>:1234
>>>    (gdb) c
>>>    (gdb) c
>>>
>>> Program will hit first breakpoint, but not second breakpoint.
>>>
>>> It appears that the instruction at the last breakpoint location
>>> is in the icache and does not get flushed when the bp is written.
>>>
>>> After applying the attached patch, gdb/gdbserver behavior is correct.
>>
>> Thanks for your report and patch!
>
> I attached the test program, which I previously forgot.
>
>> Does this happen only in 2.6.29, or also in current kernels?
>> The first hunk of your patch no longer applies, as the affected code is
>> gone and those cases are now handled purely by the generic code.
>
> I'm working with a client's environment using 2.6.29, so I can't verify
> that the same failure occurs in recent kernels.  But I don't see anything
> in ptrace.c in the latest kernel which would clear the i/d caches when
> writing to memory.

Yeah, even 2.6.29 just called the generic version from the m68k-specific code,
which moved a layer up in more recent kernels (commit
faa47b466935e73251b18b17d51455b06ed65764 ("m68k: use generic code for
ptrace requests") by Andreas).

Anyway, I'd expect the generic code to issue a cache flush/invalidate somewhere
around the road, else it would fail for many more platforms.
So far I couldn't reproduce this (on 3.0 and 3.5-rc6) on 68040 (both ARAnyM
and real hardware). Hence I'm more inclined to believe this is an issue in the
Coldfire-specific code, cfr. the recent cache issues Greg discovered
(http://www.mail-archive.com/linux-m68k@vger.kernel.org/msg04929.html).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: M68k ColdFire ptrace/cache fix

[Michael Eager]

On 07/15/2012 04:54 AM, Geert Uytterhoeven wrote:
> Hi Michael,
>
> On Fri, Jul 13, 2012 at 10:18 PM, Michael Eager <eager@eagercon.com> wrote:
>> On 07/13/2012 01:06 PM, Geert Uytterhoeven wrote:
>>> On Fri, Jul 13, 2012 at 9:14 PM, Michael Eager <eager@eagercon.com> wrote:
>>>> I've tracked down a problem in gdb/gdbserver to ptrace() not
>>>> clearing the i/d cache after modifying memory.
>>>>
>>>> To reproduce:
>>>>     m68k-gcc -g -o cf-gdb-test-no-io cf-gdb-test-no-io.c
>>>>     scp cf-gdb-test-no-io <target>:/
>>>>     on target:   gdbserver :1234 cf-gdb-test-no-io
>>>>     m68k-gcc cf-gdb-test-no-io
>>>>     (gdb) b 8
>>>>     (gdb) b 10
>>>>     (gdb) tar rem <target>:1234
>>>>     (gdb) c
>>>>     (gdb) c
>>>>
>>>> Program will hit first breakpoint, but not second breakpoint.
>>>>
>>>> It appears that the instruction at the last breakpoint location
>>>> is in the icache and does not get flushed when the bp is written.
>>>>
>>>> After applying the attached patch, gdb/gdbserver behavior is correct.
>>>
>>> Thanks for your report and patch!
>>
>> I attached the test program, which I previously forgot.
>>
>>> Does this happen only in 2.6.29, or also in current kernels?
>>> The first hunk of your patch no longer applies, as the affected code is
>>> gone and those cases are now handled purely by the generic code.
>>
>> I'm working with a client's environment using 2.6.29, so I can't verify
>> that the same failure occurs in recent kernels.  But I don't see anything
>> in ptrace.c in the latest kernel which would clear the i/d caches when
>> writing to memory.
>
> Yeah, even 2.6.29 just called the generic version from the m68k-specific code,
> which moved a layer up in more recent kernels (commit
> faa47b466935e73251b18b17d51455b06ed65764 ("m68k: use generic code for
> ptrace requests") by Andreas).
>
> Anyway, I'd expect the generic code to issue a cache flush/invalidate somewhere
> around the road, else it would fail for many more platforms.

I'd assume the same, but I couldn't find where this is happening.

> So far I couldn't reproduce this (on 3.0 and 3.5-rc6) on 68040 (both ARAnyM
> and real hardware). Hence I'm more inclined to believe this is an issue in the
> Coldfire-specific code, cfr. the recent cache issues Greg discovered
> (http://www.mail-archive.com/linux-m68k@vger.kernel.org/msg04929.html).

I'll see if this patch also fixes the problem.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: M68k ColdFire ptrace/cache fix

[Greg Ungerer]

Hi Michael,

On 16/07/12 03:10, Michael Eager wrote:
> On 07/15/2012 04:54 AM, Geert Uytterhoeven wrote:
>> On Fri, Jul 13, 2012 at 10:18 PM, Michael Eager <eager@eagercon.com> wrote:
>>> On 07/13/2012 01:06 PM, Geert Uytterhoeven wrote:
>>>> On Fri, Jul 13, 2012 at 9:14 PM, Michael Eager <eager@eagercon.com> wrote:
>>>>> I've tracked down a problem in gdb/gdbserver to ptrace() not
>>>>> clearing the i/d cache after modifying memory.
>>>>>
>>>>> To reproduce:
>>>>>      m68k-gcc -g -o cf-gdb-test-no-io cf-gdb-test-no-io.c
>>>>>      scp cf-gdb-test-no-io <target>:/
>>>>>      on target:   gdbserver :1234 cf-gdb-test-no-io
>>>>>      m68k-gcc cf-gdb-test-no-io
>>>>>      (gdb) b 8
>>>>>      (gdb) b 10
>>>>>      (gdb) tar rem <target>:1234
>>>>>      (gdb) c
>>>>>      (gdb) c
>>>>>
>>>>> Program will hit first breakpoint, but not second breakpoint.
>>>>>
>>>>> It appears that the instruction at the last breakpoint location
>>>>> is in the icache and does not get flushed when the bp is written.
>>>>>
>>>>> After applying the attached patch, gdb/gdbserver behavior is correct.
>>>>
>>>> Thanks for your report and patch!
>>>
>>> I attached the test program, which I previously forgot.
>>>
>>>> Does this happen only in 2.6.29, or also in current kernels?
>>>> The first hunk of your patch no longer applies, as the affected code is
>>>> gone and those cases are now handled purely by the generic code.
>>>
>>> I'm working with a client's environment using 2.6.29, so I can't verify
>>> that the same failure occurs in recent kernels.  But I don't see anything
>>> in ptrace.c in the latest kernel which would clear the i/d caches when
>>> writing to memory.

It can't be a stock 2.6.29 kernel. There is no ColdFire code in
arch/m68k/ in 2.6.29. My best guess is that you are using a kernel
supplied by Freescale with MMU ColdFire support.


>> Yeah, even 2.6.29 just called the generic version from the m68k-specific code,
>> which moved a layer up in more recent kernels (commit
>> faa47b466935e73251b18b17d51455b06ed65764 ("m68k: use generic code for
>> ptrace requests") by Andreas).
>>
>> Anyway, I'd expect the generic code to issue a cache flush/invalidate somewhere
>> around the road, else it would fail for many more platforms.
>
> I'd assume the same, but I couldn't find where this is happening.
>
>> So far I couldn't reproduce this (on 3.0 and 3.5-rc6) on 68040 (both ARAnyM
>> and real hardware). Hence I'm more inclined to believe this is an issue in the
>> Coldfire-specific code, cfr. the recent cache issues Greg discovered
>> (http://www.mail-archive.com/linux-m68k@vger.kernel.org/msg04929.html).
>
> I'll see if this patch also fixes the problem.

I can't try this myself at the moment on 3.5-rc7 with the cache patch.
My gdb and gdbserver seem to be version mis-matched.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com