An error occurred fetching the project authors.
- 26 Jun, 2008 1 commit
-
-
Jens Axboe authored
This converts x86, x86-64, and xen to use the new helpers for smp_call_function() and friends, and adds support for smp_call_function_single(). Acked-by:
Ingo Molnar <mingo@elte.hu> Acked-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com>
-
- 17 Apr, 2008 1 commit
-
-
Roland McGrath authored
When we're stopped at syscall entry tracing, ptrace can change the %rax value from -ENOSYS to something else. If no system call is actually made because the syscall number (now in orig_rax) is bad, then we now always reset %rax to -ENOSYS again. This changes it to leave the return value alone after entry tracing. That way, the %rax value set by ptrace is there to be seen in user mode (or in syscall exit tracing). This is consistent with what the 32-bit kernel does. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- 26 Feb, 2008 1 commit
-
-
Ingo Molnar authored
pointed out by pageexec@freemail.hu: > what happens here is that gcc treats the argument area as owned by the > callee, not the caller and is allowed to do certain tricks. for ssp it > will make a copy of the struct passed by value into the local variable > area and pass *its* address down, and it won't copy it back into the > original instance stored in the argument area. > > so once sys_execve returns, the pt_regs passed by value hasn't at all > changed and its default content will cause a nice double fault (FWIW, > this part took me the longest to debug, being down with cold didn't > help it either ;). To fix this we pass in pt_regs by pointer. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 19 Feb, 2008 1 commit
-
-
Adrian Bunk authored
Signed-off-by:
Adrian Bunk <bunk@kernel.org> Cc: hpa@zytor.com Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 09 Feb, 2008 1 commit
-
-
Ingo Molnar authored
Use a common irq_return entry point for all the iret places, which need the paravirt INTERRUPT return wrapper. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 06 Feb, 2008 2 commits
-
-
Roland McGrath authored
This change broke recovery of exceptions in iret: commit 72fe4858 Author: Glauber de Oliveira Costa <gcosta@redhat.com> x86: replace privileged instructions with paravirt macros The ENTRY(native_iret) macro adds alignment padding before the iretq instruction, so "iret_label" no longer points exactly at the instruction. It was sloppy to leave the old "iret_label" label behind when replacing its nearby use. Removing it would have revealed the other use of the label later in the file, and upon noticing that use, anyone exercising the minimum of attention to detail expected of anyone touching this subtle code would realize it needed to change as well. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Roland McGrath authored
Unify the x86-64 behavior for 32-bit processes that set bogus %cs/%ss values (the only ones that can fault in iret) match what the native i386 behavior is. (do not kill the task via do_exit but generate a SIGSEGV signal) [ tglx@linutronix.de: build fix ] Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- 30 Jan, 2008 1 commit
-
-
Glauber de Oliveira Costa authored
The assembly code in entry_64.S issues a bunch of privileged instructions, like cli, sti, swapgs, and others. Paravirt guests are forbidden to do so, and we then replace them with macros that will do the right thing. Signed-off-by:
Glauber de Oliveira Costa <gcosta@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 25 Jan, 2008 1 commit
-
-
Peter Zijlstra authored
Use HR-timers (when available) to deliver an accurate preemption tick. The regular scheduler tick that runs at 1/HZ can be too coarse when nice level are used. The fairness system will still keep the cpu utilisation 'fair' by then delaying the task that got an excessive amount of CPU time but try to minimize this by delivering preemption points spot-on. The average frequency of this extra interrupt is sched_latency / nr_latency. Which need not be higher than 1/HZ, its just that the distribution within the sched_latency period is important. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- 17 Oct, 2007 1 commit
-
-
Andrey Mirkin authored
Right now register edi is just cleared before calling do_exit. That is wrong because correct return value will be ignored. Value from rax should be copied to rdi instead of clearing edi. AK: changed to 32bit move because it's strictly an int [ tglx: arch/x86 adaptation ] Signed-off-by:
Andrey Mirkin <major@openvz.org> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 11 Oct, 2007 3 commits
-
-
Peter Zijlstra authored
Run the lockdep_sys_exit hook after all other C code on the syscall return path. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Thomas Gleixner authored
Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Thomas Gleixner authored
Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- 31 Jul, 2007 1 commit
-
-
Stephane Eranian authored
Remove unused TIF_NOTIFY_RESUME flag for all processor architectures. The flag was not used excecpt on IA-64 where the patch replaces it with TIF_PERFMON_WORK. Signed-off-by:
stephane eranian <eranian@hpl.hp.com> Cc: <linux-arch@vger.kernel.org> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 22 Jul, 2007 1 commit
-
-
Tim Hockin authored
Background: /dev/mcelog is typically polled manually. This is less than optimal for situations where accurate accounting of MCEs is important. Calling poll() on /dev/mcelog does not work. Description: This patch adds support for poll() to /dev/mcelog. This results in immediate wakeup of user apps whenever the poller finds MCEs. Because the exception handler can not take any locks, it can not call the wakeup itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is caught at the next return from interrupt or exit from idle, calling the mce_user_notify() routine. This patch also disables the "fake panic" path of the mce_panic(), because it results in printk()s in the exception handler and crashy systems. This patch also does some small cleanup for essentially unused variables, and moves the user notification into the body of the poller, so it is only called once per poll, rather than once per CPU. Result: Applications can now poll() on /dev/mcelog. When an error is logged (whether through the poller or through an exception) the applications are woken up promptly. This should not affect any previous behaviors. If no MCEs are being logged, there is no overhead. Alternatives: I considered simply supporting poll() through the poller and not using TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error happening and the user application being notified is *the*most* critical window for us. Many uncorrectable errors can be logged to the network if given a chance. I also considered doing the MCE poll directly from the idle notifier, but decided that was overkill. Testing: I used an error-injecting DIMM to create lots of correctable DRAM errors and verified that my user app is woken up in sync with the polling interval. I also used the northbridge to inject uncorrectable ECC errors, and verified (printk() to the rescue) that the notify routine is called and the user app does wake up. I built with PREEMPT on and off, and verified that my machine survives MCEs. [wli@holomorphy.com: build fix] Signed-off-by:
Tim Hockin <thockin@google.com> Signed-off-by:
William Irwin <bill.irwin@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 23 Jun, 2007 1 commit
-
-
Andi Kleen authored
Previously a program could switch to a compat mode segment and then execute SYSCALL and it would jump to an uninitialized MSR and crash the kernel. Instead supply a dummy target for this case. Pointed out by Jan Beulich Cc: jbeulich@novell.com Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 02 May, 2007 1 commit
-
-
Jan Beulich authored
Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Andi Kleen <ak@suse.de>
-
- 26 Feb, 2007 1 commit
-
-
Eric W. Biederman authored
The problem: After moving an interrupt when is it safe to teardown the data structures for receiving the interrupt at the old location? With a normal pci device it is possible to issue a read to a device to flush all posted writes. This does not work for the oldest ioapics because they are on a 3-wire apic bus which is a completely different data path. For some more modern ioapics when everything is using front side bus delivery you can flush interrupts by simply issuing a read to the ioapic. For other modern ioapics emperical testing has shown that this does not work. So it appears the only reliable way to know the last of the irqs from an ioapic have been received from before the ioapic was reprogrammed is to received the first irq from the ioapic from after it was reprogrammed. Once we know the last irq message has been received from an ioapic into a local apic we then need to know that irq message has been processed through the local apics. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 15 Dec, 2006 1 commit
-
-
Linus Torvalds authored
It has caused more problems than it ever really solved, and is apparently not getting cleaned up and fixed. We can put it back when it's stable and isn't likely to make warning or bug events worse. In the meantime, enable frame pointers for more readable stack traces. Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 07 Dec, 2006 1 commit
-
-
Jan Beulich authored
This patch: - makes ret_from_sys_call no longer global (all external users were previously switched to use int_ret_from_sys_call) - adjusts placement of a CFI_{REMEMBER,RESTORE}_STATE pair to better fit logic flow - eliminates an unnecessary pair of CFI_{REMEMBER,RESTORE}_STATE - glues together function- and unwinder-wise the previously separate system_call and int_ret_from_sys_call function fragments Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Andi Kleen <ak@suse.de>
-
- 21 Oct, 2006 3 commits
-
-
Andi Kleen authored
Jan convinced me that it was unnecessary because the assembly stubs do this already on the stack. Cc: jbeulich@novell.com Signed-off-by:
Andi Kleen <ak@suse.de>
-
Andi Kleen authored
They break more than they fix Signed-off-by:
Andi Kleen <ak@suse.de>
-
Jan Beulich authored
This patch: - out of range system calls failing to return -ENOSYS under system call tracing [AK: split out from another patch by Jan as separate bugfix] Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Andi Kleen <ak@suse.de>
-
- 05 Oct, 2006 2 commits
-
-
Andi Kleen authored
Add correct CFI annotation to the backlink on top of the interrupt stack. Signed-off-by:
Andi Kleen <ak@suse.de>
-
Andi Kleen authored
Always make sure RIP/EIP is 0 in the registers stored on the top of the stack of a kernel thread. This makes sure the unwinder code won't try a fallback but knows the stack has ended. AK: this patch is a bit mysterious. in theory they should be terminated anyways, but it seems to fix at least one crash. Anyways double termination probably doesn't hurt. Signed-off-by:
Andi Kleen <ak@suse.de>
-
- 02 Oct, 2006 1 commit
-
-
Arnd Bergmann authored
Some architectures provide an execve function that does not set errno, but instead returns the result code directly. Rename these to kernel_execve to get the right semantics there. Moreover, there is no reasone for any of these architectures to still provide __KERNEL_SYSCALLS__ or _syscallN macros, so remove these right away. [akpm@osdl.org: build fix] [bunk@stusta.de: build fix] Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Andi Kleen <ak@muc.de> Acked-by:
Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ian Molton <spyro@f2s.com> Cc: Mikael Starvik <starvik@axis.com> Cc: David Howells <dhowells@redhat.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Hirokazu Takata <takata.hirokazu@renesas.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp> Cc: Richard Curnow <rc@rc0.org.uk> Cc: William Lee Irwin III <wli@holomorphy.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp> Cc: Chris Zankel <chris@zankel.net> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
Adrian Bunk <bunk@stusta.de> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 26 Sep, 2006 10 commits
-
-
Andi Kleen authored
SYSENTER can cause a NT to be set which might cause crashes on the IRET in the next task. Following similar i386 patch from Linus. Signed-off-by:
Andi Kleen <ak@suse.de>
-
Jan Beulich authored
Current gcc generates calls not jumps to noreturn functions. When that happens the return address can point to the next function, which confuses the unwinder. This patch works around it by marking asynchronous exception frames in contrast normal call frames in the unwind information. Then teach the unwinder to decode this. For normal call frames the unwinder now subtracts one from the address which avoids this problem. The standard libgcc unwinder uses the same trick. It doesn't include adjustment of the printed address (i.e. for the original example, it'd still be kernel_math_error+0 that gets displayed, but the unwinder wouldn't get confused anymore. This only works with binutils 2.6.17+ and some versions of H.J.Lu's 2.6.16 unfortunately because earlier binutils don't support .cfi_signal_frame [AK: added automatic detection of the new binutils and wrote description] Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Andi Kleen <ak@suse.de>
-
Andi Kleen authored
Signed-off-by:
Andi Kleen <ak@suse.de>
-
Andi Kleen authored
NMIs are not supposed to track the irq flags, but TRACE_IRQS_IRETQ did it anyways. Add a check. Cc: mingo@elte.hu Signed-off-by:
Andi Kleen <ak@suse.de>
-
Prasanna S.P authored
This patch moves the entry.S:error_entry to .kprobes.text section, since code marked unsafe for kprobes jumps directly to entry.S::error_entry, that must be marked unsafe as well. This patch also moves all the ".previous.text" asm directives to ".previous" for kprobes section. AK: Following a similar i386 patch from Chuck Ebbert AK: Also merged Jeremy's fix in. +From: Jeremy Fitzhardinge <jeremy@goop.org> KPROBE_ENTRY does a .section .kprobes.text, and expects its users to do a .previous at the end of the function. Unfortunately, if any code within the function switches sections, for example .fixup, then the .previous ends up putting all subsequent code into .fixup. Worse, any subsequent .fixup code gets intermingled with the code its supposed to be fixing (which is also in .fixup). It's surprising this didn't cause more havok. The fix is to use .pushsection/.popsection, so this stuff nests properly. A further cleanup would be to get rid of all .section/.previous pairs, since they're inherently fragile. +From: Chuck Ebbert <76306.1226@compuserve.com> Because code marked unsafe for kprobes jumps directly to entry.S::error_code, that must be marked unsafe as well. The easiest way to do that is to move the page fault entry point to just before error_code and let it inherit the same section. Also moved all the ".previous" asm directives for kprobes sections to column 1 and removed ".text" from them. Signed-off-by:
Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by:
Andi Kleen <ak@suse.de>
-
Andi Kleen authored
CVS hasn't been used for a long time for them. Signed-off-by:
Andi Kleen <ak@suse.de>
-
Andi Kleen authored
And remove some old obsolete ones. Signed-off-by:
Andi Kleen <ak@suse.de>
-
Andi Kleen authored
IO-APIC or local APIC can only be disabled at runtime anyways and Kconfig has forced these options on for a long time now. The Kconfigs are kept only now for the benefit of the shared acpi boot.c code. Signed-off-by:
Andi Kleen <ak@suse.de>
-
Andi Kleen authored
Previously it didn't align. Use the same one as the C compiler in blended mode, which is good for K8 and Core2 and doesn't hurt on P4. Signed-off-by:
Andi Kleen <ak@suse.de>
-
Andi Kleen authored
No need to include it from entry.S Drop all the #ifdef __ASSEMBLY__ Signed-off-by:
Andi Kleen <ak@suse.de>
-
- 30 Aug, 2006 1 commit
-
-
Andi Kleen authored
One open question: Should these added pushes perhaps be made conditional upon CONFIG_STACK_UNWIND or CONFIG_UNWIND_INFO? [AK: Not needed -- these are all very slow paths] Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 03 Aug, 2006 1 commit
-
-
Andi Kleen authored
Re-add backlink for old style unwinder to stack switching. Add proper stack frame and CFI annotations to call_softirq This prevents a oops when backtracing with fallback through the interrupt stack top. Suggested by Jan Beulich and Herbert Xu wanted it in 2.6.18. Cc: jbeulich@novell.com Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 03 Jul, 2006 1 commit
-
-
Ingo Molnar authored
Add irqflags-tracing support to x86_64. [akpm@osdl.org: build fix] Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 30 Jun, 2006 1 commit
-
-
Jörn Engel authored
Signed-off-by:
Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by:
Adrian Bunk <bunk@stusta.de>
-