commit 76605033bb81028b4c603a324dcec6793b7da8ae Author: Greg Kroah-Hartman Date: Wed Jul 2 20:46:47 2008 -0700 Linux 2.6.25.10 commit 8ede7cd02adbd93b00f7097e38c7d3ee0c21f3f0 Author: Max Asbock Date: Mon Jun 30 18:17:09 2008 +0200 x86: shift bits the right way in native_read_tscp Commit 41aefdcc98fdba47459eab67630293d67e855fc3 upstream x86: shift bits the right way in native_read_tscp native_read_tscp shifts the bits in the high order value in the wrong direction, the attached patch fixes that. Signed-off-by: Max Asbock Acked-by: Glauber Costa Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 712a9da4d9f05a918152422bbc30b601f892b62c Author: Yanmin Zhang Date: Mon Jun 30 18:21:54 2008 +0200 x86: fix cpu hotplug crash 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 commit 66f100382995e2510e5bbae37ec4dbc4f73e4638 Author: TAKADA Yoshihito Date: Mon Jun 30 18:22:07 2008 +0200 ptrace GET/SET FPXREGS broken 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 commit 0758c2f30b75419fbe5e0ec6dfc892bbc0687f57 Author: Dmitry Adamushko Date: Mon Jun 30 18:22:34 2008 +0200 sched: fix cpu hotplug Commit 79c537998d143b127c8c662a403c3356cb885f1c upstream the CPU hotplug problems (crashes under high-volume unplug+replug tests) seem to be related to migrate_dead_tasks(). Firstly I added traces to see all tasks being migrated with migrate_live_tasks() and migrate_dead_tasks(). On my setup the problem pops up (the one with "se == NULL" in the loop of pick_next_task_fair()) shortly after the traces indicate that some has been migrated with migrate_dead_tasks()). btw., I can reproduce it much faster now with just a plain cpu down/up loop. [disclaimer] Well, unless I'm really missing something important in this late hour [/desclaimer] pick_next_task() is not something appropriate for migrate_dead_tasks() :-) the following change seems to eliminate the problem on my setup (although, I kept it running only for a few minutes to get a few messages indicating migrate_dead_tasks() does move tasks and the system is still ok) Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1e9a615bfce7996ea4d815d45d364b47ac6a74e8 Author: Roland McGrath Date: Fri Jun 27 13:48:29 2008 -0700 x86_64 ptrace: fix sys32_ptrace task_struct leak 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 commit 20dc9a897a736105af739346fd6517dec6142b5d Author: Jie Luo Date: Tue Jun 24 10:38:31 2008 -0700 DRM: enable bus mastering on i915 at resume time commit ea7b44c8e6baa1a4507f05ba2c0009ac21c3fe0b upstream On 9xx chips, bus mastering needs to be enabled at resume time for much of the chip to function. With this patch, vblank interrupts will work as expected on resume, along with other chip functions. Fixes kernel bugzilla #10844. Signed-off-by: Jie Luo Signed-off-by: Jesse Barnes Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6f139f638a58706d45e1219e7625ec39608115b2 Author: Eli Cohen Date: Mon Jun 23 23:30:09 2008 +0000 IB/mthca: Clear ICM pages before handing to FW commit 87afd448b186c885d67a08b7417cd46253b6a9d6 upstream Current memfree FW has a bug which in some cases, assumes that ICM pages passed to it are cleared. This patch uses __GFP_ZERO to allocate all ICM pages passed to the FW. Once firmware with a fix is released, we can make the workaround conditional on firmware version. This fixes the bug reported by Arthur Kepner here: http://lists.openfabrics.org/pipermail/general/2008-May/050026.html [ Rewritten to be a one-liner using __GFP_ZERO instead of vmap()ing ICM memory and memset()ing it to 0. - Roland ] Signed-off-by: Eli Cohen Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 935cfe235e825998eef8fd0673b1bd62fe4a85c2 Author: Thomas Gleixner Date: Mon Jun 23 23:30:13 2008 +0000 futexes: fix fault handling in futex_lock_pi commit 1b7558e457ed0de61023cfc913d2c342c7c3d9f2 upstream This patch addresses a very sporadic pi-futex related failure in highly threaded java apps on large SMP systems. David Holmes reported that the pi_state consistency check in lookup_pi_state triggered with his test application. This means that the kernel internal pi_state and the user space futex variable are out of sync. First we assumed that this is a user space data corruption, but deeper investigation revieled that the problem happend because the pi-futex code is not handling a fault in the futex_lock_pi path when the user space variable needs to be fixed up. The fault happens when a fork mapped the anon memory which contains the futex readonly for COW or the page got swapped out exactly between the unlock of the futex and the return of either the new futex owner or the task which was the expected owner but failed to acquire the kernel internal rtmutex. The current futex_lock_pi() code drops out with an inconsistent in case it faults and returns -EFAULT to user space. User space has no way to fixup that state. When we wrote this code we thought that we could not drop the hash bucket lock at this point to handle the fault. After analysing the code again it turned out to be wrong because there are only two tasks involved which might modify the pi_state and the user space variable: - the task which acquired the rtmutex - the pending owner of the pi_state which did not get the rtmutex Both tasks drop into the fixup_pi_state() function before returning to user space. The first task which acquired the hash bucket lock faults in the fixup of the user space variable, drops the spinlock and calls futex_handle_fault() to fault in the page. Now the second task could acquire the hash bucket lock and tries to fixup the user space variable as well. It either faults as well or it succeeds because the first task already faulted the page in. One caveat is to avoid a double fixup. After returning from the fault handling we reacquire the hash bucket lock and check whether the pi_state owner has been modified already. Reported-by: David Holmes Signed-off-by: Thomas Gleixner Cc: Andrew Morton Cc: David Holmes Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Peter Zijlstra Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2a739dd53ad7ee010ae6e155438507f329dce788 Author: Alan Cox Date: Fri Jun 27 15:21:55 2008 +0100 TTY: fix for tty operations bugs This is fixed with the recent tty operations rewrite in mainline in a different way, this is a selective backport of the relevant portions to the -stable tree. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman