[PATCH] m68k/coldfire: flush cache when creating the signal stack frame

[PATCH] m68k/coldfire: flush cache when creating the signal stack frame

[Alexander Stein]

When the signal stack frame is created, it must be flushed in order to
make sure the cache fetches the correct data.
Without cache flush the icache might pick up old cached data from an older
signal stack frame if the signal is raised again very fast.
In case of copyback the data cache muist be pushed first, but is untested.

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
 arch/m68k/kernel/signal.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index 2a16df3..57fd286 100644
--- a/arch/m68k/kernel/signal.c
+++ b/arch/m68k/kernel/signal.c
@@ -50,6 +50,7 @@
 #include <asm/pgtable.h>
 #include <asm/traps.h>
 #include <asm/ucontext.h>
+#include <asm/cacheflush.h>
 
 #ifdef CONFIG_MMU
 
@@ -181,6 +182,13 @@ static inline void push_cache (unsigned long vaddr)
 		asm volatile ("movec %0,%%caar\n\t"
 			      "movec %1,%%cacr"
 			      : : "r" (vaddr + 4), "r" (temp));
+	} else {
+		/* CPU_IS_COLDFIRE */
+#if defined(CONFIG_CACHE_COPYBACK)
+		flush_cf_dcache(0, DCACHE_MAX_ADDR);
+#endif
+		/* Invalidate instruction cache for the pushed bytes */
+		clear_cf_icache(vaddr, vaddr + 8);
 	}
 }
 
-- 
1.8.1.5

Re: [PATCH] m68k/coldfire: flush cache when creating the signal stack frame

[Alexander Stein]

Any feedback on this?

On Wednesday 05 June 2013 13:42:39, Alexander Stein wrote:
> When the signal stack frame is created, it must be flushed in order to
> make sure the cache fetches the correct data.
> Without cache flush the icache might pick up old cached data from an older
> signal stack frame if the signal is raised again very fast.
> In case of copyback the data cache muist be pushed first, but is untested.
> 
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
>  arch/m68k/kernel/signal.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
> index 2a16df3..57fd286 100644
> --- a/arch/m68k/kernel/signal.c
> +++ b/arch/m68k/kernel/signal.c
> @@ -50,6 +50,7 @@
>  #include <asm/pgtable.h>
>  #include <asm/traps.h>
>  #include <asm/ucontext.h>
> +#include <asm/cacheflush.h>
>  
>  #ifdef CONFIG_MMU
>  
> @@ -181,6 +182,13 @@ static inline void push_cache (unsigned long vaddr)
>  		asm volatile ("movec %0,%%caar\n\t"
>  			      "movec %1,%%cacr"
>  			      : : "r" (vaddr + 4), "r" (temp));
> +	} else {
> +		/* CPU_IS_COLDFIRE */
> +#if defined(CONFIG_CACHE_COPYBACK)
> +		flush_cf_dcache(0, DCACHE_MAX_ADDR);
> +#endif
> +		/* Invalidate instruction cache for the pushed bytes */
> +		clear_cf_icache(vaddr, vaddr + 8);
>  	}
>  }
>  
> 
-- 
Dipl.-Inf. Alexander Stein

SYS TEC electronic GmbH
Am Windrad 2
08468 Heinsdorfergrund
Tel.: 03765 38600-1156
Fax: 03765 38600-4100
Email: alexander.stein@systec-electronic.com
Website: www.systec-electronic.com
 
Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Chemnitz, HRB 28082

Re: [PATCH] m68k/coldfire: flush cache when creating the signal stack frame

[Greg Ungerer]

Hi Alexander,

On 05/06/13 21:42, Alexander Stein wrote:
> When the signal stack frame is created, it must be flushed in order to
> make sure the cache fetches the correct data.
> Without cache flush the icache might pick up old cached data from an older
> signal stack frame if the signal is raised again very fast.
> In case of copyback the data cache muist be pushed first, but is untested.
> 
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>

Sorry for the delay.

I haven't been able to actually test it, I can't get the M5475 to
boot in copyback cache mode at the moment. I need to debug it and
figure out why it is broken.

For now I think the best is if I push it into for-next on the
m68knommu git tree.

(Aside it looks like the clear_cf_icache call here is a bit bogus.
It takes cache line number args, not virtual addresses - it works
here because clear_cf_cache invalidates the whole icache... :-(

Regards
Greg


> ---
>  arch/m68k/kernel/signal.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
> index 2a16df3..57fd286 100644
> --- a/arch/m68k/kernel/signal.c
> +++ b/arch/m68k/kernel/signal.c
> @@ -50,6 +50,7 @@
>  #include <asm/pgtable.h>
>  #include <asm/traps.h>
>  #include <asm/ucontext.h>
> +#include <asm/cacheflush.h>
>  
>  #ifdef CONFIG_MMU
>  
> @@ -181,6 +182,13 @@ static inline void push_cache (unsigned long vaddr)
>  		asm volatile ("movec %0,%%caar\n\t"
>  			      "movec %1,%%cacr"
>  			      : : "r" (vaddr + 4), "r" (temp));
> +	} else {
> +		/* CPU_IS_COLDFIRE */
> +#if defined(CONFIG_CACHE_COPYBACK)
> +		flush_cf_dcache(0, DCACHE_MAX_ADDR);
> +#endif
> +		/* Invalidate instruction cache for the pushed bytes */
> +		clear_cf_icache(vaddr, vaddr + 8);
>  	}
>  }
>  
> 

Re: [PATCH] m68k/coldfire: flush cache when creating the signal stack frame

[Alexander Stein]

Hello Greg,

On Tuesday 30 July 2013 16:41:43, Greg Ungerer wrote:
> Hi Alexander,
> 
> On 05/06/13 21:42, Alexander Stein wrote:
> > When the signal stack frame is created, it must be flushed in order to
> > make sure the cache fetches the correct data.
> > Without cache flush the icache might pick up old cached data from an older
> > signal stack frame if the signal is raised again very fast.
> > In case of copyback the data cache muist be pushed first, but is untested.
> > 
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> 
> Sorry for the delay.
> 
> I haven't been able to actually test it, I can't get the M5475 to
> boot in copyback cache mode at the moment. I need to debug it and
> figure out why it is broken.
> 
> For now I think the best is if I push it into for-next on the
> m68knommu git tree.
> 
> (Aside it looks like the clear_cf_icache call here is a bit bogus.
> It takes cache line number args, not virtual addresses - it works
> here because clear_cf_cache invalidates the whole icache... :-(

Yep, the problem is that IIRC coldfire can only invalidate the whole cache, or single cache lines where I think it is impossible to find out which one to invalidate.

Best regards,
Alexander