* strange exit paths for do_sparc64_fault?
@ 2004-03-10 18:27 Ed L Cashin
2004-03-10 22:01 ` David S. Miller
0 siblings, 1 reply; 2+ messages in thread
From: Ed L Cashin @ 2004-03-10 18:27 UTC (permalink / raw)
To: sparclinux
Hi. In my patch to 2.6.0-test11 I have added a new semaphore "S".
The mmap_sem sometimes nests within S if a process is of a certain
kind (that has non-NULL current->macc_info). I've included a patch
below to help show what I'm talking about.
I'm observing a situation where in do_sparc64_fault, this semaphore is
taken but never released. I've matched every up_read(&mm->mmap_sem)
with a release of my semaphore, though.
Is there a situation where the mmap_sem is taken on entering
do_sparc64_fault but released outside of do_sparc64_fault? That would
explain what I'm seeing. I should mention that I only see this when
there's significant contention for memory, i.e., pgsteal is
increasing.
--- /tmp/2.6.0-test11.orig/arch/sparc64/mm/fault.c Wed Mar 10 13:04:08 2004
+++ macc-sparc64/arch/sparc64/mm/fault.c Wed Mar 10 12:59:07 2004
@@ -18,6 +18,8 @@
#include <linux/smp_lock.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/macc.h>
+#include <linux/dbg.h>
#include <asm/page.h>
#include <asm/pgtable.h>
@@ -345,6 +358,8 @@ asmlinkage void do_sparc64_fault(struct
address &= 0xffffffff;
}
+ /* to avoid deadlock, get the sync mutex first if we're in a macc family */
+ get_macc_sync(current->pid, current->macc_info);
down_read(&mm->mmap_sem);
vma = find_vma(mm, address);
if (!vma)
@@ -432,6 +447,7 @@ good_area:
}
up_read(&mm->mmap_sem);
+ put_macc_sync(current->pid, current->macc_info);
goto fault_done;
/*
@@ -441,6 +457,7 @@ good_area:
bad_area:
insn = get_fault_insn(regs, insn);
up_read(&mm->mmap_sem);
+ put_macc_sync(current->pid, current->macc_info);
handle_kernel_fault:
do_kernel_fault(regs, si_code, fault_code, insn, address);
@@ -454,6 +471,7 @@ handle_kernel_fault:
out_of_memory:
insn = get_fault_insn(regs, insn);
up_read(&mm->mmap_sem);
+ put_macc_sync(current->pid, current->macc_info);
printk("VM: killing process %s\n", current->comm);
if (!(regs->tstate & TSTATE_PRIV))
do_exit(SIGKILL);
@@ -466,6 +484,7 @@ intr_or_no_mm:
do_sigbus:
insn = get_fault_insn(regs, insn);
up_read(&mm->mmap_sem);
+ put_macc_sync(current->pid, current->macc_info);
/*
* Send a sigbus, regardless of whether we were in kernel
--
--Ed L Cashin | PGP public key:
ecashin@uga.edu | http://noserose.net/e/pgp/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: strange exit paths for do_sparc64_fault?
2004-03-10 18:27 strange exit paths for do_sparc64_fault? Ed L Cashin
@ 2004-03-10 22:01 ` David S. Miller
0 siblings, 0 replies; 2+ messages in thread
From: David S. Miller @ 2004-03-10 22:01 UTC (permalink / raw)
To: sparclinux
On Wed, 10 Mar 2004 13:27:49 -0500
Ed L Cashin <ecashin@uga.edu> wrote:
> Is there a situation where the mmap_sem is taken on entering
> do_sparc64_fault but released outside of do_sparc64_fault?
Yes, if the process dies due to a fatal fault and thus invokes
do_exit() to kill the process, it will never return back into
do_sparc64_fault() if that occurs.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-03-10 22:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-10 18:27 strange exit paths for do_sparc64_fault? Ed L Cashin
2004-03-10 22:01 ` David S. Miller
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.