The problem
http://www.geocrawler.com/archives/3/343/2000/8/0/4140605/
which is on Alan's list to be looked at for 2.2 remains in
2.4.0.
Here is a patch for 2.4.0
diff -u traps.c-2.4.0-test7 traps.c
--- traps.c-2.4.0-test7 Sat Aug 5 00:15:38 2000
+++ traps.c Thu Sep 21 12:47:37 2000
@@ -535,9 +535,21 @@
goto clear_TF;
}
- /* If this is a kernel mode trap, we need to reset db7 to allow us to continue sanely */
- if ((regs->xcs & 3) == 0)
- goto clear_dr7;
+
+ /* If this is a kernel mode trap, we ignore it. Since the debug
+ * exception is a trap the instruction has completed, and we can just
+ * resume at the next instruction.
+ * If we were to clear the debug register, then we would need to restore
+ * it in every return to user level (or miss user level watchpoints).
+ * If we just leave it on here we may take a number of traps in the kernel,
+ * but only for a process which has watchpoints enabled, and that can
+ * reasonably pay since it is a rare occurrence.
+ * It would be good to be able to signal the process, since completely
+ * ignoring the trap means that watchpointed data can be silently overwritten
+ * by a system call, however that seems hard.
+ */
+ if ((regs->xcs & 3) == 0)
+ return;
/* Ok, finally something we can handle */
tsk->thread.trap_no = 1;
%
-- Jim
James Cownie <jcownie@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:24 EST