- 30 Apr, 2008 40 commits
-
-
Oleg Nesterov authored
Move the unchanged definition of __group_complete_signal() so that send_signal can see it. To simplify the reading of the next patches. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Oleg Nesterov authored
Suggested by Roland McGrath. Initialize signal->curr_target in copy_signal(). This way ->curr_target is never == NULL, we can kill the check in __group_complete_signal's hot path. Signed-off-by:
-
Oleg Nesterov authored
The comment in send_sig_info() is wrong, tasklist_lock can't help. The caller must ensure the task can't go away, otherwise ->sighand can be NULL even before we take the lock. p->sighand could be changed by exec(), but I can't imagine how it is possible to prevent exit(), but not exec(). Since the things seem to work, I assume all callers are correct. However, drm_vbl_send_signals() looks broken. block_all_signals() which is solely used by drm is definitely broken. Signed-off-by:
-
Oleg Nesterov authored
Convert do_tkill() to use rcu_read_lock() + lock_task_sighand() to avoid taking tasklist lock. Note that we don't return an error if lock_task_sighand() fails, we pretend the task dies after receiving the signal. Otherwise, we should fight with the nasty races with mt-exec without having any advantage. Signed-off-by:
-
Oleg Nesterov authored
Move handle_stop_signal() into send_signal(). This factors out a couple of callsites and allows us to do further unifications. Also, with this change specific_send_sig_info() does handle_stop_signal(). Not that this is really important, we never send STOP/CONT via send_sig() and friends, but still this looks more consistent. The only (afaics) special case is get_signal_to_deliver(). If the traced task dequeues SIGCONT, it can re-send it to itself after ptrace_stop() if the signal was blocked by debugger. In that case handle_stop_signal() is unnecessary, but hopefully not a problem. Signed-off-by:
-
Oleg Nesterov authored
handle_stop_signal() was changed, now send_group_sigqueue() doesn't need tasklist_lock. Signed-off-by:
-
Oleg Nesterov authored
Cosmetic, cache p->signal to make the code a bit more readable. Signed-off-by:
-
Oleg Nesterov authored
send_group_sigqueue() calls handle_stop_signal(), send_sigqueue() doesn't. This is not consistent and in fact I'd say this is (minor) bug. Move handle_stop_signal() from send_group_sigqueue() to do_send_sigqueue(), the latter is called by send_sigqueue() too. Signed-off-by:
-
Oleg Nesterov authored
lock_task_sighand() was changed, send_sigqueue() doesn't need rcu_read_lock() any longer. Signed-off-by:
-
Oleg Nesterov authored
Cache the values of current->signal/sighand. Shrinks .text a bit and makes the code more readable. Also, remove "sigset_t *mask", it is pointless because in fact we save the constant offset. Signed-off-by:
-
Oleg Nesterov authored
Cache the value of p->signal, and change the code to use while_each_thread() helper. Signed-off-by:
-
Oleg Nesterov authored
Now that handle_stop_signal() doesn't drop ->siglock, we can't see both ->group_stop_count && SIGNAL_STOP_STOPPED. Merge two "if" branches. As Roland pointed out, we never actually needed 2 do_notify_parent_cldstop() calls. Signed-off-by:
-
Oleg Nesterov authored
Previously handle_stop_signal(SIGCONT) could drop ->siglock. That is why kill_pid_info(SIGCONT) takes tasklist_lock to make sure the target task can't go away after unlock. Not needed now. Signed-off-by:
-
Oleg Nesterov authored
Based on discussion with Jiri and Roland. In short: currently handle_stop_signal(SIGCONT, p) sends the notification to p->parent, with this patch p itself notifies its parent when it becomes running. handle_stop_signal(SIGCONT) has to drop ->siglock temporary in order to notify the parent with do_notify_parent_cldstop(). This leads to multiple problems: - as Jiri Kosina pointed out, the stopped task can resume without actually seeing SIGCONT which may have a handler. - we race with another sig_kernel_stop() signal which may come in that window. - we race with sig_fatal() signals which may set SIGNAL_GROUP_EXIT in that window. - we can't avoid taking tasklist_lock() while sending SIGCONT. With this patch handle_stop_signal() just sets the new SIGNAL_CLD_CONTINUED flag in p->signal->flags and returns. The notification is sent by the first task which returns from finish_stop() (there should be at least one) or any other signalled thread from get_signal_to_deliver(). This is a user-visible change. Say, currently kill(SIGCONT, stopped_child) can't return without seeing SIGCHLD, with this patch SIGCHLD can be delayed unpredictably. Another difference is that if the child is ptraced by another process, CLD_CONTINUED may be delivered to ->real_parent after ptrace_detach() while currently it always goes to the tracer which doesn't actually need this notification. Hopefully not a problem. The patch asks for the futher obvious cleanups, I'll send them separately. Signed-off-by:
-
Oleg Nesterov authored
Every implementation of ->task_kill() does nothing when the signal comes from the kernel. This is correct, but means that check_kill_permission() should call security_task_kill() only for SI_FROMUSER() case, and we can remove the same check from ->task_kill() implementations. (sadly, check_kill_permission() is the last user of signal->session/__session but we can't s/task_session_nr/task_session/ here). NOTE: Eric W. Biederman pointed out cap_task_kill() should die, and I think he is very right. Signed-off-by:
-
Pavel Emelyanov authored
Both functions do the same thing after proper locking, but with different sigpending structs, so move the common code into a helper. After this we have 4 places that look very similar: send_sigqueue: calls do_send_sigqueue and signal_wakeup send_group_sigqueue: calls do_send_sigqueue and __group_complete_signal __group_send_sig_info: calls send_signal and __group_complete_signal specific_send_sig_info: calls send_signal and signal_wakeup Besides, send_signal performs actions similar to do_send_sigqueue's and __group_complete_signal - to signal_wakeup. It looks like they can be consolidated gracefully. Oleg said: Personally, I think this change is very good. But send_sigqueue() and send_group_sigqueue() have a very subtle difference which I was never able to understand. Let's suppose that sigqueue is already queued, and the signal is ignored (the latter means we should re-schedule cpu timer or handle overrruns). In that case send_sigqueue() returns 0, but send_group_sigqueue() returns 1. I think this is not the problem (in fact, I think this patch makes the behaviour more correct), but I hope Thomas can take a look and confirm. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Cc: Oleg Nesterov <oleg@tv-sign.ru> Cc: Roland McGrath <roland@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Pavel Emelyanov authored
The signr variable may be declared without initialization - it is set ro the return value from __dequeue_signal() right at the function beginning. Besides, after recalc_sigpending() two checks for signr to be not 0 may be merged into one. Both if-s become easier to read. Thanks to Oleg for pointing out mistakes in the first version of this patch. Signed-off-by:
-
Pavel Emelyanov authored
Both sig_ignored() and do_sigaction() check for signr to be explicitly or implicitly ignored. Introduce a helper for them. This patch is aimed to help handling signals by pid namespace's init, and was derived from one of Oleg's patches https://lists.linux-foundation.org/pipermail/containers/2007-December/009308.html so, if he doesn't mind, he should be considered as an author. Signed-off-by:
-
Oleg Nesterov authored
lock_task_sighand() was changed, and do_task_stat() doesn't need rcu_read_lock any longer. sighand->siglock protects all "interesting" fields. Except: it doesn't protect ->tty->pgrp, but neither does rcu_read_lock(), this should be fixed. Signed-off-by:
-
Oleg Nesterov authored
Just a trivial example, more to come. k_getrusage() holds rcu_read_lock() because it was previously required by lock_task_sighand(). Unneeded now. Signed-off-by:
-
Oleg Nesterov authored
Most of the callers of lock_task_sighand() doesn't actually need rcu_lock(). lock_task_sighand() needs it only to safely play with tsk->sighand, it can take the lock itself. Signed-off-by:
-
Oleg Nesterov authored
do_group_exit() checks SIGNAL_GROUP_EXIT to avoid taking sighand->siglock. Since ed5d2cac exec() doesn't set this flag, we should use signal_group_exit(). This is not needed for correctness, but can speedup the multithreaded exec and makes the code more consistent. Signed-off-by:
-
Oleg Nesterov authored
do_signal_stop() needs signal_group_exit() but checks sig->group_exit_task. This (optimization) is correct, SIGNAL_STOP_DEQUEUED and SIGNAL_GROUP_EXIT are mutually exclusive, but looks confusing. Use signal_group_exit(), this is not fastpath, the code clarity is more important. Signed-off-by:
-
Pavel Emelyanov authored
Two callers for send_signal() - the specific_send_sig_info and the __group_send_sig_info - both check for sig to be ignored or already queued. Move these checks into send_signal() and make it return 1 to indicate that the signal is dropped, but there's no error in this. Besides, merge comments and spell-check them. [oleg@tv-sign.ru: simplifications] Signed-off-by:
-
Pavel Emelyanov authored
This makes the code more readable, due to less brackets and small letters in name. I also move it above the send_signal() as a preparation for the 3rd patch. Signed-off-by:
-
Pavel Emelyanov authored
This function doesn't change the ret's value and thus always returns 0, with a single exception of returning -EAGAIN explicitly. Signed-off-by:
-
Jan Kara authored
When a directory on isofs is corrupted, we did not check whether length of the name in a directory entry and the length of the directory entry itself are consistent. This could lead to possible access beyond the end of buffer when the length of the name was too big. Add this sanity check to directory reading code. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Dan Williams authored
Allows a userspace metadata handler to take action upon detecting a device failure. Based on an original patch by Neil Brown. Changes: -added blocked_wait waitqueue to rdev -don't qualify Blocked with Faulty always let userspace block writes -added md_wait_for_blocked_rdev to wait for the block device to be clear, if userspace misses the notification another one is sent every 5 seconds -set MD_RECOVERY_NEEDED after clearing "blocked" -kill DoBlock flag, just test mddev->external Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Dan Williams authored
Found when trying to reassemble an active externally managed array. Without this check we hit the more noisy "sysfs duplicate" warning in the later call to kobject_add. Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
NeilBrown authored
When setting an array to 'readonly' or to 'active' via sysfs, we must make the appropriate set_disk_ro call too. Also when switching to "read_auto" (which is like readonly, but blocks on the first write so that metadata can be marked 'dirty') we need to be more careful about what state we are changing from. Signed-off-by:
-
NeilBrown authored
'safemode' relates to marking an array as 'clean' if there has been no write traffic for a while (a couple of seconds), to reduce the chance of the array being found dirty on reboot. ->safemode is set to '1' when there have been no write for a while, and it gets set to '0' when the superblock is updates with the 'clean' flag set. This requires a few fixes for 'external' metadata: - When an array is set to 'clean' via sysfs, 'safemode' must be cleared. - when we write to an array that has 'safemode' set (there must have been some delay in updating the metadata), we need to clear safemode. - Don't try to update external metadata in md_check_recovery for safemode transitions - it won't work. Also, don't try to support "immediate safe mode" (safemode==2) for external metadata, it cannot really work (the safemode timeout can be set very low if this is really needed). Signed-off-by: -
NeilBrown authored
I keep finding problems where an mddev gets reused and some fields has a value from a previous usage that confuses the new usage. So clear all fields that could possible need clearing when calling do_md_stop. Also initialise the 'level' of a new array to LEVEL_NONE (which isn't 0). Signed-off-by:
-
NeilBrown authored
All the metadata update processing for external metadata is on in user-space or through the sysfs interfaces, so make "md_update_sb" a no-op in that case. Signed-off-by:
-
Dan Williams authored
rdev->mddev is no longer valid upon return from entry->store() when the 'remove' command is given. Cc: <stable@kernel.org> Signed-off-by:
-
Eric Miao authored
FB_PXA_SMARTPANEL defaults to "n" and removed the cast to void *. Signed-off-by:
Daniel Mack <daniel@caiaq.de> Acked-by:
Eric Miao <eric.miao@marvell.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Eric Miao authored
Signed-off-by:
-
Eric Miao authored
the new_regs stuff has been removed, and all the setup (modification to those fbi->reg_*) is protected with IRQ disabled * disable IRQ is too heavy here, provided that no IRQ context will touch the fbi->reg_* and the only possible contending place is in the CPUFREQ_POSTCHANGE (task context), a mutex will be better, leave this for future improvement Signed-off-by: -
Eric Miao authored
Signed-off-by:
-
Eric Miao authored
using __raw_{read,write}l() everywhere looks messy, introduce lcd_{read,write}l() to get this cleaned up a bit Signed-off-by:
-
