[patch 1/1] uml: avoid fixing faults while atomic

From: blaisorblade
Date: Sat Jul 30 2005 - 14:26:01 EST

From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@xxxxxxxx>

Following i386, we should maybe refuse trying to fault in pages when we're
doing atomic operations, because to handle the fault we could need to take
already taken spinlocks.

Also, if we're doing an atomic operation (in the sense of in_atomic()) we're
surely in kernel mode and we're surely going to handle adequately the failed
fault, so it's safe to behave this way.

Currently, on UML SMP is rarely used, and we don't support PREEMPT, so this is
unlikely to create problems right now, but it might in the future.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@xxxxxxxx>

linux-2.6.git-paolo/arch/um/kernel/trap_kern.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)

diff -puN arch/um/kernel/trap_kern.c~uml-avoid-faults-while-atomic arch/um/kernel/trap_kern.c
--- linux-2.6.git/arch/um/kernel/trap_kern.c~uml-avoid-faults-while-atomic 2005-07-30 17:04:10.000000000 +0200
+++ linux-2.6.git-paolo/arch/um/kernel/trap_kern.c 2005-07-30 17:04:10.000000000 +0200
@@ -39,6 +39,10 @@ int handle_page_fault(unsigned long addr
int err = -EFAULT;

*code_out = SEGV_MAPERR;
+ if (in_atomic()) //If the fault was during atomic operation, don't take the fault.
+ goto out_nosemaphore;
vma = find_vma(mm, address);
@@ -52,7 +56,7 @@ int handle_page_fault(unsigned long addr
else if(expand_stack(vma, address))
goto out;

- good_area:
*code_out = SEGV_ACCERR;
if(is_write && !(vma->vm_flags & VM_WRITE))
goto out;
@@ -62,7 +66,7 @@ int handle_page_fault(unsigned long addr

page = address & PAGE_MASK;
do {
- survive:
switch (handle_mm_fault(mm, vma, address, is_write)){
@@ -88,8 +92,9 @@ int handle_page_fault(unsigned long addr
*pte = pte_mkyoung(*pte);
if(pte_write(*pte)) *pte = pte_mkdirty(*pte);
flush_tlb_page(vma, page);
- out:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/