linux/arch, branch v2.6.24.7

x86: Fix 32-bit x86 MSI-X allocation leakage

2008-05-01T21:48:59Z

commit 9d9ad4b51d2b29b5bbeb4011f5e76f7538119cf9 upstream This bug was introduced in the 2.6.24 lguest tree merge, where MSI-X vector allocation will eventually fail. The cause is the new bit array tracking used vectors is not getting cleared properly on IRQ destruction on the 32-bit APIC code. This can be seen easily using the ixgbe 10 GbE driver on multi-core systems by simply loading and unloading the driver a few times. Depending on the number of available vectors on the host system, the MSI-X allocation will eventually fail, and the driver will only be able to use legacy interrupts. Signed-off-by: Peter P Waskiewicz Jr Signed-off-by: Greg Kroah-Hartman

PARISC fix signal trampoline cache flushing

2008-04-19T01:53:30Z

upstream commit: cf39cc3b56bc4a562db6242d3069f65034ec7549 The signal trampolines were accidently flushing the kernel I$ instead of the users. Fix that up, and also add a missing user D$ flush while we're at it. Signed-off-by: Kyle McMartin Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

PARISC pdc_console: fix bizarre panic on boot

2008-04-19T01:53:29Z

upstream commit ef1afd4d79f0479960ff36bb5fe6ec6eba1ebff2 commit 721fdf34167580ff98263c74cead8871d76936e6 Author: Kyle McMartin Date: Thu Dec 6 09:32:15 2007 -0800 [PARISC] print more than one character at a time for pdc console introduced a subtle bug by accidentally removing the "static" from iodc_dbuf. This resulted in, what appeared to be, a trap without *current set to a task. Probably the result of a trap in real mode while calling firmware. Also do other misc clean ups. Since the only input from firmware is non blocking, share iodc_dbuf between input and output, and spinlock the only callers. [jejb: fixed up rejections against the stable tree] Signed-off-by: Kyle McMartin Signed-off-by: James Bottomley Signed-off-by: Chris Wright

SPARC64: Fix FPU saving in 64-bit signal handling.

2008-04-19T01:53:28Z

Upstream commit: 7c3cce978e4f933ac13758ec5d2554fc8d0927d2 The calculation of the FPU reg save area pointer was wrong. Based upon an OOPS report from Tom Callaway. Signed-off-by: David S. Miller Signed-off-by: Chris Wright

SPARC64: flush_ptrace_access() needs preemption disable.

2008-04-19T01:53:27Z

Upstream commit: f6a843d939ade435e060d580f5c56d958464f8a5 Based upon a report by Mariusz Kozlowski. Signed-off-by: David S. Miller Signed-off-by: Chris Wright

SPARC64: Fix __get_cpu_var in preemption-enabled area.

2008-04-19T01:53:27Z

Upstream commit: 69072f6e8e4bd4799d2a54e4ff8771d0657512c1 Reported by Mariusz Kozlowski. Signed-off-by: David S. Miller Signed-off-by: Chris Wright

vmcoreinfo: add the symbol "phys_base"

2008-04-19T01:53:22Z

upstream commit: 629c8b4cdb354518308663aff2f719e02f69ffbe Fix the problem that makedumpfile sometimes fails on x86_64 machine. This patch adds the symbol "phys_base" to a vmcoreinfo data. The vmcoreinfo data has the minimum debugging information only for dump filtering. makedumpfile (dump filtering command) gets it to distinguish unnecessary pages, and makedumpfile creates a small dumpfile. On x86_64 kernel which compiled with CONFIG_PHYSICAL_START=0x0 and CONFIG_RELOCATABLE=y, makedumpfile fails like the following: # makedumpfile -d31 /proc/vmcore dumpfile The kernel version is not supported. The created dumpfile may be incomplete. _exclude_free_page: Can't get next online node. makedumpfile Failed. # The cause is the lack of the symbol "phys_base" in a vmcoreinfo data. If the symbol "phys_base" does not exist, makedumpfile considers an x86_64 kernel as non relocatable. As the result, makedumpfile misunderstands the physical address where the kernel is loaded, and it cannot translate a kernel virtual address to physical address correctly. To fix this problem, this patch adds the symbol "phys_base" to a vmcoreinfo data. Signed-off-by: Ken'ichi Ohmichi Cc: "Eric W. Biederman" Cc: Acked-by: Vivek Goyal Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

xen: fix UP setup of shared_info

2008-04-19T01:53:21Z

upstream commit: 2e8fe719b57bbdc9e313daed1204bb55fed3ed44 We need to set up the shared_info pointer once we've mapped the real shared_info into its fixmap slot. That needs to happen once the general pagetable setup has been done. Previously, the UP shared_info was set up one in xen_start_kernel, but that was left pointing to the dummy shared info. Unfortunately there's no really good place to do a later setup of the shared_info in UP, so just do it once the pagetable setup has been done. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Ingo Molnar [chrisw@sous-sol.org: backport to 2.6.24.4] Signed-off-by: Chris Wright

xen: mask out SEP from CPUID

2008-04-19T01:53:20Z

upstream commit: d40e705903397445c6861a0a56c23e5b2e8f9b9a Fix 32-on-64 pvops kernel: we don't want userspace using syscall/sysenter, even if the hypervisor supports it, so mask it out from CPUID. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright

xen: fix RMW when unmasking events

2008-04-19T01:53:20Z

upstream commit: 04c44a080d2f699a3042d4e743f7ad2ffae9d538 xen_irq_enable_direct and xen_sysexit were using "andw $0x00ff, XEN_vcpu_info_pending(vcpu)" to unmask events and test for pending ones in one instuction. Unfortunately, the pending flag must be modified with a locked operation since it can be set by another CPU, and the unlocked form of this operation was causing the pending flag to get lost, allowing the processor to return to usermode with pending events and ultimately deadlock. The simple fix would be to make it a locked operation, but that's rather costly and unnecessary. The fix here is to split the mask-clearing and pending-testing into two instructions; the interrupt window between them is of no concern because either way pending or new events will be processed. This should fix lingering bugs in using direct vcpu structure access too. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright