arm_syscall cacheflush breakage on VIPT platforms
From: Russell King - ARM Linux <hidden>
Date: 2009-09-28 09:59:45
On Mon, Sep 28, 2009 at 12:54:29PM +0300, Imre Deak wrote:
On Mon, Sep 28, 2009 at 11:41:40AM +0200, ext Russell King - ARM Linux wrote:quoted
On Mon, Sep 28, 2009 at 12:29:19PM +0300, Imre Deak wrote:quoted
Hi, the following test app will cause an unhandled kernel paging request on VIPT platforms. The triggering condition is the mmap_sem held by thread_func while the main thread performs cache flushing. Since the likelihood of this to trigger is relatively low, a patch will follow that makes similar bugs more visible.The problem is that, unlike previous cache architectures, if a page is not present we now get a data abort during cache maintainence. That means the cache maintainence instructions used for this call need to be marked with user fixups, so that the kernel knows how to handle such an abort. It is not caused by the holding of mmap_sem.This particular bug is caused by holding of mmap_sem, without any fixup being defined.
No it is not. The problem has nothing to do with holding of mmap_sem AT ALL. In fact, do_cache_op needs to hold mmap_sem itself, to prevent the VMA going away beneath it. That's not going to stop it generating faults, and it's not going to stop it oopsing. The problem is that we don't have any fixup in place for this situation. There is nothing wrong in the page fault handler.