linux/arch, branch v2.6.25.10

x86: fix cpu hotplug crash

2008-07-03T03:46:16Z

Commit fcb43042ef55d2f46b0efa5d7746967cef38f056 upstream x86: fix cpu hotplug crash Vegard Nossum reported crashes during cpu hotplug tests: http://marc.info/?l=linux-kernel&m=121413950227884&w=4 In function _cpu_up, the panic happens when calling __raw_notifier_call_chain at the second time. Kernel doesn't panic when calling it at the first time. If just say because of nr_cpu_ids, that's not right. By checking the source code, I found that function do_boot_cpu is the culprit. Consider below call chain: _cpu_up=>__cpu_up=>smp_ops.cpu_up=>native_cpu_up=>do_boot_cpu. So do_boot_cpu is called in the end. In do_boot_cpu, if boot_error==true, cpu_clear(cpu, cpu_possible_map) is executed. So later on, when _cpu_up calls __raw_notifier_call_chain at the second time to report CPU_UP_CANCELED, because this cpu is already cleared from cpu_possible_map, get_cpu_sysdev returns NULL. Many resources are related to cpu_possible_map, so it's better not to change it. Below patch against 2.6.26-rc7 fixes it by removing the bit clearing in cpu_possible_map. Signed-off-by: Zhang Yanmin Tested-by: Vegard Nossum Acked-by: Rusty Russell Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

ptrace GET/SET FPXREGS broken

2008-07-03T03:46:16Z

Commit 11dbc963a8f6128595d0f6ecf138dc369e144997 upstream ptrace GET/SET FPXREGS broken When I update kernel 2.6.25 from 2.6.24, gdb does not work. On 2.6.25, ptrace(PTRACE_GETFPXREGS, ...) returns ENODEV. But 2.6.24 kernel's ptrace() returns EIO. It is issue of compatibility. I attached test program as pt.c and patch for fix it. #include #include #include #include #include #include #include struct user_fxsr_struct { unsigned short cwd; unsigned short swd; unsigned short twd; unsigned short fop; long fip; long fcs; long foo; long fos; long mxcsr; long reserved; long st_space[32]; /* 8*16 bytes for each FP-reg = 128 bytes */ long xmm_space[32]; /* 8*16 bytes for each XMM-reg = 128 bytes */ long padding[56]; }; int main(void) { pid_t pid; pid = fork(); switch(pid){ case -1:/* error */ break; case 0:/* child */ child(); break; default: parent(pid); break; } return 0; } int child(void) { ptrace(PTRACE_TRACEME); kill(getpid(), SIGSTOP); sleep(10); return 0; } int parent(pid_t pid) { int ret; struct user_fxsr_struct fpxregs; ret = ptrace(PTRACE_GETFPXREGS, pid, 0, &fpxregs); if(ret < 0){ printf("%d: %s.\n", errno, strerror(errno)); } kill(pid, SIGCONT); wait(pid); return 0; } /* in the kerel, at kernel/i387.c get_fpxregs() */ Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86_64 ptrace: fix sys32_ptrace task_struct leak

2008-07-03T03:46:15Z

Commit 5a4646a4efed8c835f76c3b88f3155f6ab5b8d9b introduced a leak of task_struct refs into sys32_ptrace. This bug has already gone away in for 2.6.26 in commit 562b80bafffaf42a6d916b0a2ee3d684220a1c10. Signed-off-by: Roland McGrath Acked-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: use BOOTMEM_EXCLUSIVE on 32-bit

2008-06-24T21:08:30Z

commit d3942cff620bea073fc4e3c8ed878eb1e84615ce upstream This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for i386 and prints a error message on failure. The patch is still for 2.6.26 since it is only bug fixing. The unification of reserve_crashkernel() between i386 and x86_64 should be done for 2.6.27. Signed-off-by: Bernhard Walle Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

Reinstate ZERO_PAGE optimization in 'get_user_pages()' and fix XIP

2008-06-24T21:08:29Z

commit 89f5b7da2a6bad2e84670422ab8192382a5aeb9f upstream KAMEZAWA Hiroyuki and Oleg Nesterov point out that since the commit 557ed1fa2620dc119adb86b34c614e152a629a80 ("remove ZERO_PAGE") removed the ZERO_PAGE from the VM mappings, any users of get_user_pages() will generally now populate the VM with real empty pages needlessly. We used to get the ZERO_PAGE when we did the "handle_mm_fault()", but since fault handling no longer uses ZERO_PAGE for new anonymous pages, we now need to handle that special case in follow_page() instead. In particular, the removal of ZERO_PAGE effectively removed the core file writing optimization where we would skip writing pages that had not been populated at all, and increased memory pressure a lot by allocating all those useless newly zeroed pages. This reinstates the optimization by making the unmapped PTE case the same as for a non-existent page table, which already did this correctly. While at it, this also fixes the XIP case for follow_page(), where the caller could not differentiate between the case of a page that simply could not be used (because it had no "struct page" associated with it) and a page that just wasn't mapped. We do that by simply returning an error pointer for pages that could not be turned into a "struct page *". The error is arbitrarily picked to be EFAULT, since that was what get_user_pages() already used for the equivalent IO-mapped page case. [ Also removed an impossible test for pte_offset_map_lock() failing: that's not how that function works ] Acked-by: Oleg Nesterov Acked-by: Nick Piggin Cc: KAMEZAWA Hiroyuki Cc: Hugh Dickins Cc: Andrew Morton Cc: Ingo Molnar Cc: Roland McGrath Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86: disable mwait for AMD family 10H/11H CPUs

