> IIRC the SA1100 will access data in its cache without looking at the
> TLB/PTE entry.  Now unless the permissions from the TLB are saved
> with the cache line (Richard might be able to find out) this would
> allow users to write to kernel data that is in the d-cache! [1]

I've never heard anything to suggest this was the case before.  If true, 
it would indeed be horrible.  It certainly is the case that the SA110 
caches also hold the physical address of the cache line, so that the 
write-backs can take place without a further look up.  Of course, a simple 
kernel test should suffice:

	ldr	r0, [some_cacheable_kernel_address]
	ldrt	r0, [same_kernel_address]

which should trap on the second access.

Are you sure that you aren't confusing the mini-cache on the 1100 with the 
main Dcache?  That could well be different (and, of course, specific to 
the 1100 parts).  Either way, I've asked a colleague who was more 
intimately involved what the situation really is.  No answer yet...

> 
> However valid user addresses are know to be a bounded range (8k to
> maybe 0xc0000000 - or similar) so this can be checked quite cheaply.
> Allowing the kernel permissions to be used for the copy.

Yes, the fusuxxx routines already do this.

> 
> The PTE check is actually checking for the 'copy on write' case,
> not the 'page not present' case.  This may have something to do
> with the problems Jason? was having with COW on XSCALE.
> My guess is that the cpu wasn't faulting the write to cache! Just the
> writeback of the cacheline - which would be asynchonous! [2]

Nah! far more likely that the original author didn't know about ldrt!  
Otherwise, the absence of a comment explaining why they aren't used is 
unforgivable.

The SA can never abort on a cache write-back.  There's just no way for it 
to do that.  It can abort on a cache-line fetch, but only if the aborting 
word occurs before the required word is fetched.  After that, the core 
will have continued, and the cache line will just be discarded (so says 
the data sheet).

R.