linux-dev/arch/um/kernel/skas/process_kern.c, branch master

[PATCH] uml: remove unneeded file

2006-09-29T16:18:04Z

Remove arch/um/kernel/skas/process_kern.c again. The stack alignment change which resulted in this file being here is safely in arch/um/kernel/process.c. Signed-off-by: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] uml: file renaming

2006-09-27T15:26:16Z

Move some foo_kern.c files to foo.c now that the old foo.c files are out of the way. Also cleaned up some whitespace and an emacs formatting comment. Signed-off-by: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] uml: thread creation tidying

2006-09-27T15:26:16Z

fork on UML has always somewhat subtle. The underlying cause has been the need to initialize a stack for the new process. The only portable way to initialize a new stack is to set it as the alternate signal stack and take a signal. The signal handler does whatever initialization is needed and jumps back to the original stack, where the fork processing is finished. The basic context switching mechanism is a jmp_buf for each process. You switch to a new process by longjmping to its jmp_buf. Now that UML has its own implementation of setjmp and longjmp, and I can poke around inside a jmp_buf without fear that libc will change the structure, a much simpler mechanism is possible. The jmpbuf can simply be initialized by hand. This eliminates - the need to set up and remove the alternate signal stack sending and handling a signal the signal blocking needed around the stack switching, since there is no stack switching setting up the jmp_buf needed to jump back to the original stack after the new one is set up In addition, since jmp_buf is now defined by UML, and not by libc, it can be embedded in the thread struct. This makes it unnecessary to have it exist on the stack, where it used to be. It also simplifies interfaces, since the switch jmp_buf used to be a void * inside the thread struct, and functions which took it as an argument needed to define a jmp_buf variable and assign it from the void *. Signed-off-by: Jeff Dike Cc: Paolo 'Blaisorblade' Giarrusso Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] uml: signal initialization cleanup

2006-07-10T20:24:23Z

It turns out that init_new_thread_signals is always called with altstack == 1, so we can eliminate the parameter. Signed-off-by: Jeff Dike Cc: Paolo 'Blaisorblade' Giarrusso Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] uml: add arch_switch_to for newly forked thread

2006-03-31T20:18:52Z

Newly forked threads have no arch_switch_to_skas() called before their first run, because when schedule() switches to them they're resumed in the body of thread_wait() inside fork_handler() rather than in switch_threads() in switch_to_skas(). Compensate this missing call. Signed-off-by: Paolo 'Blaisorblade' Giarrusso Acked-by: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] uml: implement {get,set}_thread_area for i386

2006-03-31T20:18:52Z

Implement sys_[gs]et_thread_area and the corresponding ptrace operations for UML. This is the main chunk, additional parts follow. This implementation is now well tested and has run reliably for some time, and we've understood all the previously existing problems. Their implementation saves the new GDT content and then forwards the call to the host when appropriate, i.e. immediately when the target process is running or on context switch otherwise (i.e. on fork and on ptrace() calls). In SKAS mode, we must switch registers on each context switch (because SKAS does not switches tls_array together with current->mm). Also, added get_cpu() locking; this has been done for SKAS mode, since TT does not need it (it does not use smp_processor_id()). Signed-off-by: Paolo 'Blaisorblade' Giarrusso Acked-by: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] uml: clean arch_switch usage

2006-03-31T20:18:52Z

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 Acked-by: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] uml: move libc-dependent skas process handling

2006-01-19T03:20:19Z

The serial UML OS-abstraction layer patch (um/kernel/skas dir). This moves all systemcalls from skas/process.c file under os-Linux dir and join skas/process.c and skas/process_kern.c files. Signed-off-by: Gennady Sharapov Signed-off-by: Jeff Dike Cc: Paolo 'Blaisorblade' Giarrusso Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] uml: move libc-dependent time code

2006-01-19T03:20:19Z

The serial UML OS-abstraction layer patch (um/kernel dir). This moves all systemcalls from time.c file under os-Linux dir and joins time.c and tine_kernel.c files Signed-off-by: Gennady Sharapov Signed-off-by: Jeff Dike Cc: Paolo 'Blaisorblade' Giarrusso Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] uml: move LDT creation

2006-01-19T03:20:18Z

s390 doesn't have a LDT. So MM_COPY_SEGMENTS will not be supported on s390. The only user of MM_COPY_SEGMENTS is new_mm(), but that's no longer useful, as arch/sys-i386/ldt.c defines init_new_ldt(), which is called immediately after new_mm(). So we should copy host's LDT in init_new_ldt(), if /proc/mm is available, to have this subarch specific call in subarch code. Signed-off-by: Bodo Stroesser Signed-off-by: Jeff Dike Cc: Paolo 'Blaisorblade' Giarrusso Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds