path: root/arch/um/kernel/tt/process_kern.c
diff options
authorPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>2006-03-31 02:30:21 -0800
committerLinus Torvalds <torvalds@g5.osdl.org>2006-03-31 12:18:52 -0800
commit972410b0232e97609fcefc8e408fe3037fcd607b (patch)
tree2de18ed5d823dc7e24c0171f720f6354a9cd57e4 /arch/um/kernel/tt/process_kern.c
parent[PATCH] uml: split ldt.h in arch-independent and arch-dependant code (diff)
[PATCH] uml: clean arch_switch usage
Call arch_switch also in switch_to_skas, even if it's, for now, a no-op for that case (and mark this in the comment); this will change soon. Also, arch_switch for TT mode is actually useless when the PT proxy (a complicate debugging instrumentation for TT mode) is not enabled. In fact, it only calls update_debugregs, which checks debugregs_seq against seq (to check if the registers are up-to-date - seq here means a "version number" of the registers). If the ptrace proxy is not enabled, debugregs_seq always stays 0 and update_debugregs will be a no-op. So, optimize this out (the compiler can't do it). Also, I've been disappointed by the fact that it would make a lot of sense if, after calling a successful update_debugregs(current->thread.arch.debugregs_seq), current->thread.arch.debugregs_seq were updated with the new debugregs_seq. But this is not done. Is this a bug or a feature? For all purposes, it seems a bug (otherwise the whole mechanism does not make sense, which is also a possibility to check), which causes some performance only problems (not correctness), since we write_debugregs when not needed. Also, as suggested by Jeff, remove a redundant enabling of SIGVTALRM, comprised in the subsequent local_irq_enable(). I'm just a bit dubious if ordering matters there... Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Acked-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'arch/um/kernel/tt/process_kern.c')
1 files changed, 8 insertions, 2 deletions
diff --git a/arch/um/kernel/tt/process_kern.c b/arch/um/kernel/tt/process_kern.c
index 295c1ac817b3..a9c1443fc548 100644
--- a/arch/um/kernel/tt/process_kern.c
+++ b/arch/um/kernel/tt/process_kern.c
@@ -51,6 +51,13 @@ void switch_to_tt(void *prev, void *next)
c = 0;
+ /* Notice that here we "up" the semaphore on which "to" is waiting, and
+ * below (the read) we wait on this semaphore (which is implemented by
+ * switch_pipe) and go sleeping. Thus, after that, we have resumed in
+ * "to", and can't use any more the value of "from" (which is outdated),
+ * nor the value in "to" (since it was the task which stole us the CPU,
+ * which we don't care about). */
err = os_write_file(to->thread.mode.tt.switch_pipe[1], &c, sizeof(c));
if(err != sizeof(c))
panic("write of switch_pipe failed, err = %d", -err);
@@ -77,7 +84,7 @@ void switch_to_tt(void *prev, void *next)
change_sig(SIGALRM, alrm);
change_sig(SIGPROF, prof);
- arch_switch();
+ arch_switch_to_tt(prev_sched, current);
@@ -141,7 +148,6 @@ static void new_thread_handler(int sig)
set_cmdline("(kernel thread)");
change_sig(SIGUSR1, 1);
- change_sig(SIGVTALRM, 1);
change_sig(SIGPROF, 1);
if(!run_kernel_thread(fn, arg, &current->thread.exec_buf))