2.4.19-pre8 vm86 smp locking fix
PATCH 1/1 2.4.19-pre8 vm86 smp locking fix
arch/i386/kernel/vm86.c performs page table operations without obtaining any locks. This patch obtains page_table_lock around the the table walk and modification.
-ben
Signature · 41 lines
"You will be reincarnated as a toad; and you will be much happier."
diff -urN v2.4.19-pre8/arch/i386/kernel/vm86.c work/arch/i386/kernel/vm86.c
--- v2.4.19-pre8/arch/i386/kernel/vm86.c Thu Mar 7 16:39:56 2002
+++ work/arch/i386/kernel/vm86.c Thu May 23 16:21:38 2002
@@ -97,21 +97,22 @@
pte_t *pte;
int i;
+ spin_lock(&tsk->mm->page_table_lock);
pgd = pgd_offset(tsk->mm, 0xA0000);
if (pgd_none(*pgd))
- return;
+ goto out;
if (pgd_bad(*pgd)) {
pgd_ERROR(*pgd);
pgd_clear(pgd);
- return;
+ goto out;
}
pmd = pmd_offset(pgd, 0xA0000);
if (pmd_none(*pmd))
- return;
+ goto out;
if (pmd_bad(*pmd)) {
pmd_ERROR(*pmd);
pmd_clear(pmd);
- return;
+ goto out;
}
pte = pte_offset(pmd, 0xA0000);
for (i = 0; i < 32; i++) {
@@ -119,6 +120,8 @@
set_pte(pte, pte_wrprotect(*pte));
pte++;
}
+out:
+ spin_unlock(&tsk->mm->page_table_lock);
flush_tlb();
}Quoted 4 lines · Benjamin LaHaise
arch/i386/kernel/vm86.cperforms page table operations without obtaining any locks. This patch obtainspage_table_lockaround the the table walk and modification.
This patch can also be applied against 2.4.19-pre8-ac5. The patch command does report:
patching file arch/i386/kernel/vm86.c
Hunk #1 succeeded at 124 (offset 27 lines).
Since this missing lock is completely unrelated to the other bugfixes in vm86 I don't expect any bad interactions.
The pagetable access in arch/i386/kernel/vm86.c is related to another access in arch/i386/mm/fault.c. Did anybody verify that the other file does correct locking?
Signature · 2 lines
Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:[email protected]
Quoted 3 lines · Kasper Dupont
The pagetable access in
arch/i386/kernel/vm86.cis related to another access inarch/i386/mm/fault.c. Did anybody verify that the other file does correct locking?
That should be safe: the vmalloc pgds can only be filled from the main kernel page table. They never change afterwards, so even if two CPUs entered that code at the same time it would be okay.
-ben
Signature · 1 line
"You will be reincarnated as a toad; and you will be much happier."