aboutsummaryrefslogtreecommitdiff
path: root/arch/sparc/kernel/rtrap_64.S
AgeCommit message (Collapse)Author
2012-04-13sparc64: Remove trap return code which is now unnecessary.David S. Miller
Noticed by Linus. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-13sparc64: Eliminate obsolete __handle_softirq() functionPaul E. McKenney
The invocation of softirq is now handled by irq_exit(), so there is no need for sparc64 to invoke it on the trap-return path. In fact, doing so is a bug because if the trap occurred in the idle loop, this invocation can result in lockdep-RCU failures. The problem is that RCU ignores idle CPUs, and the sparc64 trap-return path to the softirq handlers fails to tell RCU that the CPU must be considered non-idle while those handlers are executing. This means that RCU is ignoring any RCU read-side critical sections in those handlers, which in turn means that RCU-protected data can be yanked out from under those read-side critical sections. The shiny new lockdep-RCU ability to detect RCU read-side critical sections that RCU is ignoring located this problem. The fix is straightforward: Make sparc64 stop manually invoking the softirq handlers. Reported-by: Meelis Roos <mroos@linux.ee> Suggested-by: David Miller <davem@davemloft.net> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by: Meelis Roos <mroos@linux.ee> Cc: stable@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-26sparc: keep calling do_signal() as long as pending signals remainAl Viro
Analog of what commit 494486a1d2697f2153199b6501ab5b4d6e15a2bb had done to alpha (another architecture with similar bug). One note: in rtrap_32.S part clr %l6 has been a rudiment of left after commit 28e6103665301ce60634e8a77f0b657c6cc099de (sparc: Fix debugger syscall restart interactions) has killed %l6 use in there. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-20sparc64: Fix hardirq tracing in trap return path.David S. Miller
We can overflow the hardirq stack if we set the %pil here so early, just let the normal control flow do it. This is fine as we are allowed to do the actual IRQ enable at any point after we call trace_hardirqs_on. Signed-off-by: David S. Miller <davem@davemloft.net>
2010-03-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6: sparc64: Make prom entry spinlock NMI safe. sparc64: Kill off old sys_perfctr system call and state. sparc: Update defconfigs. sparc: Provide io{read,write}{16,32}be().
2010-03-03sparc64: Kill off old sys_perfctr system call and state.David S. Miller
People should be using the perf events interfaces, and the way these system call facilities used the %pcr conflicts with the usage of the NMI watchdog and perf events. Signed-off-by: David S. Miller <davem@davemloft.net>
2009-10-29percpu: remove per_cpu__ prefix.Rusty Russell
Now that the return from alloc_percpu is compatible with the address of per-cpu vars, it makes sense to hand around the address of per-cpu variables. To make this sane, we remove the per_cpu__ prefix we used created to stop people accidentally using these vars directly. Now we have sparse, we can use that (next patch). tj: * Updated to convert stuff which were missed by or added after the original patch. * Kill per_cpu_var() macro. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Christoph Lameter <cl@linux-foundation.org>
2008-12-04sparc,sparc64: unify kernel/Sam Ravnborg
o Move all files from sparc64/kernel/ to sparc/kernel - rename as appropriate o Update sparc/Makefile to the changes o Update sparc/kernel/Makefile to include the sparc64 files NOTE: This commit changes link order on sparc64! Link order had to change for either of sparc32 and sparc64. And assuming sparc64 see more testing than sparc32 change link order on sparc64 where issues will be caught faster. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>