aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86_64
Commit message (Collapse)AuthorAge
* [PATCH] kprobes: bad manipulation of 2 byte opcode on x86_64Satoshi Oshima2006-05-21
| | | | | | | | | | | | | | | | | | | | | | | Problem: If we put a probe onto a callq instruction and the probe is executed, kernel panic of Bad RIP value occurs. Root cause: If resume_execution() found 0xff at first byte of p->ainsn.insn, it must check the _second_ byte. But current resume_execution check _first_ byte again. I changed it checks second byte of p->ainsn.insn. Kprobes on i386 don't have this problem, because the implementation is a little bit different from x86_64. Cc: Andi Kleen <ak@muc.de> Signed-off-by: Satoshi Oshima <soshima@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Don't schedule on exception stack on preemptive kernelsAndi Kleen2006-05-16
| | | | | | | | | | | | | | | | Extends an earlier patch from John Blackwood to more exception handlers that also run on the exception stacks. Expand the use of preempt_conditional_{sti,cli} to all cases where interrupts are to be re-enabled during exception handling while running on an IST stack. Based on original patch from Jan Beulich. Cc: John Blackwood <john.blackwood@ccur.com> Cc: jbeulich@novell.com Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Fix memory hotadd heuristicsAndi Kleen2006-05-16
| | | | | | | | | | | | | | | | | This fixes some boot failures on Dell and Unisys systems with memory hotadd added. - Set hotadd_percent to 0 by default. This means anybody using hotadd memory needs to specify the value on the command line. That's because there are lots of Intel boxes which have a bogus hotplug area in their SRAT and they would waste a lot of memory before. - Fix calculation of how much memory to use when the hotplug area exceeds hotadd_percent - Fix fallback when the - Fix fallback if memory hotadd is not compiled in. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Don't warn for overflow in nommu case when dma_mask is < 32bitAndi Kleen2006-05-16
| | | | | | | | | | | This triggers for b44's 1GB DMA workaround which tries to map first and then bounces. The 32bit heuristic is reasonable because the IOMMU doesn't attempt to handle < 32bit masks anyways. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Avoid EBDA area in early boot allocatorAndi Kleen2006-05-08
| | | | | | | | | | | | | | | | | | | | | | | Based on analysis&patch from Robert Hentosch Observed on a Dell PE6850 with 16GB The problem occurs very early on, when the kernel allocates space for the temporary memory map called bootmap. The bootmap overlaps the EBDA region. EBDA region is not historically reserved in the e820 mapping. When the bootmap is freed it marks the EBDA region as usable. If you notice in setup.c there is already code to work around the EBDA in reserve_ebda_region(), this check however occurs after the bootmap is allocated and doesn't prevent the bootmap from using this range. AK: I redid the original patch. Thanks also to Jan Beulich for spotting some mistakes. Cc: Robert_Hentosch@dell.com Cc: jbeulich@novell.com Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: add nmi_exit to die_nmiCorey Minyard2006-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | Playing with NMI watchdog on x86_64, I discovered that it didn't do what I expected. It always panic-ed, even when it didn't happen from interrupt context. This patch solves that problem for me. Also, in this case, do_exit() will be called with interrupts disabled, I believe. Would it be wise to also call local_irq_enable() after nmi_exit()? [Yes I added it -AK] Currently, on x86_64, any NMI watchdog timeout will cause a panic because the irq count will always be set to be in an interrupt when do_exit() is called from die_nmi(). If we add nmi_exit() to the die_nmi() call (since the nmi will never exit "normally") it seems to solve this problem. The following small program can be used to trigger the NMI watchdog to reproduce this: main () { iopl(3); for (;;) asm("cli"); } Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: fix die_lock nestingCorey Minyard2006-05-08
| | | | | | | | | | | | | I noticed this when poking around in this area. The oops_begin() function in x86_64 would only conditionally claim the die_lock if the call is nested, but oops_end() would always release the spinlock. This patch adds a nest count for the die lock so that the release of the lock is only done on the final oops_end(). Signed-off-by: Corey Minyard <minyard@acm.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Check for too many northbridges in IOMMU codeAndi Kleen2006-05-08
| | | | | | | | The IOMMU code can only deal with 8 northbridges. Error out when more are found. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: avoid IRQ0 ioapic pin collisionKimball Murray2006-05-08
| | | | | | | | | | | | | | | | | | The patch addresses a problem with ACPI SCI interrupt entry, which gets re-used, and the IRQ is assigned to another unrelated device. The patch corrects the code such that SCI IRQ is skipped and duplicate entry is avoided. Second issue came up with VIA chipset, the problem was caused by original patch assigning IRQs starting 16 and up. The VIA chipset uses 4-bit IRQ register for internal interrupt routing, and therefore cannot handle IRQ numbers assigned to its devices. The patch corrects this problem by allowing PCI IRQs below 16. Cc: len.brown@intel.com Signed-off by: Natalie Protasevich <Natalie.Protasevich@unisys.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge branch 'audit.b10' of ↵Linus Torvalds2006-05-02
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current * 'audit.b10' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current: [PATCH] Audit Filter Performance [PATCH] Rework of IPC auditing [PATCH] More user space subject labels [PATCH] Reworked patch for labels on user space messages [PATCH] change lspp ipc auditing [PATCH] audit inode patch [PATCH] support for context based audit filtering, part 2 [PATCH] support for context based audit filtering [PATCH] no need to wank with task_lock() and pinning task down in audit_syscall_exit() [PATCH] drop task argument of audit_syscall_{entry,exit} [PATCH] drop gfp_mask in audit_log_exit() [PATCH] move call of audit_free() into do_exit() [PATCH] sockaddr patch [PATCH] deal with deadlocks in audit_free()
| * [PATCH] drop task argument of audit_syscall_{entry,exit}Al Viro2006-05-01
| | | | | | | | | | | | ... it's always current, and that's a good thing - allows simpler locking. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | [PATCH] x86_64: make PC Speaker driver workMikael Pettersson2006-05-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PC Speaker driver's ->probe() routine doesn't even get called in the 64-bit kernels. The reason for that is that the arch code apparently has to explictly add a "pcspkr" platform device in order for the driver core to call the ->probe() routine. arch/i386/kernel/setup.c unconditionally adds a "pcspkr" device, but the x86_64 kernel has no code at all related to the PC Speaker. The patch below copies the relevant code from i386 to x86_64, which makes the PC Speaker work for me on x86_64. Cc: Dmitry Torokhov <dtor_core@ameritech.net> Acked-by: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] x86_64: Add compat_sys_vmsplice and use it in x86-64Andi Kleen2006-05-01
|/ | | | | | Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Remove __devinit and __cpuinit from notifier_call definitionsChandra Seetharaman2006-04-26
| | | | | | | | | | | | | Few of the notifier_chain_register() callers use __init in the definition of notifier_call. It is incorrect as the function definition should be available after the initializations (they do not unregister them during initializations). This patch fixes all such usages to _not_ have the notifier_call __init section. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Fix a race in the free_iommu pathMike Waychison2006-04-22
| | | | | | | | | | | | | | | | | We do this by removing a micro-optimization that tries to avoid grabbing the iommu_bitmap_lock spinlock and using a bus-locked operation. This still races with other simultaneous alloc_iommu or free_iommu(size > 1) which both use bus-unlocked operations. The end result of this race is eventually ending up with an iommu_gart_bitmap that has bits errornously set all over, making large contiguous iommu space allocations fail with 'PCI-DMA: Out of IOMMU space'. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Pass -32 to the assembler when compiling the 32bit vsyscall ↵Andi Kleen2006-04-22
| | | | | | | | | | | | | | | | | | pages This quietens warnings and actually fixes a bug. The unwind tables would come out wrong without -32, causing pthread cancellation during them to crash in the gcc runtime. The problem seems to only happen with newer binutils (it doesn't happen with 2.16.91.0.2 but happens wit 2.16.91.0.5) Thanks to David Altobelli <david.altobelli@hp.com> and Brian Baker <Brian.B@hp.com> for test case and initial analysis. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: sparsemem does not need node_mem_mapAndy Whitcroft2006-04-22
| | | | | | | | | | | | | | | Seems we are trying to init the node_mem_map when we don't need to, for example when SPARSEMEM is enabled. This causes the error below during compilation. Use CONFIG_FLAT_NODE_MEM_MAP to gate allocation and init. arch/x86_64/mm/numa.c: In function `setup_node_zones': arch/x86_64/mm/numa.c:191: error: structure has no member named `node_mem_map' Signed-off-by: Andy Whitcroft <apw@shadowen.org> Acked-by: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] i386/x86-64: Fix x87 information leak between processesAndi Kleen2006-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE when an exception is pending. This means the value leak through context switches and allow processes to observe some x87 instruction state of other processes. This was actually documented by AMD, but nobody recognized it as being different from Intel before. The fix first adds an optimization: instead of unconditionally calling FNCLEX after each FXSAVE test if ES is pending and skip it when not needed. Then do a x87 load from a kernel variable to clear FOP/FIP/FDP. This means other processes always will only see a constant value defined by the kernel in their FP state. I took some pain to make sure to chose a variable that's already in L1 during context switch to make the overhead of this low. Also alternative() is used to patch away the new code on CPUs who don't need it. Patch for both i386/x86-64. The problem was discovered originally by Jan Beulich. Richard Brunner provided the basic code for the workarounds, with contribution from Jan. This is CVE-2006-1056 Cc: richard.brunner@amd.com Cc: jbeulich@novell.com Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Switch Kprobes inline functions to __kprobes for x86_64Prasanna S Panchamukhi2006-04-19
| | | | | | | | | | | | | | | | Andrew Morton pointed out that compiler might not inline the functions marked for inline in kprobes. There-by allowing the insertion of probes on these kprobes routines, which might cause recursion. This patch removes all such inline and adds them to kprobes section there by disallowing probes on all such routines. Some of the routines can even still be inlined, since these routines gets executed after the kprobes had done necessay setup for reentrancy. Signed-off-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Add tee and sync_file_rangeAndi Kleen2006-04-18
| | | | | | | | tee was already there for some reason for native 64bit, but sys_sync_file_range was missing. Also add it to the compat layer. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: x86_64 add crashdump trigger pointsVivek Goyal2006-04-18
| | | | | | | | | | | | | | | | | o Start booting into the capture kernel after an Oops if system is in a unrecoverable state. System will boot into the capture kernel, if one is pre-loaded by the user, and capture the kernel core dump. o One of the following conditions should be true to trigger the booting of capture kernel. - panic_on_oops is set. - pid of current thread is 0 - pid of current thread is 1 - Oops happened inside interrupt context. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Update defconfigAndi Kleen2006-04-18
| | | | | Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] DMI: move dmi_scan.c from arch/i386 to drivers/firmware/Bjorn Helgaas2006-04-14
| | | | | | | | | | | | | | | | | | dmi_scan.c is arch-independent and is used by i386, x86_64, and ia64. Currently all three arches compile it from arch/i386, which means that ia64 and x86_64 depend on things in arch/i386 that they wouldn't otherwise care about. This is simply "mv arch/i386/kernel/dmi_scan.c drivers/firmware/" (removing trailing whitespace) and the associated Makefile changes. All three architectures already set CONFIG_DMI in their top-level Kconfig files. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Andi Kleen <ak@muc.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Andrey Panin <pazke@orbita1.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] x86_64: Fix embarassing typo in mmconfig bus checkAndi Kleen2006-04-11
| | | | | | | | Surprising that it still worked at all with this - yes it was tested. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] i386/x86-64: Remove checks for value == NULL in PCI config space accessAndi Kleen2006-04-11
| | | | | | | | Nobody should pass NULL here. Could in theory make it a BUG, but the NULL pointer oops will do as well. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Remove check for canonical RIPAndi Kleen2006-04-11
| | | | | | | | As pointed out by Linus it is useless now because entry.S should handle it correctly in all cases. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] vesafb: Fix incorrect logo colors in x86_64Antonino A. Daplas2006-04-11
| | | | | | | | | | | | | | | | | | | Bugzilla Bug 6299: A pixel size of 8 bits produces wrong logo colors in x86_64. The driver has 2 methods for setting the color map, using the protected mode interface provided by the video BIOS and directly writing to the VGA registers. The former is not supported in x86_64 and the latter is enabled only in i386. Fix by enabling the latter method in x86_64 only if supported by the BIOS. If both methods are unsupported, change the visual of vesafb to STATIC_PSEUDOCOLOR. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] No arch-specific strpbrk implementationsKyle McMartin2006-04-11
| | | | | | | | | | | | | | | While cleaning up parisc_ksyms.c earlier, I noticed that strpbrk wasn't being exported from lib/string.c. Investigating further, I noticed a changeset that removed its export and added it to _ksyms.c on a few more architectures. The justification was that "other arches do it." I think this is wrong, since no architecture currently defines __HAVE_ARCH_STRPBRK, there's no reason for any of them to be exporting it themselves. Therefore, consolidate the export to lib/string.c. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Configurable NODES_SHIFTYasunori Goto2006-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current implementations define NODES_SHIFT in include/asm-xxx/numnodes.h for each arch. Its definition is sometimes configurable. Indeed, ia64 defines 5 NODES_SHIFT values in the current git tree. But it looks a bit messy. SGI-SN2(ia64) system requires 1024 nodes, and the number of nodes already has been changeable by config. Suitable node's number may be changed in the future even if it is other architecture. So, I wrote configurable node's number. This patch set defines just default value for each arch which needs multi nodes except ia64. But, it is easy to change to configurable if necessary. On ia64 the number of nodes can be already configured in generic ia64 and SN2 config. But, NODES_SHIFT is defined for DIG64 and HP'S machine too. So, I changed it so that all platforms can be configured via CONFIG_NODES_SHIFT. It would be simpler. See also: http://marc.theaimsgroup.com/?l=linux-kernel&m=114358010523896&w=2 Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Andi Kleen <ak@muc.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Jack Steiner <steiner@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Update 32-bit system call tableAndi Kleen2006-04-09
| | | | | Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Eliminate IA32_NR_syscalls defineAndi Kleen2006-04-09
| | | | | | | | | | Or rather compute it based on the table length automatically. This also has the intended side effect of not warning for new system calls anymore. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: fix CONFIG_REORDERSam Ravnborg2006-04-09
| | | | | | | | | | | | | | Fix CONFIG_REORDER. The value of cflags-y was assined to CFLAGS before cflags-y was assigned the value used for CONFIG_REORDER. Use cflags-y for all CFLAGS options in the Makefile to avoid this happening again. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Plug GS leak in arch_prctl()John Blackwood2006-04-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In linux-2.6.16, we have noticed a problem where the gs base value returned from an arch_prtcl(ARCH_GET_GS, ...) call will be incorrect if: - the current/calling task has NOT set its own gs base yet to a non-zero value, - some other task that ran on the same processor previously set their own gs base to a non-zero value. In this situation, the ARCH_GET_GS code will read and return the MSR_KERNEL_GS_BASE msr register. However, since the __switch_to() code does NOT load/zero the MSR_KERNEL_GS_BASE register when the task that is switched IN has a zero next->gs value, the caller of arch_prctl(ARCH_GET_GS, ...) will get back the value of some previous tasks's gs base value instead of 0. Change the arch_prctl() ARCH_GET_GS code to only read and return the MSR_KERNEL_GS_BASE msr register if the 'gs' register of the calling task is non-zero. Side note: Since in addition to using arch_prctl(ARCH_SET_GS, ...), a task can also setup a gs base value by using modify_ldt() and write an index value into 'gs' from user space, the patch below reads 'gs' instead of using thread.gs, since in the modify_ldt() case, the thread.gs value will be 0, and incorrect value would be returned (the task->thread.gs value). When the user has not set its own gs base value and the 'gs' register is zero, then the MSR_KERNEL_GS_BASE register will not be read and a value of zero will be returned by reading and returning 'task->thread.gs'. The first patch shown below is an attempt at implementing this approach. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Fix drift with HPET timer enabledJordan Hargrave2006-04-09
| | | | | | | | | | | | | | | | | | | | If the HPET timer is enabled, the clock can drift by ~3 seconds a day. This is due to the HPET timer not being initialized with the correct setting (still using PIT count). If HZ changes, this drift can become even more pronounced. HPET patch initializes tick_nsec with correct tick_nsec settings for HPET timer. Vojtech comments: "It's not entirely correct (it assumes the HPET ticks totally exactly), but it's significantly better than assuming the PIT error there." Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] i386/x86-64: Return defined error value for bad PCI config space ↵Andi Kleen2006-04-09
| | | | | | | | | | | accesses Mostly to get better handling when a extended config space access has to fallback to Type1. Cc: gregkh@suse.de Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] i386/x86_64: Check if MCFG works for the first 16 bussesAndi Kleen2006-04-09
| | | | | | | | | | | | | Previously only the first bus would be checked against Type 1. Why 16? Checking all would need too much memory and we can assume that systems with more than 16 busses have better than average quality BIOS. This is an additional defense against bad MCFG tables. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Fixup read_mostly section on internode cache line size for vSMPRavikiran G Thirumalai2006-04-09
| | | | | | | | | Fixup the read mostly section to start at internode cacheline boundary. Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by: Shai Fultheim <shai@scalex86.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Don't return error for HPET initialization in initcallAndi Kleen2006-04-09
| | | | | Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Don't export strlen twiceAndi Kleen2006-04-09
| | | | | | | | | | | Fix WARNING: vmlinux: 'strlen' exported twice. Previous export was in vmlinux Reported by Mats Johannesson Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: When user could have changed RIP always force IRETAndi Kleen2006-04-09
| | | | | | | | | | | | | | | | | | | | | Intel EM64T CPUs handle uncanonical return addresses differently from AMD CPUs. The exception is reported in the SYSRET, not the next instruction. This leads to the kernel exception handler running on the user stack with the wrong GS because the kernel didn't expect exceptions on this instruction. This version of the patch has the teething problems that plagued an earlier version fixed. This is CVE-2006-0744 Thanks to Ernie Petrides and Asit B. Mallick for analysis and initial patches. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Don't run NMI watchdog during machine checksAndi Kleen2006-04-09
| | | | | | | | Machine checks can stall the machine for a long time and it's not good to trigger the nmi watchdog during that. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Clear APIC feature bit when local APIC is disabledAndi Kleen2006-04-09
| | | | | | | | | Needed for other checks later in ACPI. Pointed out by Len Brown Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Fix compilation with CONFIG_PCI=n / allnoconfigAndi Kleen2006-04-09
| | | | | Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] i386/x86-64: Check that MCFG points to an e820 reserved areaArjan van de Ven2006-04-09
| | | | | | | | | | | | | | | | | | This patch introduces a user for the e820_all_mapped function: There have been several machines that don't have a working MMCONFIG, often because of a buggy MCFG table in the ACPI bios. This patch adds a simple sanity check that detects a whole bunch of these cases, and when it detects it, linux now boots rather than crash-and-burns. The accuracy of this detection can in principle be improved if there was a "is this entire range in e820 with THIS attribute", but no such function exist and the complexity needed for this is not really worth it; this simple check already catches most cases anyway. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Introduce e820_all_mappedArjan van de Ven2006-04-09
| | | | | | | | | | | | | | Introduce a e820_all_mapped() function which checks if the entire range <start,end> is mapped with type. This is done by moving the local start variable to the end of each known-good region; if at the end of the function the start address is still before end, there must be a part that's not of the correct type; otherwise it's a good region. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Rename e820_mapped to e820_any_mappedArjan van de Ven2006-04-09
| | | | | | | | | | | | Rename e820_mapped to e820_any_mapped since it tests if any part of the range is mapped according to the type. Later steps will introduce e820_all_mapped which will check if the entire range is mapped with the type. Both have their merit. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Handle empty PXMs that only contain hotplug memoryAndi Kleen2006-04-09
| | | | | | | | | | | | | | | | | | | | | | The node setup code would try to allocate the node metadata in the node itself, but that fails if there is no memory in there. This can happen with memory hotplug when the hotplug area defines an so far empty node. Now use bootmem to try to allocate the mem_map in other nodes. And if it fails don't panic, but just ignore the node. To make this work I added a new __alloc_bootmem_nopanic function that does what its name implies. TBD should try to use nearby nodes here. Currently we just use any. It's hard to do it better because bootmem doesn't have proper fallback lists yet. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Reserve SRAT hotadd memory on x86-64Andi Kleen2006-04-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From: Keith Mannthey, Andi Kleen Implement memory hotadd without sparsemem. The memory in the SRAT hotadd area is just preserved instead and can be activated later. There are a few restrictions: - Only one continuous hotadd area allowed per node The main problem is dealing with the many buggy SRAT tables that are out there. The strategy here is to reject anything suspicious. Originally from Keith Mannthey, with several hacks and changes by AK and also contributions from Andrew Morton [ TBD: Problems pointed out by KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>: 1) Goto's rebuild_zonelist patch will not work if CONFIG_MEMORY_HOTPLUG=n. Rebuilding zonelist is necessary when the system has just memory < 4G at boot, and hot add memory > 4G. because x86_64 has DMA32, ZONE_NORAML is not included into zonelist at boot time if system doesn't have memory >4G at boot. [AK: should just force the higher zones at boot time when SRAT tells us] 2) zone and node's spanned_pages and present_pages are not incremented. They should be. For example, our server (ia64/Fujitsu PrimeQuest) can equip memory from 4G to 1T(maybe 2T in future), and SRAT will *always* say we have possible 1T +memory. (Microsoft requires "write all possible memory in SRAT") When we reserve memmap for possible 1T memory, Linux will not work well in +minimum 4G configuraion ;) [AK: needs limiting to 5-10% of max memory] ] Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Support memory hotadd without sparsememAndi Kleen2006-04-09
| | | | | | | | | | | Memory hotadd doesn't need SPARSEMEM, but can be handled by just preallocating mem_maps. This only needs some untangling of ifdefs to enable the necessary code even without SPARSEMEM. Originally from Keith Mannthey, hacked by AK. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Clean up execve pathAndi Kleen2006-04-09
| | | | | | | | | Just call IRET always, no need for any special cases. Needed for the next bug fix. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-21 04:50:37 -0500