An error occurred fetching the project authors.
- 24 Sep, 2002 1 commit
-
-
Ingo Molnar authored
This fixes the emacs bug reported by Andries. It should probably also fix other, terminal handling related weirdnesses introduced by the new PID handling code in 2.5.38. The bug was in the session_of_pgrp() function, if no proper session is found in the process group then we must take the session ID from the process that has pgrp PID (which does not necesserily have to be part of the pgrp). The fallback code is only triggered when no process in the process group has a valid session - besides being faster, this also matches the old implementation. [ hey, who needs a POSIX conformance testsuite when we have emacs! ;) ]
-
- 23 Sep, 2002 1 commit
-
-
Ingo Molnar authored
This does the following things: - removes the ->thread_group list and uses a new PIDTYPE_TGID pid class to handle thread groups. This cleans up lots of code in signal.c and elsewhere. - fixes sys_execve() if a non-leader thread calls it. (2.5.38 crashed in this case.) - renames list_for_each_noprefetch to __list_for_each. - cleans up delayed-leader parent notification. - introduces link_pid() to optimize PIDTYPE_TGID installation in the thread-group case. I've tested the patch with a number of threaded and non-threaded workloads, and it works just fine. Compiles & boots on UP and SMP x86. The session/pgrp bugs reported to lkml are probably still open, they are the next on my todo - now that we have a clean pidhash architecture they should be easier to fix.
-
- 19 Sep, 2002 2 commits
-
-
Linus Torvalds authored
it might be actively running on another CPU, so we still need to do the synchronous wait.
-
Ingo Molnar authored
This is the latest version of the generic pidhash patch. The biggest change is the removal of separately allocated pid structures: they are now part of the task structure and the first task that uses a PID will provide the pid structure. Task refcounting is used to avoid the freeing of the task structure before every member of a process group or session has exited. This approach has a number of advantages besides the performance gains. Besides simplifying the whole hashing code significantly, attach_pid() is now fundamentally atomic and can be called during create_process() without worrying about task-list side-effects. It does not have to re-search the pidhash to find out about raced PID-adding either, and attach_pid() cannot fail due to OOM. detach_pid() can do a simple put_task_struct() instead of the kmem_cache_free(). The only minimal downside is the potential pending task structures after session leaders or group leaders have exited - but the number of orphan sessions and process groups is usually very low - and even if it's higher, this can be regarded as a slow execution of the final deallocation of the session leader, not some additional burden.
-
- 18 Sep, 2002 1 commit
-
-
Daniel Jacobowitz authored
This patch consolidates zap_thread into reparent_thread, and fixes __will_become_orphaned_pgrp to check p->real_parent instead of p->parent.
-
- 15 Sep, 2002 7 commits
-
-
David Gibson authored
Linus, please apply. This defines wait_task_inactive() to be a no-op on UP machines, and removes the #ifdef CONFIG_SMP which surrounds current calls. This also fixes compile on UP which was broken by the addition of a call to wait_task_inactive in fs/exec.c which was not protected by an #ifdef.
-
Ingo Molnar authored
This implements one of the last missing POSIX threading details - exec() semantics. Previous kernels had code that tried to handle it, but that code had a number of disadvantages: - it only worked if the exec()-ing thread was the thread group leader, creating an assymetry. This does not work if the thread group leader has exited already. - it was racy: it sent a SIGKILL to every thread in the group but did not wait for them to actually process the SIGKILL. It did a yield() but that is not enough. All 'other' threads have to finish processing before we can continue with the exec(). This adds the same logic, but extended with the following enhancements: - works from non-leader threads just as much as the thread group leader. - waits for all other threads to exit before continuing with the exec(). - reuses the PID of the group. It would perhaps be a more generic approach to add a new syscall, sys_ungroup() - which would do largely what de_thread() does in this patch. But it's not really needed now - posix_spawn() is currently implemented via starting a non-CLONE_THREAD helper thread that does a sys_exec(). There's no API currently that needs a direct exec() from a thread - but it could be created (such as pthread_exec_np()). It would have the advantage of not having to go through a helper thread, but the difference is minimal.
-
Ingo Molnar authored
This fixes one more exit-time resource accounting issue - and it's also a speedup and a thread-tree (to-be thread-aware pstree) visual improvement. In the current code we reparent detached threads to the init thread. This worked but was not very nice in ps output: threads showed up as being related to init. There was also a resource-accounting issue, upon exit they update their parent's (ie. init's) rusage fields - effectively losing these statistics. Eg. 'time' under-reports CPU usage if the threaded app is Ctrl-C-ed prematurely. The solution is to reparent threads to the group leader - this is now very easy since we have p->group_leader cached and it's also valid all the time. It's also somewhat faster for applications that use CLONE_THREAD but do not use the CLONE_DETACHED feature.
-
Ingo Molnar authored
This fixes a number of bugs that broke ptrace: - wait4 must not inhibit TASK_STOPPED processes even for thread group leaders. - do_notify_parent() should not delay the notification of parents if the thread in question is ptraced. strace now works as expected for CLONE_THREAD applications as well.
-
Ingo Molnar authored
This optimizes sys_exit_group() to only take the siglock if it's a true thread group. Boots & works fine.
-
Ingo Molnar authored
This fixes three resource accounting related bugs introduced by detached threads: - the 'child CPU usage' fields were updated in wait4 until now - this was slightly buggy for a number of reasons, eg. if the exit_code writout faults then it's possible to trigger this code multiple times. - those threads that do not go through wait4 were not properly accounted. - sched_exit() was incorrectly assuming that current == parent. In the detached case p->parent is the real parent. with this patch applied things like 'time' work again for new-style threaded apps.
-
Ingo Molnar authored
the attached patch (against BK-curr) fixes a sys_wait4() bug noticed by Ulrich Drepper. The kernel would not block properly if there are eligible children delayed due to the new delayed thread-group-leader logic. The solution is to introduce a new type of 'eligible child' type - and skip over delayed children but set the wait4 flag nevertheless. The libpthreads testcase that failed due to it now it works fine.
-
- 14 Sep, 2002 1 commit
-
-
Ingo Molnar authored
I fixed up the 'remove thread group inferiors from the tasklist' patch. I think i managed to find a reasonably good construct to iterate over all threads: do_each_thread(g, p) { ... } while_each_thread(g, p); the only caveat with this is that the construct suggests a single-loop - while it's two loops internally - and 'break' will not work. I added a comment to sched.h that warns about this, but perhaps it would help more to have naming that suggests two loops: for_each_process_do_each_thread(g, p) { ... } while_each_thread(g, p); but this looks a bit too long. I dont know. We might as well use it all unrolled and no helper macros - although with the above construct it's pretty straightforward to iterate over all threads in the system.
-
- 13 Sep, 2002 2 commits
-
-
Ingo Molnar authored
This implements the 'keep the initial thread around until every thread in the group exits' concept in a different, less intrusive way, along your suggestions. There is no exit_done completion handling anymore, freeing of the task is still done by wait4(). This has the following side-effect: detached threads/processes can only be started within a thread group, not in a standalone way. (This also fixes the bugs introduced by the ->exit_done code, which made it possible for a zombie task to be reactivated.) I've introduced the p->group_leader pointer, which can/will be used for other purposes in the future as well - since from now on the thread group leader is always existent. Right now it's used to notify the parent of the thread group leader from the last non-leader thread that exits [if the thread group leader is a zombie already].
-
Ingo Molnar authored
I distilled the attached fix-patch from Daniel's bigger patch - it includes all fixes for all currently known ptrace related breakages, which include things like bad behavior (crash) if the tracer process dies unexpectedly.
-
- 12 Sep, 2002 1 commit
-
-
Daniel Jacobowitz authored
Linus spotted one cut-n-pasto ('tracing' argument) but didn't see the other: we were walking the ptrace_children list by the sibling field. So we got garbage for your task_structs when this happened. If the list wasn't empty, it would crash. Strace detaches from all tasks when it receives a Control-C so only with enough threads and SMP would this be easily seen.
-
- 11 Sep, 2002 2 commits
-
-
Ingo Molnar authored
This is another step to have better threading support under Linux, it implements the sys_exit_group() system call. It's a straightforward extension of the generic 'thread group' concept, which extension also comes handy to solve a number of problems when implementing POSIX threads. POSIX exit() [the C library function] has the following semantics: all thread have to exit and the waiting parent has to get the exit code that was specified for the exit() function. It also has to be ensured that every thread has truly finished its work by the time the parent gets the notification. The exit code has to be propagated properly to the parent thread even if not the thread group leader calls the exit() function. Normal single-thread exit is done via the pthread_exit() function, which calls sys_exit(). Previous incarnations of Linux POSIX threads implementations chose the following solution: send a 'thread management' signal to the thread group leader via tkill(), which thread goes around and kills every thread in the group (except itself), then calls sys_exit() with the proper exit code. Both old libpthreads and NGPT use this solution. This works to a certain degree, unless a userspace threading library uses the initial thread for normal thread work [like the new libpthreads], which 'work' can cause the initial thread to exit prematurely. At this point the threading library has to catch the group leader in pthread_exit() and has to keep the management thread 'hanging around' artificially, waiting for the management signal. Besides being slightly confusing to users ('why is this thread still around?') even this variant is unrobust: if the initial thread is killed by the kernel (SIGSEGV or any other thread-specific event that triggers do_exit()) then the thread goes away without the thread library having a chance to intervene. the sys_exit_group() syscall implements the mechanism within the kernel, which, besides robustness, is also *much* faster. Instead of the threading library having to tkill() every thread available, the kernel can use the already existing 'broadcast signal' capability. (the threading library cannot use broadcast signals because that would kill the initial thread as well.) as a side-effect of the completion mechanism used by sys_exit_group() it was also possible to make the initial thread hang around as a zombie until every other thread in the group has exited. A 'Z' state thread is much easier to understand by users - it's around because it has to wait for all other threads to exit first. and as a side-effect of the initial thread hanging around in a guaranteed way, there are three advantages: - signals sent to the thread group via sys_kill() work again. Previously if the initial thread exited then all subsequent sys_kill() calls to the group PID failed with a -ESRCH. - the get_pid() function got faster: it does not have to check for tgid collision anymore. - procps has an easier job displaying threaded applications - since the thread group leader is always around, no thread group can 'hide' from procps just because the thread group leader has exited. [ - NOTE: the same mechanism can/will also be used by the upcoming threaded-coredumps patch. ] there's also another (small) advantage for threading libraries: eg. the new libpthreads does not even have any notion of 'group of threads' anymore - it does not maintain any global list of threads. Via this syscall it can purely rely on the kernel to manage thread groups. the patch itself does some internal changes to the way a thread exits: now the unhashing of the PID and the signal-freeing is done atomically. This is needed to make sure the thread group leader unhashes itself precisely when the last thread group member has exited. (the sys_exit_group() syscall has been used by glibc's new libpthreads code for the past couple of weeks and the concept is working just fine.)
-
Ingo Molnar authored
I forgot to remove an unused label in the deadlock fix patch.
-
- 10 Sep, 2002 1 commit
-
-
Ingo Molnar authored
This fixes the lockup. The bug happened because reparenting in the CLONE_THREAD case was done in a fundamentally non-atomic way, which was asking for various races to happen: eg. the target parent gets reparented to the currently exiting thread ... (the non-CLONE_THREAD case is safe because nothing reparents init.) the solution is to make all of reparenting atomic (including the forget_original_parent() bit) - this is possible with some reorganization done in signal.c and exit.c. This also made some of the loops simpler.
-
- 09 Sep, 2002 1 commit
-
-
Ingo Molnar authored
This avoids a crash that can be caused by a CLONE_DETACHED thread.
-
- 08 Sep, 2002 1 commit
-
-
Ingo Molnar authored
Support POSIX compliant thread signals on a kernel level with usable debugging (broadcast SIGSTOP, SIGCONT) and thread group management (broadcast SIGKILL), plus to load-balance 'process' signals between threads for better signal performance. Changes: - POSIX thread semantics for signals there are 7 'types' of actions a signal can take: specific, load-balance, kill-all, kill-all+core, stop-all, continue-all and ignore. Depending on the POSIX specifications each signal has one of the types defined for both the 'handler defined' and the 'handler not defined (kernel default)' case. Here is the table: ---------------------------------------------------------- | | userspace | kernel | ---------------------------------------------------------- | SIGHUP | load-balance | kill-all | | SIGINT | load-balance | kill-all | | SIGQUIT | load-balance | kill-all+core | | SIGILL | specific | kill-all+core | | SIGTRAP | specific | kill-all+core | | SIGABRT/SIGIOT | specific | kill-all+core | | SIGBUS | specific | kill-all+core | | SIGFPE | specific | kill-all+core | | SIGKILL | n/a | kill-all | | SIGUSR1 | load-balance | kill-all | | SIGSEGV | specific | kill-all+core | | SIGUSR2 | load-balance | kill-all | | SIGPIPE | specific | kill-all | | SIGALRM | load-balance | kill-all | | SIGTERM | load-balance | kill-all | | SIGCHLD | load-balance | ignore | | SIGCONT | load-balance | continue-all | | SIGSTOP | n/a | stop-all | | SIGTSTP | load-balance | stop-all | | SIGTTIN | load-balancen | stop-all | | SIGTTOU | load-balancen | stop-all | | SIGURG | load-balance | ignore | | SIGXCPU | specific | kill-all+core | | SIGXFSZ | specific | kill-all+core | | SIGVTALRM | load-balance | kill-all | | SIGPROF | specific | kill-all | | SIGPOLL/SIGIO | load-balance | kill-all | | SIGSYS/SIGUNUSED | specific | kill-all+core | | SIGSTKFLT | specific | kill-all | | SIGWINCH | load-balance | ignore | | SIGPWR | load-balance | kill-all | | SIGRTMIN-SIGRTMAX | load-balance | kill-all | ---------------------------------------------------------- as you can see it from the list, signals that have handlers defined never get broadcasted - they are either specific or load-balanced. - CLONE_THREAD implies CLONE_SIGHAND It does not make much sense to have a thread group that does not share signal handlers. In fact in the patch i'm using the signal spinlock to lock access to the thread group. I made the siglock IRQ-safe, thus we can load-balance signals from interrupt contexts as well. (we cannot take the tasklist lock in write mode from IRQ handlers.) this is not as clean as i'd like it to be, but it's the best i could come up with so far. - thread group list management reworked. threads are now removed from the group if the thread is unhashed from the PID table. This makes the most sense. This also helps with another feature that relies on an intact thread group list: multithreaded coredumps. - child reparenting reworked. the O(N) algorithm in forget_original_parent() causes massive performance problems if a large number of threads exit from the group. Performance improves more than 10-fold if the following simple rules are followed instead: - reparent children to the *previous* thread [exiting or not] - if a thread is detached then reparent to init. - fast broadcasting of kernel-internal SIGSTOP, SIGCONT, SIGKILL, etc. kernel-internal broadcasted signals are a potential DoS problem, since they might generate massive amounts of GFP_ATOMIC allocations of siginfo structures. The important thing to note is that the siginfo structure does not actually have to be allocated and queued - the signal processing code has all the information it needs, neither of these signals carries any information in the siginfo structure. This makes a broadcast SIGKILL a very simple operation: all threads get the bit 9 set in their pending bitmask. The speedup due to this was significant - and the robustness win is invaluable. - sys_execve() should not kill off 'all other' threads. the 'exec kills all threads if the master thread does the exec()' is a POSIX(-ish) thing that should not be hardcoded in the kernel in this case. to handle POSIX exec() semantics, glibc uses a special syscall, which kills 'all but self' threads: sys_exit_allbutself(). the straightforward exec() implementation just calls sys_exit_allbutself() and then sys_execve(). (this syscall is also be used internally if the thread group leader thread sys_exit()s or sys_exec()s, to ensure the integrity of the thread group.)
-
- 07 Sep, 2002 2 commits
-
-
Daniel Jacobowitz authored
Here are the changes I have - Fix some bugs I introduced in zap_thread - Improve the check for traced children in sys_wait4 - Fix parent links when using CLONE_PTRACE My thanks to OGAWA Hirofumi for pointing out the first bit. The only other issue I know of is something else Hirofumi pointed out earlier; there are problems when a tracing process dies unexpectedly. I'll come back to that later.
-
Ingo Molnar authored
I've done the attached patch to collect & clean up all the things that happened since yesterday.
-
- 05 Sep, 2002 1 commit
-
-
Ingo Molnar authored
This contains Daniel's suggested fix that allows a parent to PTRACE_ATTACH to a child it forked. That fixes the incorrect BUG_ON() assert that Ogawa's patch was intended to fix, and we thus undo Ogawa's patch. I've tested various ptrace uses and they appear to work just fine.
-
- 03 Sep, 2002 2 commits
-
-
Rusty Russell authored
This removes list_t, which is a gratuitous typedef for a "struct list_head". Unless there is good reason, the kernel doesn't usually typedef, as typedefs cannot be predeclared unlike structs.
-
Rusty Russell authored
This makes daemonize() call reparent_to_init() itself, as long suggested for 2.5, and fixes the callers so they don't call it again. Also fixes callers which set current->tty to NULL themselves (also no longer neccessary).
-
- 01 Sep, 2002 1 commit
-
-
Hirofumi Ogawa authored
The BUG_ON(p->ptrace) will be called if the CLONE_DETACH process is traced. This patch removes BUG_ON(p->ptrace), and also removes a workaround for it in sys_wait4().
-
- 31 Aug, 2002 1 commit
-
-
Daniel Jacobowitz authored
Gotta ptrace_unlink before calling release_task, and instead of fiddling with the real_parent directly.
-
- 20 Aug, 2002 1 commit
-
-
Ingo Molnar authored
This fixes the ptrace wait4() anomaly that can be observed in any previous Linux kernel i could get my hands at. If the parent still has other children (that are being traced by somebody), we wait for them or return immediately without an error in case of WNOHANG.
-
- 19 Aug, 2002 1 commit
-
-
Ingo Molnar authored
the attached patch updates a number of items: - adds cleanups suggested by Christoph Hellwig: needed unlikely() statements, a superfluous #define and line length problems. - splits up the global ptrace list into per-task ptrace lists. This was pretty straightforward, and this makes the worst-case exit() latency O(nr_children). the per-task ptrace lists unearthed a bug that the previous code did not take care of: tasks on the ptrace list have to be correctly reparented as well. This patch passed my stresstests as well.
-
- 13 Aug, 2002 1 commit
-
-
Ingo Molnar authored
the attached patch implements the per-CPU thread-structure cache to do detached exit, if the parent does not want to be notified of child exit via a signal.
-
- 24 Jul, 2002 1 commit
-
-
Ingo Molnar authored
- introduce new type of context-switch locking, this is a must-have for ia64 and sparc64. - load_balance() bug noticed by Scott Rhine and myself: scan the whole list to find imbalance number of tasks, not just the tail of the list. - sched_yield() fix: use current->array not rq->active.
-
- 21 Jul, 2002 1 commit
-
-
Ingo Molnar authored
This is a massive cleanup of the IRQ subsystem. It's losely based on Linus' original idea and DaveM's original implementation, to fold our various irq, softirq and bh counters into the preemption counter. with this approach it was possible: - to remove the 'big IRQ lock' on SMP - on which sti() and cli() relied. - to streamline/simplify arch/i386/kernel/irq.c significantly. - to simplify the softirq code. - to remove the preemption count increase/decrease code from the lowlevel IRQ assembly code. - to speed up schedule() a bit. Global sti() and cli() is gone forever on SMP, there is no more globally synchronizing irq-disabling capability. All code that relied on sti() and cli() and restore_flags() must use other locking mechanisms from now on (spinlocks and __cli()/__sti()). obviously this patch breaks massive amounts of code, so only limited .configs are working at the moment (UP is expected to be unaffected, but SMP will require various driver updates). The patch was developed and tested on SMP systems, and while the code is still a bit rough in places, the base IRQ code appears to be pretty robust and clean. while it boots already so the worst is over, there is lots of work left: eg. to fix the serial layer to not use cli()/sti() and bhs ...
-
- 19 Jul, 2002 1 commit
-
-
Greg Kroah-Hartman authored
-
- 01 Jul, 2002 1 commit
-
-
Linus Torvalds authored
Stop using "struct tms" internally - always use timer ticks (or one of the sane timeval/timespec types) instead. Explicitly convert to clock_t when copying to user space for the old broken interfaces that still use "clock_t". Clean up and unify jiffies<->timeval conversion.
-
- 28 May, 2002 1 commit
-
-
Robert Love authored
The attached trivial patch simply changes the printk debug statement in do_exit when preempt_count!=0 to say "note" instead of "error" and log at KERN_INFO in lieu of KERN_ERR. I want to keep the message around a bit, but people get too paranoid when things like nfsd legitimately exit with a preempt_count=1.
-
- 18 May, 2002 1 commit
-
-
Dave McCracken authored
A long time ago there was thread group code that at exit time tried to reparent a task to another task in the thread group. I discovered a major race condition in this code, and submitted a patch that removed it. This patch was accepted in, I think, 2.4.12. The code reappeared in 2.4.18 and sometime in the 2.5 tree before 2.5.15, breaking applications that use thread groups. As part of chasing this down, I figured out a way to remove the race condition while still preserving this behavior. I've attached a patch against 2.5.15 that fixes it.
-
- 28 Apr, 2002 1 commit
-
-
Russell King authored
The following patch drops the above functions from the ARM port; we've already removed them from the syscall table on ARM, so we can safely remove these from the ARM build.
-
- 25 Apr, 2002 1 commit
-
-
Linus Torvalds authored
-
- 22 Apr, 2002 1 commit
-
-
Alexander Viro authored
- sane dentry retention. Namely, we don't kill /proc/<pid> dentries at the first opportunity (as the current tree does). Instead we do the following: * ->d_delete() kills it only if process is already dead. * all ->lookup() in proc/base.c end with checking if process is still alive and unhash if it isn't. * proc_pid_lookup() (lookup for /proc/<pid>) caches reference to dentry in task_struct. It's _not_ counted in ->d_count. * ->d_iput() resets said reference to NULL. * release_task() (burying a zombie) checks if there is a cached reference and if there is - shrinks the subtree. * tasklist_lock is used for exclusion. That way we are guaranteed that after release_task() all dentries in /proc/<pid> will go away as soon as possible; OTOH, before release_task() we have normal retention policy - they go away under memory pressure with the same rules as for dentries on any other fs.
-