flush_kernel_dcache_page() not needed ?

Hi,

I noticed that there's currently (v2.6.23-rc4) no implementation of this function even for mips CPUs that have dcache aliasing.

Could anybody explain why ?

thanks, Franck

Ralf added this a while ago:

"arch/mips/mm/cache.c:void __flush_dcache_page(struct page *page)"

Ralf added this a while ago:

"arch/mips/mm/cache.c:void __flush_dcache_page(struct page *page)"

Quoted 3 lines · Markus Gothe

Ralf added this a while ago:

"arch/mips/mm/cache.c:void __flush_dcache_page(struct page *page)"

__flush_dcache_page is just the part of flush_dcache_page which does the real work.and has nothing to do with flush_kernel_dcache_page.

Ralf

Hi,

I noticed that there's currently (v2.6.23-rc4) no implementation of this function even for mips CPUs that have dcache aliasing.

Could anybody explain why ?

thanks, Franck

I noticed that there's currently (v2.6.23-rc4) no implementation of this function even for mips CPUs that have dcache aliasing.

Could anybody explain why ?

Quoted 4 lines · Franck Bui-Huu

I noticed that there's currently (v2.6.23-rc4) no implementation of this function even for mips CPUs that have dcache aliasing.

Could anybody explain why ?

Maybe because the API was not called by anybody until 2.6.23-rc1 :)

Now copy_strings() calls this and I'm wondering we should implement or not. It seems the kernel works fine for me without the API...

Do you have any problem due to luck of the API?

Quoted 2 lines

Now copy_strings() calls this and I'm wondering we should implement or not. It seems the kernel works fine for me without the API...

Do you use a cpu with dcache aliasing issue ?

Quoted 1 line

Do you have any problem due to luck of the API?

No, but looking at copy_strings(), I think we can have some trouble.

BTW, do you recall flush_anon_page() and fuse bug ? It seems the same here...

Indeed. But copy_strings() is not rare case (called on each execve), so there might be some constraints which make us free from the aliasing problem.

I'll look at it further, but any testcase are welcome.

Quoted 3 lines

Indeed. But copy_strings() is not rare case (called on each execve), so there might be some constraints which make us free from the aliasing problem.

The point is that this _generic_ function has been created so we need to understand if MIPS architecture needs to implement it or not, whatever its current usages. This was actually what I was trying to understand with this thread.

Whatever the constraints, they don't seem to be intended at all since flush_kernel_dcache_page() is called... So even if the current code is working fine, it seems very fragile _if_ MIPS needs to implement this cache helper.

Quoted 1 line

I'll look at it further, but any testcase are welcome.

Quoted 1 line · Franck Bui-Huu

Quoted 1 line

I'll look at it further, but any testcase are welcome.

I found the reason.

do_execve()
copy_strings()
flush_kernel_dcache_page()
search_binary_handler()
load_elf_binary()
setup_arg_pages()
shift_arg_pages()
move_page_tables()
flush_cache_range()

And MIPS flush_cache_range() blasts whole dcache! That's why empty flush_kernel_dcache_page() was enough for now.

Yeah, that what I think too and that's also why I was suggesting to test a plain 2.6.23-rc5 with the randomize_va_space=0. Please see my previous reply...

Could you give it a try ?

Quoted 5 lines · Franck Bui-Huu

Yeah, that what I think too and that's also why I was suggesting to test a plain 2.6.23-rc5 with the randomize_va_space=0. Please see my previous reply...

Could you give it a try ?

OK, I'll try it in a few days...

One thing you might want to try is:

	$ echo 0 > /proc/sys/kernel/randomize_va_space

and see if your system still works fine. This command should avoid a data cache flush when moving the stack around. See shift_arg_pages().

With this, maybe you could give this testcase a try:

	$ /bin/echo "`seq 10000`" > seq.txt

and see if seq.txt is correct. This command should pass to echo (not the bash builtin one) a long argument that should fill your dcache.

That said the execve syscall code is quite 'hairy' and it may not be suprising that after this syscall the dcache has been completly flushed and thus make the problem disappear.

Quoted 7 lines · Franck Bui-Huu

One thing you might want to try is:

	$ echo 0 > /proc/sys/kernel/randomize_va_space

and see if your system still works fine. This command should avoid a data cache flush when moving the stack around. See shift_arg_pages().

Quoted 7 lines

With this, maybe you could give this testcase a try:

	$ /bin/echo "`seq 10000`" > seq.txt

and see if seq.txt is correct. This command should pass to echo (not the bash builtin one) a long argument that should fill your dcache.

I tried this and everything worked fine with/without the flush_kernel_dcache_page() ;)

Quoted 3 lines

That said the execve syscall code is quite 'hairy' and it may not be suprising that after this syscall the dcache has been completly flushed and thus make the problem disappear.

Yes, there is an yet another path to "flush all dcache".

do_execve()
copy_strings()
flush_kernel_dcache_page()
search_binary_handler()

    load_elf_binary()
      flush_old_exec()
        exec_mmap()
          mmput()
            exit_mmap()
              flush_cache_mm()
                r4k_blast_dcache()

Anyway, the implementation of flush_kernel_dcache_page() is very simple so that we can believe it works correctly without any testcase. Too optimistic? :)

Yes, there is an yet another path to "flush all dcache".

do_execve()
copy_strings()
flush_kernel_dcache_page()
search_binary_handler()

    load_elf_binary()
      flush_old_exec()
        exec_mmap()
          mmput()
            exit_mmap()
              flush_cache_mm()
                r4k_blast_dcache()

BTW, flush_cache_mm() flushes (write back + invalidate ) the whole data cache unconditionnaly, but I'm wondering if it's really necessary for cpus which don't have any cache aliasing issues. After all they're equivalent to physical caches, aren't they ?

Quoted 4 lines · Franck Bui-Huu

BTW, flush_cache_mm() flushes (write back + invalidate ) the whole data cache unconditionnaly, but I'm wondering if it's really necessary for cpus which don't have any cache aliasing issues. After all they're equivalent to physical caches, aren't they ?

r4k_flush_cache_mm() returns immediately if !cpu_has_dc_aliases.