Re: flush_kernel_dcache_page() not needed ?

[Franck Bui-Huu <vagabon.xyz@gmail.com>]

Atsushi Nemoto wrote:
> 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.

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

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.

		Franck