[parisc-linux] flush_icache_range problem

[John Marvin]

Richard Hirst wrote:
> Added a flush of the data cache after copying a module from userland to
> kernel land.  I guess that without this the module code is still in the
> data cache and hasn't been flushed through to memory.  Maybe copy_from_user()
> should flush caches really (as it used to do).

No, copy_from_user should not be doing any cache flushing. EVERY other
call, except for this case, does not need, and would suffer from,
flushing the cache.

The problem here is that data is being brought in from user land to
be executed in the kernel. Since PARISC has separate I&D caches, the
data has to be pushed out from the data cache, and the instruction
cache has to be invalidated so that the instructions will be read
into the I cache.

sys_init_module() calls flush_icache_range() to solve this problem.  The
problem is that the current implementation is only flushing the icache,
where it should be flushing the dcache first (As does other
implementations on other architectures where it is necessary) .  Of
course, other parisc cache routines are using flush_icache_range assuming
it is only flushing the icache. This could be easily hacked, but I am
reluctant to spend any time applying more bandaids.

So, adding the dcache flush is an acceptable workaround for now, and if I
forget to remove it when I fix the cache management code, we will catch it
when we prepare for the upstream merge.

I am well aware that system performance sucks, due to the cache management
code flushing everything all the time, and I intend to fix it.  But,
stability is more important to me than performance right now.  I will work
on proper cache management once I stop finding easily reproducible system
crashes (e.g. simply doing a large cpio from nfs root to a scsi disk on an
A180 HPMC's the machine every time).  I didn't realize that
flush_icache_range was broken, since I thought that everything had been
reverted back to flushing everything and missed the difference.  This
looks like the only case where it matters though, since the other callers
of flush_icache_range are there for aout support.

John Marvin
jsm@fc.hp.com