On Thu, Sep 27, 2018 at 09:08:59AM +0200, Peter Zijlstra wrote: > On Thu, Sep 27, 2018 at 01:27:38PM +0800, Guo Ren wrote: > > On Tue, Sep 25, 2018 at 09:24:07AM +0200, Peter Zijlstra wrote: > > > On Mon, Sep 24, 2018 at 10:36:22PM +0800, Guo Ren wrote: > > > > diff --git a/arch/csky/abiv1/inc/abi/cacheflush.h b/arch/csky/abiv1/inc/abi/cacheflush.h > > > > new file mode 100644 > > > > index 0000000..f0de49c > > > > --- /dev/null > > > > +++ b/arch/csky/abiv1/inc/abi/cacheflush.h > > > > > +#define flush_cache_range(mm,start,end) cache_wbinv_range(start, end) > > > ^^^ should be vma > > Yes, I'll change it to: > > #define flush_cache_range(mm,start,end) cache_wbinv_all() > > > > I'll improve it later after test. > > That's not what I meant; I meant you need something like: > > #define flush_cache_range(vma, start, end) cache_wbinv_range(start, end) If you remove the tlb_start_vma in my tlb.h, I want to use cache_wbinv_all() is more safe. And I'll improve it in future. My cache_wbinv_range(start, end) won't care vma->mm's asid and they just use current asid in mmu reg. If current_mm != vma->mm, then flush_cache_range will be broken. Perhaps, I need improve flush_cache_range first ... > > The first argument is a vma, not an mm. Yes, vma! My fault :-P > > > Also, I'll be shortly removing this: > > > > > > https://lkml.kernel.org/r/20180913092812.071989585@xxxxxxxxxxxxx > > Ok, I'll follow the rules. > > > > > > diff --git a/arch/csky/abiv2/inc/abi/cacheflush.h b/arch/csky/abiv2/inc/abi/cacheflush.h > > > > new file mode 100644 > > > > index 0000000..756beb7 > > > > --- /dev/null > > > > +++ b/arch/csky/abiv2/inc/abi/cacheflush.h > > > > @@ -0,0 +1,40 @@ > > > > > +#define flush_cache_range(vma, start, end) do { } while (0) > > > ^^^ like here.. > > #define flush_cache_range(vma, start, end) \ > > do { \ > > if (vma->vm_flags & VM_EXEC) \ > > icache_inv_all(); \ > > } > > > > Hmm ? > > > > For v2, which IIUC is PIPT (as opposed to v1 which is VIPT), what you > had was correct. I'll improve icache_inv_all() with flush_range() in future. > > I was merely pointing out that the flush_cache_range() definition was > inconsitent between v1 and v2; v1 using @mm and v2 using @vma for the > first argument. Must be vma, you are right. And I know it's a vma in mind, but fault in code. Thx for your review. Best Regards Guo Ren