- 30 Jan, 2008 40 commits
-
-
Thomas Gleixner authored
More stuff shuffeled to the correct place Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Thomas Gleixner authored
Move the mce related declarations where they belong, fix the users and remove 32bit dependency in mce.h Signed-off-by:
-
Thomas Gleixner authored
Move them and fixup some users. Signed-off-by:
-
Thomas Gleixner authored
Move k8 related declarations to k8.h and fix numa_64.c Signed-off-by:
-
Thomas Gleixner authored
Move idle related declarations to processor_64.h, where the the others are as well. Signed-off-by:
-
Thomas Gleixner authored
early_indentify_cpu is only used in setup_64.c Signed-off-by:
-
Thomas Gleixner authored
Move acpi/pci related declarations to the correct headers and remove the duplicate. Build fix from: Andrew Morton Signed-off-by:
-
Thomas Gleixner authored
Remove declarations which are made already in the appropriate header file. Signed-off-by:
-
Thomas Gleixner authored
Unify apic.h variants. Signed-off-by:
-
Thomas Gleixner authored
Use u32 so 32 and 64bit have the same interface. Andrew Morton: xen, lguest build fixes Signed-off-by:
-
Thomas Gleixner authored
Preperatory patch for merging apic headers. Signed-off-by:
-
Thomas Gleixner authored
Use the same name for the 32 and 64 bit variant. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style clenaup. Move the K8 local apic defines to apicdef.h, where they belong Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
White space and coding style cleanups. Change unsigned to int. There is no win when we compare mincount against pc->size, which is an int as well. Casting pc->size to unsigned just might hide real problems. Signed-off-by:
-
Thomas Gleixner authored
Create a ldt write accessor like the 32 bit one. Preparatory patch for merging ldt.c and anyway necessary for 64bit paravirt ops. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style clenaup. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style clenaup. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style cleanup. Signed-off-by:
-
Ingo Molnar authored
code cleanups: errors lines of code errors/KLOC arch/x86/kernel/pci-gart_64.c 183 748 244.6 arch/x86/kernel/pci-gart_64.c 0 790 0 Signed-off-by: -
Ingo Molnar authored
manually clean up some of the damage that lindent caused. (this is a separate commit so that in the unlikely case of a typo we can bisect it down to the manual edits.) Signed-off-by:
-
Ingo Molnar authored
lindent these files: errors lines of code errors/KLOC arch/x86/math-emu/ 2236 9424 237.2 arch/x86/math-emu/ 128 8706 14.7 no other changes. No code changed: text data bss dec hex filename 5589802 612739 3833856 10036397 9924ad vmlinux.before 5589802 612739 3833856 10036397 9924ad vmlinux.after the intent of this patch is to ease the automated tracking of kernel code quality - it's just much easier for us to maintain it if every file in arch/x86 is supposed to be clean. NOTE: it is a known problem of lindent that it causes some style damage of its own, but it's a safe tool (well, except for the gcc array range initializers extension), so we did the bulk of the changes via lindent, and did the manual fixups in a followup patch. the resulting math-emu code has been tested by Thomas Gleixner on a real 386 DX CPU as well, and it works fine. Signed-off-by: -
Ingo Molnar authored
lindent the mach-voyager files to get rid of more than 300 style errors: errors lines of code errors/KLOC arch/x86/mach-voyager/ [old] 409 3729 109.6 arch/x86/mach-voyager/ [new] 71 3678 19.3 Signed-off-by: -
Ingo Molnar authored
clean up arch/x86/kernel/aperture_64.c printk()s. Signed-off-by:
-
Ingo Molnar authored
whitespace cleanup. No code changed: text data bss dec hex filename 2080 76 4 2160 870 aperture_64.o.before 2080 76 4 2160 870 aperture_64.o.after errors lines of code errors/KLOC arch/x86/kernel/aperture_64.c 114 299 381.2 arch/x86/kernel/aperture_64.c 0 315 0 Signed-off-by: -
Thomas Gleixner authored
White space and coding style clenaup. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style clenaup. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style clenaup. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style clenaup. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style cleanup. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style clenaup. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style clenaup. Signed-off-by:
-
Thomas Gleixner authored
White space and coding style clenaup. Signed-off-by:
-
H. Peter Anvin authored
asm/cpufeature.h was already almost unified; this completes the job. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
H. Peter Anvin authored
Create <asm/asm.h>, with common definitions suitable for assembly unification. Signed-off-by:
-
Hiroshi Shimamoto authored
local_irq_enable() is missing after sched_clock_idle_wakeup_event(). Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by:
-
Ingo Molnar authored
do a proper idle-wakeup event on HLT as well - some CPUs stop the TSC in HLT too, not just when going through the ACPI methods. (the ACPI idle code already does this.) [ update the 64-bit side too, as noticed by Jiri Slaby. ] Signed-off-by:
-
Guillaume Chazarain authored
scale the sched_clock() cyc_2_nsec scaling factor according to CPU frequency changes. [ mingo@elte.hu: simplified it and fixed it for SMP. ] Signed-off-by:
-
Roland McGrath authored
cf http://lkml.org/lkml/2007/10/3/41 To summarize: on Linux, SA_ONSTACK decides whether you are already on the signal stack based on the value of the SP at the time of a signal. If you are not already inside the range, you are not "on the signal stack" and so the new signal handler frame starts over at the base of the signal stack. sigaltstack (and sigstack before it) was invented in BSD. There, the SA_ONSTACK behavior has always been different. It uses a kernel state flag to decide, rather than the SP value. When you first take an SA_ONSTACK signal and switch to the alternate signal stack, it sets the SS_ONSTACK flag in the thread's sigaltstack state in the kernel. Thereafter you are "on the signal stack" and don't switch SP before pushing a handler frame no matter what the SP value is. Only when you sigreturn from the original handler context do you clear the SS_ONSTACK flag so that a new handler frame will start over at the base of the alternate signal stack. The undesireable effect of the Linux behavior is that an overflow of the alternate signal stack can not only go undetected, but lead to a ring buffer effect of clobbering the original handler frame at the base of the signal stack for each successive signal that comes just after the overflow. This is what Shi Weihua's test case demonstrates. Normally this does not come up because of the signal mask, but the test case uses SA_NODEFER for its SIGSEGV handler. The other subtle part of the existing Linux semantics is that a simple longjmp out of a signal handler serves to take you off the signal stack in a safe and reliable fashion without having used sigreturn (nor having just returned from the handler normally, which means the same). After the longjmp (or even informal stack switching not via any proper libc or kernel interface), the alternate signal stack stands ready to be used again. A paranoid program would allocate a PROT_NONE red zone around its alternate signal stack. Then a small overflow would trigger a SIGSEGV in handler setup, and be fatal (core dump) whether or not SIGSEGV is blocked. As with thread stack red zones, that cannot catch all overflows (or underflows). e.g., a local array as large as page size allocated in a function called from a handler, but not actually touched before more calls push more stack, could cause an overflow that silently pushes into some unrelated allocated pages. The BSD behavior does not do anything in particular about overflow. But it does at least avoid the wraparound or "ring buffer effect", so you'll just get a straightforward all-out overflow down your address space past the low end of the alternate signal stack. I don't know what the BSD behavior is for longjmp out of an SA_ONSTACK handler. The POSIX wording relating to sigaltstack is pretty minimal. I don't think it speaks to this issue one way or another. (The program that overflows its stack is clearly in undefined behavior territory of one sort or another anyhow.) Given the longjmp issue and the potential for highly subtle complications in existing programs relying on this in arcane ways deep in their code, I am very dubious about changing the behavior to the BSD style persistent flag. I think Shi Weihua's patches have a similar effect by tracking the SP used in the last handler setup. I think it would be sensible for the signal handler setup code to detect when it would itself be causing a stack overflow. Maybe something like the following patch (untested). This issue exists in the same way on all machines, so ideally they would all do a similar check. When it's the handler function itself or its callees that cause the overflow, rather than the signal handler frame setup alone crossing the boundary, this still won't help. But I don't see any way to distinguish that from the valid longjmp case. Signed-off-by:
-
