Kernel related (?) user space crash at ARM11 MPCore

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, Sep 21, 2009 at 11:07:51AM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 21, 2009 at 10:44:23AM +0100, Catalin Marinas wrote:
> > I would still call this I-D cache coherency issue since the two caches
> > have a different view of the RAM but I agree that the D-cache is the one
> > holding the data (with a slight chance for the I-cache not to be in sync
> > with main RAM, though we could treat it separately).
> > 
> > We can sort out the D-cache issue with your approach for cleaning it in
> > the copy_user_highpage() function, but, as I said, we affect the
> > standard CoW mechanism for data pages quite a lot.
> 
> Let me restate my approach more clearly:
> 
> 1. Remember that a VMA has been executable.
> 2. Only do the additional handing if the VMA has been executable.

Well, there's a problem with this approach.  Any binary which executes
with read-implies-exec (in other words, the majority of those around)
results in any region with read permission also getting exec permission.

So, mprotect(rw) actually ends up as mprotect(rwx), which means that
effectively _all_ VMAs have been executable.

This approach won't work as well as I'd hope, since this means every
COW fault ends up triggering the cache flush.

However, the same problem affects Catalin's approach too - with these
binaries, every VMA has VM_EXEC set, which means every VMA gets the
cache flushing treatment whenever flush_cache_range() is called.

This is a nasty problem to solve...