aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/mm/fault-armv.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2009-12-04ARM: Reduce __flush_dcache_page() visibilityRussell King1-0/+2
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-12-01ARM: ZERO_PAGE: Avoid flush_dcache_page() for zero pageRussell King1-0/+7
The zero page is read-only, and has its cache state cleared during boot. No further maintanence for this page is required. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-10-12ARM: force dcache flush if dcache_dirty bit setNitin Gupta1-6/+3
On ARM, update_mmu_cache() does dcache flush for a page only if it has a kernel mapping (page_mapping(page) != NULL). The correct behavior would be to force the flush based on dcache_dirty bit only. One of the cases where present logic would be a problem is when a RAM based block device[1] is used as a swap disk. In this case, we would have in-memory data corruption as shown in steps below: do_swap_page() { - Allocate a new page (if not already in swap cache) - Issue read from swap disk - Block driver issues flush_dcache_page() - flush_dcache_page() simply sets PG_dcache_dirty bit and does not actually issue a flush since this page has no user space mapping yet. - Now, if swap disk is almost full, this newly read page is removed from swap cache and corrsponding swap slot is freed. - Map this page anonymously in user space. - update_mmu_cache() - Since this page does not have kernel mapping (its not in page/swap cache and is mapped anonymously), it does not issue dcache flush even if dcache_dirty bit is set by flush_dcache_page() above. <user now gets stale data since dcache was never flushed> } Same problem exists on mips too. [1] example: - brd (RAM based block device) - ramzswap (RAM based compressed swap device) Signed-off-by: Nitin Gupta <ngupta@vflare.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-01-28[ARM] 5366/1: fix shared memory coherency with VIVT L1 + L2 cachesNicolas Pitre1-1/+4
When there are multiple L1-aliasing userland mappings of the same physical page, we currently remap each of them uncached, to prevent VIVT cache aliasing issues. (E.g. writes to one of the mappings not being immediately visible via another mapping.) However, when we do this remapping, there could still be stale data in the L2 cache, and an uncached mapping might bypass L2 and go straight to RAM. This would cause reads from such mappings to see old data (until the dirty L2 line is eventually evicted.) This issue is solved by forcing a L2 cache flush whenever the shared page is made L1 uncacheable. Ideally, we would make L1 uncacheable and L2 cacheable as L2 is PIPT. But Feroceon does not support that combination, and the TEX=5 C=0 B=0 encoding for XSc3 doesn't appear to work in practice. Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-10-09Merge branch 'ptebits' into develRussell King1-5/+6
Conflicts: arch/arm/Kconfig
2008-10-01[ARM] Introduce new PTE memory type bitsRussell King1-5/+6
Provide L_PTE_MT_xxx definitions to describe the memory types that we use in Linux/ARM. These definitions are carefully picked such that: 1. their LSBs match what is required for pre-ARMv6 CPUs. 2. they all have a unique encoding, including after modification by build_mem_type_table() (the result being that some have more than one combination.) Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-05[ARM] sparse: fix several warningsRussell King1-0/+1
arch/arm/kernel/process.c:270:6: warning: symbol 'show_fpregs' was not declared. Should it be static? This function isn't used, so can be removed. arch/arm/kernel/setup.c:532:9: warning: symbol 'len' shadows an earlier one arch/arm/kernel/setup.c:524:6: originally declared here A function containing two 'len's. arch/arm/mm/fault-armv.c:188:13: warning: symbol 'check_writebuffer_bugs' was not declared. Should it be static? arch/arm/mm/mmap.c:122:5: warning: symbol 'valid_phys_addr_range' was not declared. Should it be static? arch/arm/mm/mmap.c:137:5: warning: symbol 'valid_mmap_phys_addr_range' was not declared. Should it be static? Missing includes. arch/arm/kernel/traps.c:71:77: warning: Using plain integer as NULL pointer arch/arm/mm/ioremap.c:355:46: error: incompatible types in comparison expression (different address spaces) Sillies. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-01[ARM] cachetype: move definitions to separate headerRussell King1-0/+1
Rather than pollute asm/cacheflush.h with the cache type definitions, move them to asm/cachetype.h, and include this new header where necessary. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-07-27[ARM] Fix shared mmap when more than two maps of the same file existRussell King1-3/+7
The shared mmap code works fine for the test case, which only checked for two shared maps of the same file. However, three shared maps result in one mapping remaining cached, resulting in stale data being visible via that mapping. Fix this. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-07-03[ARM] 5092/1: Fix the I-cache invalidation on ARMv6 and later CPUsCatalin Marinas1-0/+4
This patch adds the I-cache invalidation in update_mmu_cache if the corresponding vma is marked as executable. It also invalidates the I-cache if a thread migrates to a CPU it never ran on. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-16[ARM] 4191/1: Remove redundant __flush_dcache_page() function prototypeGeorge G. Davis1-2/+0
Commit 1c9d3df5e88ad7db23f5b22f4341c39722a904a4 added function prototype __flush_dcache_page() in include/asm-arm/cacheflush.h. So we can remove the prototype for same in arch/arm/mm/fault-armv.c since it is now redundant to have it there. Signed-off-by: George G. Davis <gdavis@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-12-13[ARM] Unuse another Linux PTE bitRussell King1-1/+1
L_PTE_ASID is not really required to be stored in every PTE, since we can identify it via the address passed to set_pte_at(). So, create set_pte_ext() which takes the address of the PTE to set, the Linux PTE value, and the additional CPU PTE bits which aren't encoded in the Linux PTE value. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-29[PATCH] mm: arm ready for split ptlockHugh Dickins1-1/+6
Prepare arm for the split page_table_lock: three issues. Signal handling's preserve and restore of iwmmxt context currently involves reading and writing that context to and from user space, while holding page_table_lock to secure the user page(s) against kswapd. If we split the lock, then the structure might span two pages, secured by to read into and write from a kernel stack buffer, copying that out and in without locking (the structure is 160 bytes in size, and here we're near the top of the kernel stack). Or would the overhead be noticeable? arm_syscall's cmpxchg emulation use pte_offset_map_lock, instead of pte_offset_map and mm-wide page_table_lock; and strictly, it should now also take mmap_sem before descending to pmd, to guard against another thread munmapping, and the page table pulled out beneath this thread. Updated two comments in fault-armv.c. adjust_pte is interesting, since its modification of a pte in one part of the mm depends on the lock held when calling update_mmu_cache for a pte in some other part of that mm. This can't be done with a split page_table_lock (and we've already taken the lowest lock in the hierarchy here): so we'll have to disable split on arm, unless CONFIG_CPU_CACHE_VIPT to ensures adjust_pte never used. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-20[PATCH] ARM: Fix delayed dcache flush for ARMv6 non-aliasing cachesRussell King1-20/+11
flush_dcache_page() did nothing for these caches, but since they suffer from I/D cache coherency issues, we need to ensure that data is written back to RAM. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+223
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!