- 30 Apr, 2008 40 commits
-
-
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 <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
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: -
eric miao authored
Signed-off-by:
-
eric miao authored
Reasons: 1. straight forward: the name "LCD_COLOR_DSTN_16BPP" is much better than "LCCR0_Pas | LCCR0_Color | LCCR0_Dual" 2. by defining LCD connection types as constants, it allows only valid possibilities 3. by removing the dependency of register bits definitions, those can be later moved into the body of pxafb.c, instead of having a regs-lcd.h around Currently, only lubbock, mainstone, zylonite and littleton have been modified to support these types (see coming patches after this). Other platforms are encouraged to change their way describing the LCD controller connections. Signed-off-by: -
eric miao authored
Use structure and array for palette buffer and dma descriptors to: 1. better organize code for future expansion like overlays 2. separate palette and dma descriptors from frame buffer Signed-off-by:
-
eric miao authored
This is part of the effort moving peripheral registers outside of pxa-regs.h, and using ioremap() make it possible the same IP can be re-used on different processors with different registers space As a result, the fixed mapping in pxa_map_io() is removed. The regs-lcd.h can actually moved to where closer to pxafb.c but some of its bit definitions are directly used by various platform code, though this is not a good style. Signed-off-by:
-
eric miao authored
So to get a better coding style and centralize the pxafb parameters handling code. Signed-off-by:
-
eric miao authored
Signed-off-by:
-
eric miao authored
Signed-off-by:
-