2008-06-22T05:24:57Z

back-ported from upstream commit e9623b35599fcdbc00c16535cbefbb4d5578f4ab by Vegard Nossum The previous revert of 0c07ee38c9d4eb081758f5ad14bbffa7197e1aec left out the mwait disable condition for AMD family 10H/11H CPUs. Andreas Herrman said: It depends on the CPU. For AMD CPUs that support MWAIT this is wrong. Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings then depend on a clock divisor and current Pstate of the core. If all cores of a processor are in halt state (C1) the processor can enter the C1E (C1 enhanced) state. If mwait is used this will never happen. Thus HLT saves more power than MWAIT here. It might be best to switch off the mwait flag for these AMD CPU families like it was introduced with commit f039b754714a422959027cb18bb33760eb8153f0 (x86: Don't use MWAIT on AMD Family 10) Re-add the AMD families 10H/11H check and disable the mwait usage for those. Signed-off-by: Thomas Gleixner Signed-off-by: Vegard Nossum Cc: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: remove mwait capability C-state check

2008-06-22T05:24:57Z

back-ported from upstream commit a738d897b7b03b83488ae74a9bc03d26a2875dc6 by Vegard Nossum Vegard Nossum reports: | powertop shows between 200-400 wakeups/second with the description | ": Rescheduling interrupts" when all processors have load (e.g. | I need to run two busy-loops on my 2-CPU system for this to show up). | | The bisect resulted in this commit: | | commit 0c07ee38c9d4eb081758f5ad14bbffa7197e1aec | Date: Wed Jan 30 13:33:16 2008 +0100 | | x86: use the correct cpuid method to detect MWAIT support for C states remove the functional effects of this patch and make mwait unconditional. A future patch will turn off mwait on specific CPUs where that causes power to be wasted. Bisected-by: Vegard Nossum Tested-by: Vegard Nossum Signed-off-by: Ingo Molnar Signed-off-by: Vegard Nossum Signed-off-by: Greg Kroah-Hartman

x86-64: Fix "bytes left to copy" return value for copy_from_user()

2008-06-22T05:24:53Z

commit 42a886af728c089df8da1b0017b0e7e6c81b5335 upstream Most users by far do not care about the exact return value (they only really care about whether the copy succeeded in its entirety or not), but a few special core routines actually care deeply about exactly how many bytes were copied from user space. And the unrolled versions of the x86-64 user copy routines would sometimes report that it had copied more bytes than it actually had. Very few uses actually have partial copies to begin with, but to make this bug even harder to trigger, most x86 CPU's use the "rep string" instructions for normal user copies, and that version didn't have this issue. To make it even harder to hit, the one user of this that really cared about the return value (and used the uncached version of the copy that doesn't use the "rep string" instructions) was the generic write routine, which pre-populated its source, once more hiding the problem by avoiding the exception case that triggers the bug. In other words, very special thanks to Bron Gondwana who not only triggered this, but created a test-program to show it, and bisected the behavior down to commit 08291429cfa6258c4cd95d8833beb40f828b194e ("mm: fix pagecache write deadlocks") which changed the access pattern just enough that you can now trigger it with 'writev()' with multiple iovec's. That commit itself was not the cause of the bug, it just allowed all the stars to align just right that you could trigger the problem. [ Side note: this is just the minimal fix to make the copy routines (with __copy_from_user_inatomic_nocache as the particular version that was involved in showing this) have the right return values. We really should improve on the exceptional case further - to make the copy do a byte-accurate copy up to the exact page limit that causes it to fail. As it is, the callers have to do extra work to handle the limit case gracefully. ] Reported-by: Bron Gondwana Cc: Nick Piggin Cc: Andrew Morton Cc: Andi Kleen Cc: Al Viro Acked-by: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86: fix recursive dependencies

2008-06-16T20:20:06Z

commit 823c248e7cc75b4f22da914b01f8e5433cff197e in mainline The proper dependency check uncovered a few dependency problems, the subarchitecture used a mixture of selects and depends on SMP and PCI dependency was messed up. Signed-off-by: Roman Zippel Signed-off-by: Ingo Molnar Signed-off-by: Ravikiran Thirumalai

Kconfig: introduce ARCH_DEFCONFIG to DEFCONFIG_LIST

2008-06-16T20:20:05Z

commit 73531905ed53576d9e8707659a761e7046a60497 in mainline. init/Kconfig contains a list of configs that are searched for if 'make *config' are used with no .config present. Extend this list to look at the config identified by ARCH_DEFCONFIG. With this change we now try the defconfig targets last. This fixes a regression reported by: Linus Torvalds Signed-off-by: Sam Ravnborg Cc: Linus Torvalds Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Signed-off-by: Greg Kroah-Hartman