Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-26 Thread Catalin Marinas
On Wed, May 25, 2016 at 06:27:07PM +0100, Russell King - ARM Linux wrote: > On Wed, May 25, 2016 at 04:22:55PM +0100, Catalin Marinas wrote: > > That's when we realised that the CoW problem no longer exists for > > non-aliasing VIPT caches. However, the I-cache counterpart 6060e8df5178 > > has not

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-26 Thread Catalin Marinas
On Wed, May 25, 2016 at 06:27:07PM +0100, Russell King - ARM Linux wrote: > On Wed, May 25, 2016 at 04:22:55PM +0100, Catalin Marinas wrote: > > That's when we realised that the CoW problem no longer exists for > > non-aliasing VIPT caches. However, the I-cache counterpart 6060e8df5178 > > has not

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-26 Thread Catalin Marinas
On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote: > On 2016/5/25 18:50, Catalin Marinas wrote: > > What happens is that __sync_icache_dcache() only takes care of the first > > time a page is mapped in user space and flushes the caches, marking it > > as "clean"

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-26 Thread Catalin Marinas
On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote: > On 2016/5/25 18:50, Catalin Marinas wrote: > > What happens is that __sync_icache_dcache() only takes care of the first > > time a page is mapped in user space and flushes the caches, marking it > > as "clean"

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-26 Thread Russell King - ARM Linux
On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote: > Hi, > As my tracing, it is returned by "if (!page_mapping(page))", because "mmap" > are anonymous pages. I commented below code lines, it works well. > > /* no flushing needed for anonymous pages */ > if

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-26 Thread Russell King - ARM Linux
On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote: > Hi, > As my tracing, it is returned by "if (!page_mapping(page))", because "mmap" > are anonymous pages. I commented below code lines, it works well. > > /* no flushing needed for anonymous pages */ > if

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-26 Thread Leizhen (ThunderTown)
On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-26 Thread Leizhen (ThunderTown)
On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-25 Thread Leizhen (ThunderTown)
On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-25 Thread Leizhen (ThunderTown)
On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-25 Thread Russell King - ARM Linux
On Wed, May 25, 2016 at 04:22:55PM +0100, Catalin Marinas wrote: > That's when we realised that the CoW problem no longer exists for > non-aliasing VIPT caches. However, the I-cache counterpart 6060e8df5178 > has not been reverted. I think I mostly agree, except for reverting 6060e8df5178, which

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-25 Thread Russell King - ARM Linux
On Wed, May 25, 2016 at 04:22:55PM +0100, Catalin Marinas wrote: > That's when we realised that the CoW problem no longer exists for > non-aliasing VIPT caches. However, the I-cache counterpart 6060e8df5178 > has not been reverted. I think I mostly agree, except for reverting 6060e8df5178, which

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-25 Thread Catalin Marinas
On Tue, May 24, 2016 at 04:12:35PM +0100, Mark Rutland wrote: > On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > > On 2016/5/24 19:37, Mark Rutland wrote: > > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > > >> When we ran mprotect04(a test case in LTP)

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-25 Thread Catalin Marinas
On Tue, May 24, 2016 at 04:12:35PM +0100, Mark Rutland wrote: > On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > > On 2016/5/24 19:37, Mark Rutland wrote: > > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > > >> When we ran mprotect04(a test case in LTP)

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-25 Thread Catalin Marinas
On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: > On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: > > On 2016/5/24 21:02, Catalin Marinas wrote: > >> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > >>> On 2016/5/24 19:37, Mark Rutland wrote: >

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-25 Thread Catalin Marinas
On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: > On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: > > On 2016/5/24 21:02, Catalin Marinas wrote: > >> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > >>> On 2016/5/24 19:37, Mark Rutland wrote: >

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Leizhen (ThunderTown)
On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: > > > On 2016/5/24 21:02, Catalin Marinas wrote: >> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 19:37, Mark Rutland wrote: On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > When we

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Leizhen (ThunderTown)
On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: > > > On 2016/5/24 21:02, Catalin Marinas wrote: >> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 19:37, Mark Rutland wrote: On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > When we

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Mark Rutland
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > > > On 2016/5/24 19:37, Mark Rutland wrote: > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > >> When we ran mprotect04(a test case in LTP) infinitely, it would always > >> failed after a few seconds. The case

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Mark Rutland
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > > > On 2016/5/24 19:37, Mark Rutland wrote: > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > >> When we ran mprotect04(a test case in LTP) infinitely, it would always > >> failed after a few seconds. The case

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Catalin Marinas
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > On 2016/5/24 19:37, Mark Rutland wrote: > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > >> When we ran mprotect04(a test case in LTP) infinitely, it would always > >> failed after a few seconds. The case can

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Catalin Marinas
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > On 2016/5/24 19:37, Mark Rutland wrote: > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > >> When we ran mprotect04(a test case in LTP) infinitely, it would always > >> failed after a few seconds. The case can

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Leizhen (ThunderTown)
On 2016/5/24 19:37, Mark Rutland wrote: > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: >> When we ran mprotect04(a test case in LTP) infinitely, it would always >> failed after a few seconds. The case can be described briefly that: copy >> a empty function from code area into a new

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Leizhen (ThunderTown)
On 2016/5/24 19:37, Mark Rutland wrote: > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: >> When we ran mprotect04(a test case in LTP) infinitely, it would always >> failed after a few seconds. The case can be described briefly that: copy >> a empty function from code area into a new

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Mark Rutland
On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > When we ran mprotect04(a test case in LTP) infinitely, it would always > failed after a few seconds. The case can be described briefly that: copy > a empty function from code area into a new memory area(created by mmap), > then call

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Mark Rutland
On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > When we ran mprotect04(a test case in LTP) infinitely, it would always > failed after a few seconds. The case can be described briefly that: copy > a empty function from code area into a new memory area(created by mmap), > then call

[PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Zhen Lei
When we ran mprotect04(a test case in LTP) infinitely, it would always failed after a few seconds. The case can be described briefly that: copy a empty function from code area into a new memory area(created by mmap), then call mprotect to change the protection to PROT_EXEC. The syscall

[PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Zhen Lei
When we ran mprotect04(a test case in LTP) infinitely, it would always failed after a few seconds. The case can be described briefly that: copy a empty function from code area into a new memory area(created by mmap), then call mprotect to change the protection to PROT_EXEC. The syscall