aboutsummaryrefslogtreecommitdiffstats
path: root/arch
diff options
context:
space:
mode:
authorDavid S. Miller <davem@sunset.davemloft.net>2006-08-28 00:33:03 -0700
committerDavid S. Miller <davem@sunset.davemloft.net>2006-08-29 21:23:31 -0700
commit47f2c3604f47579ac5c173f8b402dc6cd8e2e8fa (patch)
treee6801f2664730e13019dd0e23e71ac50c898ca88 /arch
parentdc709bd190c130b299ac19d596594256265c042a (diff)
downloadkernel_goldelico_gta04-47f2c3604f47579ac5c173f8b402dc6cd8e2e8fa.zip
kernel_goldelico_gta04-47f2c3604f47579ac5c173f8b402dc6cd8e2e8fa.tar.gz
kernel_goldelico_gta04-47f2c3604f47579ac5c173f8b402dc6cd8e2e8fa.tar.bz2
[SPARC64]: Fix X server hangs due to large pages.
This problem was introduced by changeset 14778d9072e53d2171f66ffd9657daff41acfaed Unlike the hugetlb code paths, the normal fault code is not setup to propagate PTE changes for large page sizes correctly like the ones we make for I/O mappings in io_remap_pfn_range(). It is absolutely necessary to update all sub-ptes of a largepage mapping on a fault. Adding special handling for this would add considerably complexity to tlb_batch_add(). So let's just side-step the issue and forcefully dirty any writable PTEs created by io_remap_pfn_range(). The only other real option would be to disable to large PTE code of io_remap_pfn_range() and we really don't want to do that. Much thanks to Mikael Pettersson for tracking down this problem and testing debug patches. Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'arch')
-rw-r--r--arch/sparc64/mm/generic.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/arch/sparc64/mm/generic.c b/arch/sparc64/mm/generic.c
index 8cb0620..af9d81d 100644
--- a/arch/sparc64/mm/generic.c
+++ b/arch/sparc64/mm/generic.c
@@ -69,6 +69,8 @@ static inline void io_remap_pte_range(struct mm_struct *mm, pte_t * pte,
} else
offset += PAGE_SIZE;
+ if (pte_write(entry))
+ entry = pte_mkdirty(entry);
do {
BUG_ON(!pte_none(*pte));
set_pte_at(mm, address, pte, entry);