- 30 Apr, 2008 40 commits
-
-
Alan Cox authored
Three things here - Remove softcar handler - Correct termios change detection logic - Wrap break/ioctl in lock_kernel ready to drop it in the caller Signed-off-by:
Alan Cox <alan@redhat.com> Cc: Karsten Keil <kkeil@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Alan Cox authored
This one could do with some eyeballs on it. In theory it simply wraps the ioctl handler in lock/unlock_kernel ready for the lock/unlocks to be pushed into specific switch values. To do that means changing the code to return via a common exit path not all over the place as it does now, hence the big diff Signed-off-by:
-
Alan Cox authored
For some weird reason I can't ascertain (translation "I think its broken") the viocons driver calls directly into the n_tty ldisc code even if another ldisc is in use. It'll probably break if you do that but I'm just fixing the locking and adding a comment that its horked. Signed-off-by:
-
Alan Cox authored
As these are quite complex I've simply pushed the BKL down into the ioctl handler not tried to do anything neater. Signed-off-by:
-
Alan Cox authored
Wrap the ioctl handler, and in this case the break handler also in the BKL. Remove bogus softcar handlers. Signed-off-by:
-
Alan Cox authored
Remove broken softcar functions, wrap ioctl handler in BKL Signed-off-by:
-
Alan Cox authored
Lock the ioctl handlers and remove bogus softcar handling. Signed-off-by:
-
Alan Cox authored
Kill the softcar handlers again, wrap the ioctl handler in the BKL Signed-off-by:
-
Alan Cox authored
Wrap the ioctl code in lock_kernel calls Signed-off-by:
-
Alan Cox authored
Push the locking down into a couple of functions that need it and remove bogus TIOCG/SSOFTCAR handling Signed-off-by:
-
Alan Cox authored
Push the BKL down into various internal routines in the driver ready to remove it from the break, ioctl and other call points. Signed-off-by:
-
Alan Cox authored
This is an ancient driver so just wrap it in lock_kernel internally and be done. Signed-off-by:
-
Alan Cox authored
Again lock the bits we can't trivially prove are safe without the BKL and remove the broken TIOCS/GSOFTCAR handler. Signed-off-by:
-
Alan Cox authored
Push the BKL down into a few internal bits of code in this driver. Signed-off-by:
-
Alan Cox authored
Prepare epca for removing the lock from above. Most of epca is internally locked so we can trivially push it down to a few bits of code. Drop the TIOCG/SSOFTCAR handling as that is done *properly* with locks by the mid layer. Signed-off-by:
-
Alan Cox authored
Basically wrap it in lock_kernel where it is hard to prove the locking is ok. Signed-off-by:
-
Alan Cox authored
Just wrap this one in a lock_kernel. As I understand it there is no M68K SMP anyway. Signed-off-by:
-
Oleg Nesterov authored
Afaics, currently there are no kernel problems with ptracing init, it can't lose SIGNAL_UNKILLABLE flag and be killed/stopped by accident. The ability to strace/debug init can be very useful if you try to figure out why it does not work as expected. However, admin should know what he does, "gdb /sbin/init 1" stops init, it can't reap orphaned zombies or take care of /etc/inittab until continued. It is even possible to crash init (and thus the whole system) if you wish, ptracer has full control. See also the long discussion: http://marc.info/?t=120628018600001Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Acked-by:
Roland McGrath <roland@redhat.com> Acked-by:
Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
-
Oleg Nesterov authored
Nobody can block/ignore SIGSTOP, no need to use force_sig_specific() in ptrace_attach. Use the "regular" send_sig_info(). With this patch stracing of /sbin/init doesn't clear its SIGNAL_UNKILLABLE, but not that this makes ptracing of init safe. Signed-off-by:
-
Oleg Nesterov authored
Currently __ptrace_unlink() checks list_empty(->ptrace_list) to figure out whether the child was reparented. Change the code to use ptrace_reparented() to make this check more explicit and consistent. No functional changes. Signed-off-by:
-
Oleg Nesterov authored
Add another trivial helper for the sake of grep. It also auto-documents the fact that ->parent != real_parent implies ->ptrace. No functional changes. Signed-off-by:
-
Oleg Nesterov authored
Add a couple of small comments, it is not easy to see what this code does. Signed-off-by:
-
Oleg Nesterov authored
Trivial, use same_thread_group() in reparent_thread(). Signed-off-by:
-
Oleg Nesterov authored
exit.c has numerous "->exit_signal == -1" comparisons, this check is subtle and deserves a helper. Imho makes the code more parseable for humans. At least it's surely more greppable. Also, a couple of whitespace cleanups. No functional changes. Signed-off-by:
-
Roland McGrath authored
Replace TIF_RESTORE_SIGMASK with TS_RESTORE_SIGMASK and define our own set_restore_sigmask() function. This saves the costly SMP-safe set_bit operation, which we do not need for the sigmask flag since TIF_SIGPENDING always has to be set too. Signed-off-by:
-
Roland McGrath authored
Change all the #ifdef TIF_RESTORE_SIGMASK conditionals in non-arch code to #ifdef HAVE_SET_RESTORE_SIGMASK. If arch code defines it first, the generic set_restore_sigmask() using TIF_RESTORE_SIGMASK is not defined. Signed-off-by:
-
akpm@linux-foundation.org authored
TIF_RESTORE_SIGMASK no longer needs to be in the _TIF_WORK_* masks. Those low bits are scarce. Renumber TIF_RESTORE_SIGMASK to free one up. Signed-off-by:
-
Roland McGrath authored
TIF_RESTORE_SIGMASK no longer needs to be in the _TIF_WORK_* masks. Those low bits are scarce, and are all used up now. Renumber TIF_RESTORE_SIGMASK to free one up. Signed-off-by:
-
Roland McGrath authored
Set TIF_SIGPENDING in set_restore_sigmask. This lets arch code take TIF_RESTORE_SIGMASK out of the set of bits that will be noticed on return to user mode. On some machines those bits are scarce, and we can free this unneeded one up for other uses. It is probably the case that TIF_SIGPENDING is always set anyway everywhere set_restore_sigmask() is used. But this is some cheap paranoia in case there is an arcane case where it might not be. Signed-off-by:
-
Roland McGrath authored
This adds the set_restore_sigmask() inline in <linux/thread_info.h> and replaces every set_thread_flag(TIF_RESTORE_SIGMASK) with a call to it. No change, but abstracts the details of the flag protocol from all the calls. Signed-off-by:
-
Oleg Nesterov authored
Currently the buggy /sbin/init hangs if SIGSEGV/etc happens. The kernel sends the signal, init dequeues it and ignores, returns from the exception, repeats the faulting instruction, and so on forever. Imho, such a behaviour is not good. I think that the explicit loud death of the buggy /sbin/init is better than the silent hang. Change force_sig_info() to clear SIGNAL_UNKILLABLE when the task should be really killed. Signed-off-by:
-
Oleg Nesterov authored
Now that we rely on SIGNAL_UNKILLABLE flag, de_thread() doesn't need the nasty hack to kill the old ->child_reaper during the mt-exec. This also means we can avoid taking tasklist_lock around zap_other_threads(). Signed-off-by:
-
Oleg Nesterov authored
The global init has a lot of long standing problems with the unhandled fatal signals. - The "is_global_init(current)" check in get_signal_to_deliver() protects only the main thread. Sub-thread can dequee the fatal signal and shutdown the whole thread group except the main thread. If it dequeues SIGSTOP /sbin/init will be stopped, this is not right too. Note that we can't use is_global_init(->group_leader), this breaks exec and this can't solve other problems we have. - Even if afterwards ignored, the fatal signals sets SIGNAL_GROUP_EXIT on delivery. This breaks exec, has other bad implications, and this is just wrong. Introduce the new SIGNAL_UNKILLABLE flag to fix these problems. It also helps to solve some other problems addressed by the subsequent patches. Currently we use this flag for the global init only, but it could also be used by kthreads and (perhaps) by the sub-namespace inits. Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
Now that task_session() can't return a false NULL, check_kill_permission() doesn't need tasklist_lock. Signed-off-by:
-
Oleg Nesterov authored
This wasn't documented, but as Atsushi Tsuji pointed out check_kill_permission() needs tasklist_lock for task_session_nr(). I missed this fact when removed tasklist from the callers. Change check_kill_permission() to take tasklist_lock for the SIGCONT case. Re-order security checks so that we take tasklist_lock only if/when it is actually needed. This is a minimal fix for now, tasklist will be removed later. Also change the code to use task_session() instead of task_session_nr(). Also, remove the SIGCONT check from cap_task_kill(), it is bogus (and the whole function is bogus. Serge, Eric, why it is still alive?). Signed-off-by:
Atsushi Tsuji <a-tsuji@bk.jp.nec.com> Cc: Roland McGrath <roland@redhat.com> Cc: Serge Hallyn <serue@us.ibm.com> Signed-off-by:
-
Oleg Nesterov authored
send_signal() shouldn't call signalfd_notify() if it then fails with -EAGAIN. Harmless, just a paranoid cleanup. Also remove the comment. It is obsolete, signalfd_notify() was simplified and does a simple wakeup. Signed-off-by:
Davide Libenzi <davidel@xmailserver.org> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
A couple of small comments about how CLD_CONTINUED notification works. Signed-off-by:
-
Oleg Nesterov authored
Rename handle_stop_signal() to prepare_signal(), make it return a boolean, and move the callsites of sig_ignored() into it. No functional changes for now. But it would be nice to factor out the "should we drop this signal" checks as much as possible, before we try to fix the bugs with the sub-namespace init's signals (actually the global /sbin/init has some problems with signals too). Signed-off-by:
-
Oleg Nesterov authored
Move the callsite of print_fatal_signal() down, under "if (sig_kernel_coredump(signr))", so we don't need to check signr != SIGKILL. We are only interested in the sig_kernel_coredump() signals anyway, and due to the previous changes we almost never can see other fatal signals here except SIGKILL. Signed-off-by:
-
Oleg Nesterov authored
handle_stop_signal() clears SIGNAL_STOP_DEQUEUED when sig == SIGKILL. Remove this nasty special case. It was needed to prevent the race with group stop and exit caused by thread-specific SIGKILL. Now that we use complete_signal() for private signals too this is not needed, complete_signal() will notice SIGKILL and abort the soon-to-begin group stop. Except: the target thread is dead (has PF_EXITING). But in that case we should not just clear SIGNAL_STOP_DEQUEUED and nothing more. We should either kill the whole thread group, or silently ignore the signal. I suspect we are not right wrt zombie leaders, but this is another issue which and should be fixed separately. Note that this check can't abort the group stop if it was already started/finished, this check only adds a subtle side effect if we race with the thread which has already dequeued sig_kernel_stop() signal and temporary released ->siglock. Signed-off-by:
-
