* Re: M68k ColdFire ptrace/cache fix [not found] ` <CAMuHMdUgZBgKSZK1YJnvqvcF1M82Q6mHL41K-6hdvhM69JCB+w@mail.gmail.com> @ 2012-07-13 20:18 ` Michael Eager 2012-07-15 11:54 ` Geert Uytterhoeven 0 siblings, 1 reply; 4+ messages in thread From: Michael Eager @ 2012-07-13 20:18 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: linux-m68k [-- 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 */ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: M68k ColdFire ptrace/cache fix 2012-07-13 20:18 ` M68k ColdFire ptrace/cache fix Michael Eager @ 2012-07-15 11:54 ` Geert Uytterhoeven 2012-07-15 17:10 ` Michael Eager 0 siblings, 1 reply; 4+ messages in thread From: Geert Uytterhoeven @ 2012-07-15 11:54 UTC (permalink / raw) To: Michael Eager; +Cc: linux-m68k, Andreas Schwab, Greg Ungerer 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: M68k ColdFire ptrace/cache fix 2012-07-15 11:54 ` Geert Uytterhoeven @ 2012-07-15 17:10 ` Michael Eager 2012-07-16 6:02 ` Greg Ungerer 0 siblings, 1 reply; 4+ messages in thread From: Michael Eager @ 2012-07-15 17:10 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: linux-m68k, Andreas Schwab, Greg Ungerer 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: M68k ColdFire ptrace/cache fix 2012-07-15 17:10 ` Michael Eager @ 2012-07-16 6:02 ` Greg Ungerer 0 siblings, 0 replies; 4+ messages in thread From: Greg Ungerer @ 2012-07-16 6:02 UTC (permalink / raw) To: Michael Eager Cc: Geert Uytterhoeven, linux-m68k, Andreas Schwab, 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-07-16 6:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <500073A8.5090700@eagercon.com>
[not found] ` <CAMuHMdUgZBgKSZK1YJnvqvcF1M82Q6mHL41K-6hdvhM69JCB+w@mail.gmail.com>
2012-07-13 20:18 ` M68k ColdFire ptrace/cache fix Michael Eager
2012-07-15 11:54 ` Geert Uytterhoeven
2012-07-15 17:10 ` Michael Eager
2012-07-16 6:02 ` Greg Ungerer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.