Kernel related (?) user space crash at ARM11 MPCore

Catalin Marinas catalin.marinas at arm.com
Mon Sep 21 18:34:53 EDT 2009


Jamie Lokier wrote:
> Catalin Marinas wrote:
>> A possible scenario (though more code analysis is needed to be entirely 
>> sure) with writing instructions and not calling sys_cacheflush():
>>
>> - application mmap's a file (shared mapping, otherwise the data written 
>> to private mappings is lost when unmapping)
>> - app writes some instructions to text pages. We don't get CoW because 
>> of the shared mapping but we don't get D-cache cleaning either
>> - app unmap's the page but the kernel keeps the physical page in its 
>> page cache. The flush_cache_page() on non-aliasing VIPT doesn't do 
>> anything on ARM
>> - app mmap's the page with PROT_READ|PROT_EXEC
>> - app executes from the page generating a prefetch abort. The kernel 
>> finds the page in its page cache and maps it into user space, calling 
>> update_mmu_cache(). However, the dirty bit isn't set (since the kernel 
>> hasn't touched the page) and the lazy D-cache flushing in 
>> update_mmu_cache isn't triggered, leaving the I-cache with old entries 
>> directly from RAM.
> 
> Why isn't the dirty bit set by the last step?

By dirty here I mean the PG_arch_1 bit set by flush_dcache_page() which 
won't happen at step 2.

> The dirty bit must be set by the writes in the second step, otherwise
> how does the kernel know not to discard those writes under memory
> pressure?

That's another dirty bit (I think PG_dirty) but it isn't taken into 
account by update_mmu_cache(). As I said, more in-depth code analysis 
here is needed to be entirely sure.

> Btw, regarding "non-aliasing", it's pretty clear that it does alias
> the I-cache ;-), 

We just refer to D-cache aliasing here.

> in much the same way as different addresses alias in
> the D-cache with an "aliasing" cache.  That may well be a clue as to
> clean, systematic and sane way of ensuring all the cache ops are in
> all the right places.

We should indeed favour correctness but there may be some corner cases 
which aren't used anyway, so we shouldn't penalise normal usage.

-- 
Catalin



More information about the linux-arm-kernel mailing list