commit eaa1ace05aaf4503589a3111a6f5401e85716d51 Author: Greg Kroah-Hartman Date: Mon Sep 20 13:38:16 2010 -0700 Linux 2.6.32.22 commit 6185dfa6d0aafb67732a1299867c72c56d6f69f3 Author: Chris Wilson Date: Thu Sep 9 09:41:32 2010 +0100 drm: Only decouple the old_fb from the crtc is we call mode_set* commit 356ad3cd616185631235ffb48b3efbf39f9923b3 upstream. Otherwise when disabling the output we switch to the new fb (which is likely NULL) and skip the call to mode_set -- leaking driver private state on the old_fb. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857 Reported-by: Sitsofe Wheeler Signed-off-by: Chris Wilson Cc: Dave Airlie Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit adae873370266265202de840d19650a0a8289cd1 Author: Chris Wilson Date: Mon Sep 6 16:17:22 2010 +0100 drm/i915: Prevent double dpms on commit 032d2a0d068b0368296a56469761394ef03207c3 upstream. Arguably this is a bug in drm-core in that we should not be called twice in succession with DPMS_ON, however this is still occuring and we see FDI link training failures on the second call leading to the occassional blank display. For the time being ignore the repeated call. Original patch by Dave Airlie Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 079908f18d73154f76b8abb656d63bfeda0e201f Author: Dan Carpenter Date: Wed Jun 23 19:03:01 2010 +0200 i915_gem: return -EFAULT if copy_to_user fails commit c877cdce93a44eea96f6cf7fc04be7d0372db2be upstream. copy_to_user() returns the number of bytes remaining to be copied and I'm pretty sure we want to return a negative error code here. Signed-off-by: Dan Carpenter Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 9cd74cb5174c58dd7165f8cd10897bd775a9a777 Author: Dan Carpenter Date: Sat Jun 19 15:12:51 2010 +0200 i915: return -EFAULT if copy_to_user fails commit 9927a403ca8c97798129953fa9cbb5dc259c7cb9 upstream. copy_to_user returns the number of bytes remaining to be copied, but we want to return a negative error code here. These are returned to userspace. Signed-off-by: Dan Carpenter Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit f7f040a6b088a9380a640b181687f7c79fface7b Author: Trond Myklebust Date: Sun Sep 12 19:55:25 2010 -0400 SUNRPC: Fix race corrupting rpc upcall commit 5a67657a2e90c9e4a48518f95d4ba7777aa20fbb upstream. If rpc_queue_upcall() adds a new upcall to the rpci->pipe list just after rpc_pipe_release calls rpc_purge_list(), but before it calls gss_pipe_release (as rpci->ops->release_pipe(inode)), then the latter will free a message without deleting it from the rpci->pipe list. We will be left with a freed object on the rpc->pipe list. Most frequent symptoms are kernel crashes in rpc.gssd system calls on the pipe in question. Reported-by: J. Bruce Fields Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 60804a1f4821f917c302fb1970674ab058473427 Author: Trond Myklebust Date: Sun Sep 12 19:55:26 2010 -0400 NFS: Fix a typo in nfs_sockaddr_match_ipaddr6 commit b20d37ca9561711c6a3c4b859c2855f49565e061 upstream. Reported-by: Ben Greear Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 198aa4b040aa00b4c9de5314da2338ff20ab1f73 Author: Anton Vorontsov Date: Wed Sep 8 00:10:26 2010 +0400 apm_power: Add missing break statement commit 1d220334d6a8a711149234dc5f98d34ae02226b8 upstream. The missing break statement causes wrong capacity calculation for batteries that report energy. Reported-by: d binderman Signed-off-by: Anton Vorontsov Signed-off-by: Greg Kroah-Hartman commit ebd5849e44b2a3fe939d9b5b36270ae6f8b727f9 Author: Guillem Jover Date: Fri Sep 17 17:24:12 2010 +0200 hwmon: (f75375s) Do not overwrite values read from registers commit c3b327d60bbba3f5ff8fd87d1efc0e95eb6c121b upstream. All bits in the values read from registers to be used for the next write were getting overwritten, avoid doing so to not mess with the current configuration. Signed-off-by: Guillem Jover Cc: Riku Voipio Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 2e999ac7a157b6fddb9bd5db8aff9188a9b458bb Author: Guillem Jover Date: Fri Sep 17 17:24:11 2010 +0200 hwmon: (f75375s) Shift control mode to the correct bit position commit 96f3640894012be7dd15a384566bfdc18297bc6c upstream. The spec notes that fan0 and fan1 control mode bits are located in bits 7-6 and 5-4 respectively, but the FAN_CTRL_MODE macro was making the bits shift by 5 instead of by 4. Signed-off-by: Guillem Jover Cc: Riku Voipio Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit ef8deb2ab7fab4ece05954512e66a93a94a51734 Author: Al Viro Date: Fri Sep 17 14:34:39 2010 +0100 arm: fix really nasty sigreturn bug commit 653d48b22166db2d8b1515ebe6f9f0f7c95dfc86 upstream. If a signal hits us outside of a syscall and another gets delivered when we are in sigreturn (e.g. because it had been in sa_mask for the first one and got sent to us while we'd been in the first handler), we have a chance of returning from the second handler to location one insn prior to where we ought to return. If r0 happens to contain -513 (-ERESTARTNOINTR), sigreturn will get confused into doing restart syscall song and dance. Incredible joy to debug, since it manifests as random, infrequent and very hard to reproduce double execution of instructions in userland code... The fix is simple - mark it "don't bother with restarts" in wrapper, i.e. set r8 to 0 in sys_sigreturn and sys_rt_sigreturn wrappers, suppressing the syscall restart handling on return from these guys. They can't legitimately return a restart-worthy error anyway. Testcase: #include #include #include #include #include void f(int n) { __asm__ __volatile__( "ldr r0, [%0]\n" "b 1f\n" "b 2f\n" "1:b .\n" "2:\n" : : "r"(&n)); } void handler1(int sig) { } void handler2(int sig) { raise(1); } void handler3(int sig) { exit(0); } main() { struct sigaction s = {.sa_handler = handler2}; struct itimerval t1 = { .it_value = {1} }; struct itimerval t2 = { .it_value = {2} }; signal(1, handler1); sigemptyset(&s.sa_mask); sigaddset(&s.sa_mask, 1); sigaction(SIGALRM, &s, NULL); signal(SIGVTALRM, handler3); setitimer(ITIMER_REAL, &t1, NULL); setitimer(ITIMER_VIRTUAL, &t2, NULL); f(-513); /* -ERESTARTNOINTR */ write(1, "buggered\n", 9); return 1; } Signed-off-by: Al Viro Acked-by: Russell King Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 86ea76f341725b3860d93df229fa136aa702c80e Author: Takashi Iwai Date: Fri Jul 30 14:08:25 2010 +0200 ALSA: hda - Handle pin NID 0x1a on ALC259/269 commit b08b1637ce1c0196970348bcabf40f04b6b3d58e upstream. The pin NID 0x1a should be handled as well as NID 0x1b. Also added comments. Signed-off-by: Takashi Iwai Cc: David Henningsson Signed-off-by: Greg Kroah-Hartman commit 98984831cfa25878839b44a626c561ec5b4c3cb8 Author: Takashi Iwai Date: Fri Jul 30 10:51:10 2010 +0200 ALSA: hda - Handle missing NID 0x1b on ALC259 codec commit 5d4abf93ea3192cc666430225a29a4978c97c57d upstream. Since ALC259/269 use the same parser of ALC268, the pin 0x1b was ignored as an invalid widget. Just add this NID to handle properly. This will add the missing mixer controls for some devices. Signed-off-by: Takashi Iwai Cc: David Henningsson Signed-off-by: Greg Kroah-Hartman commit 277899ef0a356b3c0434d6cc0953aa06b74dde53 Author: Anton Blanchard Date: Tue Feb 2 14:46:13 2010 -0800 sched: cpuacct: Use bigger percpu counter batch values for stats counters commit fa535a77bd3fa32b9215ba375d6a202fe73e1dd6 upstream When CONFIG_VIRT_CPU_ACCOUNTING and CONFIG_CGROUP_CPUACCT are enabled we can call cpuacct_update_stats with values much larger than percpu_counter_batch. This means the call to percpu_counter_add will always add to the global count which is protected by a spinlock and we end up with a global spinlock in the scheduler. Based on an idea by KOSAKI Motohiro, this patch scales the batch value by cputime_one_jiffy such that we have the same batch limit as we would if CONFIG_VIRT_CPU_ACCOUNTING was disabled. His patch did this once at boot but that initialisation happened too early on PowerPC (before time_init) and it was never updated at runtime as a result of a hotplug cpu add/remove. This patch instead scales percpu_counter_batch by cputime_one_jiffy at runtime, which keeps the batch correct even after cpu hotplug operations. We cap it at INT_MAX in case of overflow. For architectures that do not support CONFIG_VIRT_CPU_ACCOUNTING, cputime_one_jiffy is the constant 1 and gcc is smart enough to optimise min(s32 percpu_counter_batch, INT_MAX) to just percpu_counter_batch at least on x86 and PowerPC. So there is no need to add an #ifdef. On a 64 thread PowerPC box with CONFIG_VIRT_CPU_ACCOUNTING and CONFIG_CGROUP_CPUACCT enabled, a context switch microbenchmark is 234x faster and almost matches a CONFIG_CGROUP_CPUACCT disabled kernel: CONFIG_CGROUP_CPUACCT disabled: 16906698 ctx switches/sec CONFIG_CGROUP_CPUACCT enabled: 61720 ctx switches/sec CONFIG_CGROUP_CPUACCT + patch: 16663217 ctx switches/sec Tested with: wget http://ozlabs.org/~anton/junkcode/context_switch.c make context_switch for i in `seq 0 63`; do taskset -c $i ./context_switch & done vmstat 1 Signed-off-by: Anton Blanchard Reviewed-by: KOSAKI Motohiro Acked-by: Balbir Singh Tested-by: Balbir Singh Cc: Peter Zijlstra Cc: Martin Schwidefsky Cc: Tony Luck Signed-off-by: Andrew Morton Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 337a01799916217f16d5eec290c465465d7570fe Author: Suresh Siddha Date: Wed Mar 31 16:47:45 2010 -0700 sched: Fix select_idle_sibling() logic in select_task_rq_fair() commit 99bd5e2f245d8cd17d040c82d40becdb3efd9b69 upstream Issues in the current select_idle_sibling() logic in select_task_rq_fair() in the context of a task wake-up: a) Once we select the idle sibling, we use that domain (spanning the cpu that the task is currently woken-up and the idle sibling that we found) in our wake_affine() decisions. This domain is completely different from the domain(we are supposed to use) that spans the cpu that the task currently woken-up and the cpu where the task previously ran. b) We do select_idle_sibling() check only for the cpu that the task is currently woken-up on. If select_task_rq_fair() selects the previously run cpu for waking the task, doing a select_idle_sibling() check for that cpu also helps and we don't do this currently. c) In the scenarios where the cpu that the task is woken-up is busy but with its HT siblings are idle, we are selecting the task be woken-up on the idle HT sibling instead of a core that it previously ran and currently completely idle. i.e., we are not taking decisions based on wake_affine() but directly selecting an idle sibling that can cause an imbalance at the SMT/MC level which will be later corrected by the periodic load balancer. Fix this by first going through the load imbalance calculations using wake_affine() and once we make a decision of woken-up cpu vs previously-ran cpu, then choose a possible idle sibling for waking up the task on. Signed-off-by: Suresh Siddha Signed-off-by: Peter Zijlstra LKML-Reference: <1270079265.7835.8.camel@sbs-t61.sc.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 6efd9bbce0d4b02d295f28054caa74e6edf811b7 Author: Peter Zijlstra Date: Fri Apr 16 14:59:29 2010 +0200 sched: Pre-compute cpumask_weight(sched_domain_span(sd)) commit 669c55e9f99b90e46eaa0f98a67ec53d46dc969a upstream Dave reported that his large SPARC machines spend lots of time in hweight64(), try and optimize some of those needless cpumask_weight() invocations (esp. with the large offstack cpumasks these are very expensive indeed). Reported-by: David Miller Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit ac8f51da79873b84461e77ee2b19d02a253add3e Author: Mike Galbraith Date: Thu Mar 11 17:17:16 2010 +0100 sched: Fix select_idle_sibling() commit 8b911acdf08477c059d1c36c21113ab1696c612b upstream Don't bother with selection when the current cpu is idle. Recent load balancing changes also make it no longer necessary to check wake_affine() success before returning the selected sibling, so we now always use it. Signed-off-by: Mike Galbraith Signed-off-by: Peter Zijlstra LKML-Reference: <1268301369.6785.36.camel@marge.simson.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b971284b4af79650f4d7f4caae21c824be3dd7fb Author: Mike Galbraith Date: Mon Jan 4 14:44:56 2010 +0100 sched: Fix vmark regression on big machines commit 50b926e439620c469565e8be0f28be78f5fca1ce upstream SD_PREFER_SIBLING is set at the CPU domain level if power saving isn't enabled, leading to many cache misses on large machines as we traverse looking for an idle shared cache to wake to. Change the enabler of select_idle_sibling() to SD_SHARE_PKG_RESOURCES, and enable same at the sibling domain level. Reported-by: Lin Ming Signed-off-by: Mike Galbraith Signed-off-by: Peter Zijlstra LKML-Reference: <1262612696.15495.15.camel@marge.simson.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 81c8021a88266324db40cb2e6691fc5ddc67034a Author: Peter Zijlstra Date: Thu Nov 12 15:55:29 2009 +0100 sched: More generic WAKE_AFFINE vs select_idle_sibling() commit fe3bcfe1f6c1fc4ea7706ac2d05e579fd9092682 upstream Instead of only considering SD_WAKE_AFFINE | SD_PREFER_SIBLING domains also allow all SD_PREFER_SIBLING domains below a SD_WAKE_AFFINE domain to change the affinity target. Signed-off-by: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091112145610.909723612@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 505afcbd47a8588251409191dddd7f888b555c6f Author: Peter Zijlstra Date: Thu Nov 12 15:55:28 2009 +0100 sched: Cleanup select_task_rq_fair() commit a50bde5130f65733142b32975616427d0ea50856 upstream Clean up the new affine to idle sibling bits while trying to grok them. Should not have any function differences. Signed-off-by: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091112145610.832503781@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 0b88f2ba7caa2d0ff6e3521481a82be084ecdc7b Author: Daniel J Blueman Date: Tue Jun 1 14:06:13 2010 +0100 sched: apply RCU protection to wake_affine() commit f3b577dec1f2ce32d2db6d2ca6badff7002512af upstream The task_group() function returns a pointer that must be protected by either RCU, the ->alloc_lock, or the cgroup lock (see the rcu_dereference_check() in task_subsys_state(), which is invoked by task_group()). The wake_affine() function currently does none of these, which means that a concurrent update would be within its rights to free the structure returned by task_group(). Because wake_affine() uses this structure only to compute load-balancing heuristics, there is no reason to acquire either of the two locks. Therefore, this commit introduces an RCU read-side critical section that starts before the first call to task_group() and ends after the last use of the "tg" pointer returned from task_group(). Thanks to Li Zefan for pointing out the need to extend the RCU read-side critical section from that proposed by the original patch. Signed-off-by: Daniel J Blueman Signed-off-by: Paul E. McKenney Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 58e9934fe305f5c2caeb252cfc478c9111841d6f Author: Peter Zijlstra Date: Tue Dec 1 12:21:47 2009 +0100 sched: Remove unnecessary RCU exclusion commit fb58bac5c75bfff8bbf7d02071a10a62f32fe28b upstream As Nick pointed out, and realized by myself when doing: sched: Fix balance vs hotplug race the patch: sched: for_each_domain() vs RCU is wrong, sched_domains are freed after synchronize_sched(), which means disabling preemption is enough. Reported-by: Nick Piggin Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 6c55d19c1d235c267b151d1d6e55a9d6fd5b5161 Author: Peter Zijlstra Date: Thu Aug 19 13:31:43 2010 +0200 sched: Fix rq->clock synchronization when migrating tasks commit 861d034ee814917a83bd5de4b26e3b8336ddeeb8 upstream sched_fork() -- we do task placement in ->task_fork_fair() ensure we update_rq_clock() so we work with current time. We leave the vruntime in relative state, so the time delay until wake_up_new_task() doesn't matter. wake_up_new_task() -- Since task_fork_fair() left p->vruntime in relative state we can safely migrate, the activate_task() on the remote rq will call update_rq_clock() and causes the clock to be synced (enough). Tested-by: Jack Daniel Tested-by: Philby John Signed-off-by: Peter Zijlstra LKML-Reference: <1281002322.1923.1708.camel@laptop> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit bea226b8e646ddb0bd262fc666b741134b9e9612 Author: Peter Zijlstra Date: Fri Mar 26 12:22:14 2010 +0100 sched: Fix nr_uninterruptible count commit cc87f76a601d2d256118f7bab15e35254356ae21 upstream The cpuload calculation in calc_load_account_active() assumes rq->nr_uninterruptible will not change on an offline cpu after migrate_nr_uninterruptible(). However the recent migrate on wakeup changes broke that and would result in decrementing the offline cpu's rq->nr_uninterruptible. Fix this by accounting the nr_uninterruptible on the waking cpu. Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 6975fc131cbca470ddabd070c911a94aaad75ea3 Author: Peter Zijlstra Date: Thu Mar 25 21:05:16 2010 +0100 sched: Optimize task_rq_lock() commit 65cc8e4859ff29a9ddc989c88557d6059834c2a2 upstream Now that we hold the rq->lock over set_task_cpu() again, we can do away with most of the TASK_WAKING checks and reduce them again to set_cpus_allowed_ptr(). Removes some conditionals from scheduling hot-paths. Signed-off-by: Peter Zijlstra Cc: Oleg Nesterov LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 6d94134f5f3f8bede26d4f700e17154d590d6d6e Author: Peter Zijlstra Date: Wed Mar 24 18:34:10 2010 +0100 sched: Fix TASK_WAKING vs fork deadlock commit 0017d735092844118bef006696a750a0e4ef6ebd upstream Oleg noticed a few races with the TASK_WAKING usage on fork. - since TASK_WAKING is basically a spinlock, it should be IRQ safe - since we set TASK_WAKING (*) without holding rq->lock it could be there still is a rq->lock holder, thereby not actually providing full serialization. (*) in fact we clear PF_STARTING, which in effect enables TASK_WAKING. Cure the second issue by not setting TASK_WAKING in sched_fork(), but only temporarily in wake_up_new_task() while calling select_task_rq(). Cure the first by holding rq->lock around the select_task_rq() call, this will disable IRQs, this however requires that we push down the rq->lock release into select_task_rq_fair()'s cgroup stuff. Because select_task_rq_fair() still needs to drop the rq->lock we cannot fully get rid of TASK_WAKING. Reported-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 81695bf0ee1a6b3f2a8f183273d945decc1d3f18 Author: Oleg Nesterov Date: Mon Mar 15 10:10:27 2010 +0100 sched: Make select_fallback_rq() cpuset friendly commit 9084bb8246ea935b98320554229e2f371f7f52fa upstream Introduce cpuset_cpus_allowed_fallback() helper to fix the cpuset problems with select_fallback_rq(). It can be called from any context and can't use any cpuset locks including task_lock(). It is called when the task doesn't have online cpus in ->cpus_allowed but ttwu/etc must be able to find a suitable cpu. I am not proud of this patch. Everything which needs such a fat comment can't be good even if correct. But I'd prefer to not change the locking rules in the code I hardly understand, and in any case I believe this simple change make the code much more correct compared to deadlocks we currently have. Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091027.GA9155@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 1ccc5a299bd54b1c0f0bac6316c45b6ce31b9ac1 Author: Oleg Nesterov Date: Mon Mar 15 10:10:23 2010 +0100 sched: _cpu_down(): Don't play with current->cpus_allowed commit 6a1bdc1b577ebcb65f6603c57f8347309bc4ab13 upstream _cpu_down() changes the current task's affinity and then recovers it at the end. The problems are well known: we can't restore old_allowed if it was bound to the now-dead-cpu, and we can race with the userspace which can change cpu-affinity during unplug. _cpu_down() should not play with current->cpus_allowed at all. Instead, take_cpu_down() can migrate the caller of _cpu_down() after __cpu_disable() removes the dying cpu from cpu_online_mask. Signed-off-by: Oleg Nesterov Acked-by: Rafael J. Wysocki Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091023.GA9148@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit cc28db464250bd240299431cc4fd7b7d58b205d2 Author: Oleg Nesterov Date: Mon Mar 15 10:10:19 2010 +0100 sched: sched_exec(): Remove the select_fallback_rq() logic commit 30da688ef6b76e01969b00608202fff1eed2accc upstream. sched_exec()->select_task_rq() reads/updates ->cpus_allowed lockless. This can race with other CPUs updating our ->cpus_allowed, and this looks meaningless to me. The task is current and running, it must have online cpus in ->cpus_allowed, the fallback mode is bogus. And, if ->sched_class returns the "wrong" cpu, this likely means we raced with set_cpus_allowed() which was called for reason, why should sched_exec() retry and call ->select_task_rq() again? Change the code to call sched_class->select_task_rq() directly and do nothing if the returned cpu is wrong after re-checking under rq->lock. From now task_struct->cpus_allowed is always stable under TASK_WAKING, select_fallback_rq() is always called under rq-lock or the caller or the caller owns TASK_WAKING (select_task_rq). Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091019.GA9141@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 79d79c4fed3589210367b57385048acb4caed77b Author: Oleg Nesterov Date: Mon Mar 15 10:10:14 2010 +0100 sched: move_task_off_dead_cpu(): Remove retry logic commit c1804d547dc098363443667609c272d1e4d15ee8 upstream The previous patch preserved the retry logic, but it looks unneeded. __migrate_task() can only fail if we raced with migration after we dropped the lock, but in this case the caller of set_cpus_allowed/etc must initiate migration itself if ->on_rq == T. We already fixed p->cpus_allowed, the changes in active/online masks must be visible to racer, it should migrate the task to online cpu correctly. Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091014.GA9138@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 296a3f11b1fde27d662e52f47fda1d35adc8f0b2 Author: Oleg Nesterov Date: Mon Mar 15 10:10:10 2010 +0100 sched: move_task_off_dead_cpu(): Take rq->lock around select_fallback_rq() commit 1445c08d06c5594895b4fae952ef8a457e89c390 upstream move_task_off_dead_cpu()->select_fallback_rq() reads/updates ->cpus_allowed lockless. We can race with set_cpus_allowed() running in parallel. Change it to take rq->lock around select_fallback_rq(). Note that it is not trivial to move this spin_lock() into select_fallback_rq(), we must recheck the task was not migrated after we take the lock and other callers do not need this lock. To avoid the races with other callers of select_fallback_rq() which rely on TASK_WAKING, we also check p->state != TASK_WAKING and do nothing otherwise. The owner of TASK_WAKING must update ->cpus_allowed and choose the correct CPU anyway, and the subsequent __migrate_task() is just meaningless because p->se.on_rq must be false. Alternatively, we could change select_task_rq() to take rq->lock right after it calls sched_class->select_task_rq(), but this looks a bit ugly. Also, change it to not assume irqs are disabled and absorb __migrate_task_irq(). Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091010.GA9131@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit e624a13a60b662d7137fd093c17fd4aa077e1e59 Author: Oleg Nesterov Date: Mon Mar 15 10:10:03 2010 +0100 sched: Kill the broken and deadlockable cpuset_lock/cpuset_cpus_allowed_locked code commit 897f0b3c3ff40b443c84e271bef19bd6ae885195 upstream This patch just states the fact the cpusets/cpuhotplug interaction is broken and removes the deadlockable code which only pretends to work. - cpuset_lock() doesn't really work. It is needed for cpuset_cpus_allowed_locked() but we can't take this lock in try_to_wake_up()->select_fallback_rq() path. - cpuset_lock() is deadlockable. Suppose that a task T bound to CPU takes callback_mutex. If cpu_down(CPU) happens before T drops callback_mutex stop_machine() preempts T, then migration_call(CPU_DEAD) tries to take cpuset_lock() and hangs forever because CPU is already dead and thus T can't be scheduled. - cpuset_cpus_allowed_locked() is deadlockable too. It takes task_lock() which is not irq-safe, but try_to_wake_up() can be called from irq. Kill them, and change select_fallback_rq() to use cpu_possible_mask, like we currently do without CONFIG_CPUSETS. Also, with or without this patch, with or without CONFIG_CPUSETS, the callers of select_fallback_rq() can race with each other or with set_cpus_allowed() pathes. The subsequent patches try to to fix these problems. Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100315091003.GA9123@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 20b622cd1f1a7f557f1587524c75e72f10d8193e Author: Oleg Nesterov Date: Tue Mar 30 18:58:29 2010 +0200 sched: set_cpus_allowed_ptr(): Don't use rq->migration_thread after unlock commit 47a70985e5c093ae03d8ccf633c70a93761d86f2 upstream Trivial typo fix. rq->migration_thread can be NULL after task_rq_unlock(), this is why we have "mt" which should be used instead. Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra LKML-Reference: <20100330165829.GA18284@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 4b3d9e7ce5a9e6409df1512127feb9973df1ea57 Author: Thomas Gleixner Date: Wed Jan 20 20:59:06 2010 +0000 sched: Queue a deboosted task to the head of the RT prio queue commit 60db48cacb9b253d5607a5ff206112a59cd09e34 upstream rtmutex_set_prio() is used to implement priority inheritance for futexes. When a task is deboosted it gets enqueued at the tail of its RT priority list. This is violating the POSIX scheduling semantics: rt priority list X contains two runnable tasks A and B task A runs with priority X and holds mutex M task C preempts A and is blocked on mutex M -> task A is boosted to priority of task C (Y) task A unlocks the mutex M and deboosts itself -> A is dequeued from rt priority list Y -> A is enqueued to the tail of rt priority list X task C schedules away task B runs This is wrong as task A did not schedule away and therefor violates the POSIX scheduling semantics. Enqueue the task to the head of the priority list instead. Reported-by: Mathias Weber Reported-by: Carsten Emde Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra Tested-by: Carsten Emde Tested-by: Mathias Weber LKML-Reference: <20100120171629.809074113@linutronix.de> Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit afc0109e65ee79cf7bd868e8fe98ac60b4d8f09e Author: Thomas Gleixner Date: Wed Jan 20 20:59:01 2010 +0000 sched: Implement head queueing for sched_rt commit 37dad3fce97f01e5149d69de0833d8452c0e862e upstream The ability of enqueueing a task to the head of a SCHED_FIFO priority list is required to fix some violations of POSIX scheduling policy. Implement the functionality in sched_rt. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra Tested-by: Carsten Emde Tested-by: Mathias Weber LKML-Reference: <20100120171629.772169931@linutronix.de> Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit e788d930654fba9a7ce346aebcefa3bf379d8599 Author: Thomas Gleixner Date: Wed Jan 20 20:58:57 2010 +0000 sched: Extend enqueue_task to allow head queueing commit ea87bb7853168434f4a82426dd1ea8421f9e604d upstream The ability of enqueueing a task to the head of a SCHED_FIFO priority list is required to fix some violations of POSIX scheduling policy. Extend the related functions with a "head" argument. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra Tested-by: Carsten Emde Tested-by: Mathias Weber LKML-Reference: <20100120171629.734886007@linutronix.de> Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 7607da8d4639cea9d7282c00e4fc1b288fcaa90f Author: Peter Zijlstra Date: Mon Feb 15 14:45:54 2010 +0100 sched: Fix race between ttwu() and task_rq_lock() commit 0970d2992dfd7d5ec2c787417cf464f01eeaf42a upstream Thomas found that due to ttwu() changing a task's cpu without holding the rq->lock, task_rq_lock() might end up locking the wrong rq. Avoid this by serializing against TASK_WAKING. Reported-by: Thomas Gleixner Signed-off-by: Peter Zijlstra LKML-Reference: <1266241712.15770.420.camel@laptop> Signed-off-by: Thomas Gleixner Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit c8035d9f08c1c8bbfe04576dbebe5c6da5621dae Author: Peter Zijlstra Date: Thu Jan 21 16:34:27 2010 +0100 sched: Fix incorrect sanity check commit 11854247e2c851e7ff9ce138e501c6cffc5a4217 upstream We moved to migrate on wakeup, which means that sleeping tasks could still be present on offline cpus. Amend the check to only test running tasks. Reported-by: Heiko Carstens Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 20f95b412b7fa9ecd93bda4d34a88bd159ffca8f Author: Peter Zijlstra Date: Thu Jan 21 21:04:57 2010 +0100 sched: Fix fork vs hotplug vs cpuset namespaces commit fabf318e5e4bda0aca2b0d617b191884fda62703 upstream There are a number of issues: 1) TASK_WAKING vs cgroup_clone (cpusets) copy_process(): sched_fork() child->state = TASK_WAKING; /* waiting for wake_up_new_task() */ if (current->nsproxy != p->nsproxy) ns_cgroup_clone() cgroup_clone() mutex_lock(inode->i_mutex) mutex_lock(cgroup_mutex) cgroup_attach_task() ss->can_attach() ss->attach() [ -> cpuset_attach() ] cpuset_attach_task() set_cpus_allowed_ptr(); while (child->state == TASK_WAKING) cpu_relax(); will deadlock the system. 2) cgroup_clone (cpusets) vs copy_process So even if the above would work we still have: copy_process(): if (current->nsproxy != p->nsproxy) ns_cgroup_clone() cgroup_clone() mutex_lock(inode->i_mutex) mutex_lock(cgroup_mutex) cgroup_attach_task() ss->can_attach() ss->attach() [ -> cpuset_attach() ] cpuset_attach_task() set_cpus_allowed_ptr(); ... p->cpus_allowed = current->cpus_allowed over-writing the modified cpus_allowed. 3) fork() vs hotplug if we unplug the child's cpu after the sanity check when the child gets attached to the task_list but before wake_up_new_task() shit will meet with fan. Solve all these issues by moving fork cpu selection into wake_up_new_task(). Reported-by: Serge E. Hallyn Tested-by: Serge E. Hallyn Signed-off-by: Peter Zijlstra LKML-Reference: <1264106190.4283.1314.camel@laptop> Signed-off-by: Thomas Gleixner Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 05e067a973d46e3c5348050b99c23c0584732b48 Author: Peter Zijlstra Date: Sun Dec 20 17:36:27 2009 +0100 sched: Fix hotplug hang commit 70f1120527797adb31c68bdc6f1b45e182c342c7 upstream The hot-unplug kstopmachine usage does a wakeup after deactivating the cpu, hence we cannot use cpu_active() here but must rely on the good olde online. Reported-by: Sachin Sant Reported-by: Jens Axboe Signed-off-by: Peter Zijlstra Tested-by: Jens Axboe Cc: Heiko Carstens Cc: Benjamin Herrenschmidt LKML-Reference: <1261326987.4314.24.camel@laptop> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 54a2695e9fde1b206ad0810908c5830785f08d11 Author: Peter Zijlstra Date: Wed Dec 16 18:04:41 2009 +0100 sched: Remove the cfs_rq dependency from set_task_cpu() commit 88ec22d3edb72b261f8628226cd543589a6d5e1b upstream In order to remove the cfs_rq dependency from set_task_cpu() we need to ensure the task is cfs_rq invariant for all callsites. The simple approach is to substract cfs_rq->min_vruntime from se->vruntime on dequeue, and add cfs_rq->min_vruntime on enqueue. However, this has the downside of breaking FAIR_SLEEPERS since we loose the old vruntime as we only maintain the relative position. To solve this, we observe that we only migrate runnable tasks, we do this using deactivate_task(.sleep=0) and activate_task(.wakeup=0), therefore we can restrain the min_vruntime invariance to that state. The only other case is wakeup balancing, since we want to maintain the old vruntime we cannot make it relative on dequeue, but since we don't migrate inactive tasks, we can do so right before we activate it again. This is where we need the new pre-wakeup hook, we need to call this while still holding the old rq->lock. We could fold it into ->select_task_rq(), but since that has multiple callsites and would obfuscate the locking requirements, that seems like a fudge. This leaves the fork() case, simply make sure that ->task_fork() leaves the ->vruntime in a relative state. This covers all cases where set_task_cpu() gets called, and ensures it sees a relative vruntime. Signed-off-by: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091216170518.191697025@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 668530636f48a49fc62ca256ea979d7b6e8a94ec Author: Peter Zijlstra Date: Wed Dec 16 18:04:40 2009 +0100 sched: Add pre and post wakeup hooks commit efbbd05a595343a413964ad85a2ad359b7b7efbd upstream As will be apparent in the next patch, we need a pre wakeup hook for sched_fair task migration, hence rename the post wakeup hook and one pre wakeup. Signed-off-by: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091216170518.114746117@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit ca6d844e585ec4dd254e7dd70fd648ab3b490a63 Author: Peter Zijlstra Date: Wed Dec 16 18:04:38 2009 +0100 sched: Fix select_task_rq() vs hotplug issues commit 5da9a0fb673a0ea0a093862f95f6b89b3390c31e upstream Since select_task_rq() is now responsible for guaranteeing ->cpus_allowed and cpu_active_mask, we need to verify this. select_task_rq_rt() can blindly return smp_processor_id()/task_cpu() without checking the valid masks, select_task_rq_fair() can do the same in the rare case that all SD_flags are disabled. Signed-off-by: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091216170517.961475466@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 31a9936c6fc4dafede228a762e3ebf22d6f4ae3c Author: Peter Zijlstra Date: Wed Dec 16 18:04:37 2009 +0100 sched: Fix sched_exec() balancing commit 3802290628348674985d14914f9bfee7b9084548 upstream sched: Fix sched_exec() balancing Since we access ->cpus_allowed without holding rq->lock we need a retry loop to validate the result, this comes for near free when we merge sched_migrate_task() into sched_exec() since that already does the needed check. Signed-off-by: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091216170517.884743662@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 9f2243e5817e778ebb95101722492937b845d8c9 Author: Peter Zijlstra Date: Thu Dec 17 13:16:31 2009 +0100 sched: Fix broken assertion commit 077614ee1e93245a3b9a4e1213659405dbeb0ba6 upstream There's a preemption race in the set_task_cpu() debug check in that when we get preempted after setting task->state we'd still be on the rq proper, but fail the test. Check for preempted tasks, since those are always on the RQ. Signed-off-by: Peter Zijlstra LKML-Reference: <20091217121830.137155561@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 07ad01064059aa5ac2e174ba519cd6a0c43301fa Author: Ingo Molnar Date: Thu Dec 17 06:05:49 2009 +0100 sched: Make warning less noisy commit 416eb39556a03d1c7e52b0791e9052ccd71db241 upstream Cc: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091216170517.807938893@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 854c98401284a312d28f3115954ce8965f437df1 Author: Peter Zijlstra Date: Wed Dec 16 18:04:36 2009 +0100 sched: Ensure set_task_cpu() is never called on blocked tasks commit e2912009fb7b715728311b0d8fe327a1432b3f79 upstream In order to clean up the set_task_cpu() rq dependencies we need to ensure it is never called on blocked tasks because such usage does not pair with consistent rq->lock usage. This puts the migration burden on ttwu(). Furthermore we need to close a race against changing ->cpus_allowed, since select_task_rq() runs with only preemption disabled. For sched_fork() this is safe because the child isn't in the tasklist yet, for wakeup we fix this by synchronizing set_cpus_allowed_ptr() against TASK_WAKING, which leaves sched_exec to be a problem This also closes a hole in (6ad4c1888 sched: Fix balance vs hotplug race) where ->select_task_rq() doesn't validate the result against the sched_domain/root_domain. Signed-off-by: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091216170517.807938893@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 9afee77b0c1a234006146b1d09a87c1c0216201d Author: Peter Zijlstra Date: Wed Dec 16 18:04:35 2009 +0100 sched: Use TASK_WAKING for fork wakups commit 06b83b5fbea273672822b6ee93e16781046553ec upstream For later convenience use TASK_WAKING for fresh tasks. Signed-off-by: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091216170517.732561278@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 4ec349b128a038e9011b56843ee86e44e356987e Author: Xiaotian Feng Date: Wed Dec 16 18:04:32 2009 +0100 sched: Fix set_cpu_active() in cpu_down() commit 9ee349ad6d326df3633d43f54202427295999c47 upstream Sachin found cpu hotplug test failures on powerpc, which made the kernel hang on his POWER box. The problem is that we fail to re-activate a cpu when a hot-unplug fails. Fix this by moving the de-activation into _cpu_down after doing the initial checks. Remove the synchronize_sched() calls and rely on those implied by rebuilding the sched domains using the new mask. Reported-by: Sachin Sant Signed-off-by: Xiaotian Feng Tested-by: Sachin Sant Signed-off-by: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: <20091216170517.500272612@chello.nl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 62d4f155288b1c3524a6493341bc80d98dce11c5 Author: Thomas Gleixner Date: Wed Dec 9 10:15:11 2009 +0000 sched: Use rcu in sched_get_rr_param() commit 1a551ae715825bb2a2107a2dd68de024a1fa4e32 upstream read_lock(&tasklist_lock) does not protect sys_sched_get_rr_param() against a concurrent update of the policy or scheduler parameters as do_sched_scheduler() does not take the tasklist_lock. The access to task->sched_class->get_rr_interval is protected by task_rq_lock(task). Use rcu_read_lock() to protect find_task_by_vpid() and prevent the task struct from going away. Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra LKML-Reference: <20091209100706.862897167@linutronix.de> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit b507f4cadeaf2fb3218d84f7f853535518103f50 Author: Thomas Gleixner Date: Wed Dec 9 10:15:01 2009 +0000 sched: Use rcu in sched_get/set_affinity() commit 23f5d142519621b16cf2b378cf8adf4dcf01a616 upstream tasklist_lock is held read locked to protect the find_task_by_vpid() call and to prevent the task going away. sched_setaffinity acquires a task struct ref and drops tasklist lock right away. The access to the cpus_allowed mask is protected by rq->lock. rcu_read_lock() provides the same protection here. Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra LKML-Reference: <20091209100706.789059966@linutronix.de> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit d99be10f68ad49e067e515b53970d53e37ea8b15 Author: Thomas Gleixner Date: Wed Dec 9 10:14:58 2009 +0000 sched: Use rcu in sys_sched_getscheduler/sys_sched_getparam() commit 5fe85be081edf0ac92d83f9c39e0ab5c1371eb82 upstream read_lock(&tasklist_lock) does not protect sys_sched_getscheduler and sys_sched_getparam() against a concurrent update of the policy or scheduler parameters as do_sched_setscheduler() does not take the tasklist_lock. The accessed integers can be retrieved w/o locking and are snapshots anyway. Using rcu_read_lock() to protect find_task_by_vpid() and prevent the task struct from going away is not changing the above situation. Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra LKML-Reference: <20091209100706.753790977@linutronix.de> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit ad6899b37b13b669b2c52d1a86827d62459760a4 Author: Rafael J.Wysocki Date: Sun Dec 13 00:07:30 2009 +0100 sched: Make wakeup side and atomic variants of completion API irq safe commit 7539a3b3d1f892dd97eaf094134d7de55c13befe upstream Alan Stern noticed that all the wakeup side (and atomic) variants of the completion APIs should be irq safe, but the newly introduced completion_done() and try_wait_for_completion() aren't. The use of the irq unsafe variants in IRQ contexts can cause crashes/hangs. Fix the problem by making them use spin_lock_irqsave() and spin_lock_irqrestore(). Reported-by: Alan Stern Signed-off-by: Rafael J. Wysocki Cc: Linus Torvalds Cc: Zhang Rui Cc: pm list Cc: Peter Zijlstra Cc: David Chinner Cc: Lachlan McIlroy LKML-Reference: <200912130007.30541.rjw@sisk.pl> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 7a3ca629e89928f038eedc68bc48b2e604fe9711 Author: Ingo Molnar Date: Thu Dec 10 20:32:39 2009 +0100 sched: Remove forced2_migrations stats commit b9889ed1ddeca5a3f3569c8de7354e9e97d803ae upstream This build warning: kernel/sched.c: In function 'set_task_cpu': kernel/sched.c:2070: warning: unused variable 'old_rq' Made me realize that the forced2_migrations stat looks pretty pointless (and a misnomer) - remove it. Cc: Peter Zijlstra Cc: Mike Galbraith LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit f70cad0fdf30b751216b9ce73d6df3f8aaa3c0fe Author: Peter Zijlstra Date: Fri Nov 27 17:32:46 2009 +0100 sched: Sanitize fork() handling commit cd29fe6f2637cc2ccbda5ac65f5332d6bf5fa3c6 upstream Currently we try to do task placement in wake_up_new_task() after we do the load-balance pass in sched_fork(). This yields complicated semantics in that we have to deal with tasks on different RQs and the set_task_cpu() calls in copy_process() and sched_fork() Rename ->task_new() to ->task_fork() and call it from sched_fork() before the balancing, this gives the policy a clear point to place the task. Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 7b8a5273c87b4229bb83bbb1282424e2af0af214 Author: Peter Zijlstra Date: Fri Nov 27 15:44:43 2009 +0100 sched: Clean up ttwu() rq locking commit ab19cb23313733c55e0517607844b86720b35f5f upstream Since set_task_clock() doesn't rely on rq->clock anymore we can simplyfy the mess in ttwu(). Optimize things a bit by not fiddling with the IRQ state there. Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 55eedcb291d0c7dd1a56090f72c80360fbb40d2f Author: Peter Zijlstra Date: Fri Nov 27 14:12:25 2009 +0100 sched: Remove rq->clock coupling from set_task_cpu() commit 5afcdab706d6002cb02b567ba46e650215e694e8 upstream set_task_cpu() should be rq invariant and only touch task state, it currently fails to do so, which opens up a few races, since not all callers hold both rq->locks. Remove the relyance on rq->clock, as any site calling set_task_cpu() should also do a remote clock update, which should ensure the observed time between these two cpus is monotonic, as per kernel/sched_clock.c:sched_clock_remote(). Therefore we can simply remove the clock_offset bits and be happy. Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 9c6abb9b9806aa822c1e3ad924434c42ce0206ef Author: Hiroshi Shimamoto Date: Wed Nov 4 16:16:54 2009 +0900 sched: Remove unused cpu_nr_migrations() commit 9824a2b728b63e7ff586b9fd9293c819be79f0f3 upstream cpu_nr_migrations() is not used, remove it. Signed-off-by: Hiroshi Shimamoto Cc: Peter Zijlstra LKML-Reference: <4AF12A66.6020609@ct.jp.nec.com> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit a5f9d12672fa694ec322700e0a76ce1281b1a575 Author: Peter Zijlstra Date: Wed Nov 25 13:31:39 2009 +0100 sched: Consolidate select_task_rq() callers commit 970b13bacba14a8cef6f642861947df1d175b0b3 upstream sched: Consolidate select_task_rq() callers Small cleanup. Signed-off-by: Peter Zijlstra LKML-Reference: [ v2: build fix ] Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 34d1f22e7617964c395c9e6022d8cf718558fcce Author: Thomas Gleixner Date: Wed Dec 9 09:32:03 2009 +0100 sched: Protect sched_rr_get_param() access to task->sched_class commit dba091b9e3522b9d32fc9975e48d3b69633b45f0 upstream sched_rr_get_param calls task->sched_class->get_rr_interval(task) without protection against a concurrent sched_setscheduler() call which modifies task->sched_class. Serialize the access with task_rq_lock(task) and hand the rq pointer into get_rr_interval() as it's needed at least in the sched_fair implementation. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 7272e504cb1f35861e59fade3628f047f897afff Author: Thomas Gleixner Date: Tue Dec 8 20:24:16 2009 +0000 sched: Protect task->cpus_allowed access in sched_getaffinity() commit 3160568371da441b7f2fb57f2f1225404207e8f2 upstream sched_getaffinity() is not protected against a concurrent modification of the tasks affinity. Serialize the access with task_rq_lock(task). Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra LKML-Reference: <20091208202026.769251187@linutronix.de> Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 6bd6aa7dda2b1a347de213fdce3bf7ab778988c8 Author: Roland McGrath Date: Tue Sep 14 12:22:58 2010 -0700 x86-64, compat: Retruncate rax after ia32 syscall entry tracing commit eefdca043e8391dcd719711716492063030b55ac upstream. In commit d4d6715, we reopened an old hole for a 64-bit ptracer touching a 32-bit tracee in system call entry. A %rax value set via ptrace at the entry tracing stop gets used whole as a 32-bit syscall number, while we only check the low 32 bits for validity. Fix it by truncating %rax back to 32 bits after syscall_trace_enter, in addition to testing the full 64 bits as has already been added. Reported-by: Ben Hawkes Signed-off-by: Roland McGrath Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 337b16213b3810a982e34f4b9497745c700da8a0 Author: H. Peter Anvin Date: Tue Sep 7 16:16:18 2010 -0700 compat: Make compat_alloc_user_space() incorporate the access_ok() commit c41d68a513c71e35a14f66d71782d27a79a81ea6 upstream. compat_alloc_user_space() expects the caller to independently call access_ok() to verify the returned area. A missing call could introduce problems on some architectures. This patch incorporates the access_ok() check into compat_alloc_user_space() and also adds a sanity check on the length. The existing compat_alloc_user_space() implementations are renamed arch_compat_alloc_user_space() and are used as part of the implementation of the new global function. This patch assumes NULL will cause __get_user()/__put_user() to either fail or access userspace on all architectures. This should be followed by checking the return value of compat_access_user_space() for NULL in the callers, at which time the access_ok() in the callers can also be removed. Reported-by: Ben Hawkes Signed-off-by: H. Peter Anvin Acked-by: Benjamin Herrenschmidt Acked-by: Chris Metcalf Acked-by: David S. Miller Acked-by: Ingo Molnar Acked-by: Thomas Gleixner Acked-by: Tony Luck Cc: Andrew Morton Cc: Arnd Bergmann Cc: Fenghua Yu Cc: H. Peter Anvin Cc: Heiko Carstens Cc: Helge Deller Cc: James Bottomley Cc: Kyle McMartin Cc: Martin Schwidefsky Cc: Paul Mackerras Cc: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 7764ec137f93bb83dd287d14ad457325072aa00d Author: H. Peter Anvin Date: Tue Sep 14 12:42:41 2010 -0700 x86-64, compat: Test %rax for the syscall number, not %eax commit 36d001c70d8a0144ac1d038f6876c484849a74de upstream. On 64 bits, we always, by necessity, jump through the system call table via %rax. For 32-bit system calls, in theory the system call number is stored in %eax, and the code was testing %eax for a valid system call number. At one point we loaded the stored value back from the stack to enforce zero-extension, but that was removed in checkin d4d67150165df8bf1cc05e532f6efca96f907cab. An actual 32-bit process will not be able to introduce a non-zero-extended number, but it can happen via ptrace. Instead of re-introducing the zero-extension, test what we are actually going to use, i.e. %rax. This only adds a handful of REX prefixes to the code. Reported-by: Ben Hawkes Signed-off-by: H. Peter Anvin Cc: Roland McGrath Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f5f6687a47de60dc11007ee7a962cf366027d4ec Author: Peter Zijlstra Date: Fri Sep 10 22:32:53 2010 +0200 x86, tsc: Fix a preemption leak in restore_sched_clock_state() commit 55496c896b8a695140045099d4e0175cf09d4eae upstream. Doh, a real life genuine preemption leak.. This caused a suspend failure. Reported-bisected-and-tested-by-the-invaluable: Jeff Chua Acked-by: Suresh Siddha Signed-off-by: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Nico Schottelius Cc: Jesse Barnes Cc: Linus Torvalds Cc: Florian Pritz Cc: Suresh Siddha Cc: Len Brown sleep states LKML-Reference: <1284150773.402.122.camel@laptop> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 444ba62c397038dc01eef78f9b754b6b8c2fd0a4 Author: Johannes Berg Date: Mon Aug 30 12:24:54 2010 +0200 wireless extensions: fix kernel heap content leak commit 42da2f948d949efd0111309f5827bf0298bcc9a4 upstream. Wireless extensions have an unfortunate, undocumented requirement which requires drivers to always fill iwp->length when returning a successful status. When a driver doesn't do this, it leads to a kernel heap content leak when userspace offers a larger buffer than would have been necessary. Arguably, this is a driver bug, as it should, if it returns 0, fill iwp->length, even if it separately indicated that the buffer contents was not valid. However, we can also at least avoid the memory content leak if the driver doesn't do this by setting the iwp length to max_tokens, which then reflects how big the buffer is that the driver may fill, regardless of how big the userspace buffer is. To illustrate the point, this patch also fixes a corresponding cfg80211 bug (since this requirement isn't documented nor was ever pointed out by anyone during code review, I don't trust all drivers nor all cfg80211 handlers to implement it correctly). Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 34cee821ec2b89a613947b72eec8f31305c58a93 Author: John W. Linville Date: Tue Aug 24 15:27:34 2010 -0400 ath5k: check return value of ieee80211_get_tx_rate commit d8e1ba76d619dbc0be8fbeee4e6c683b5c812d3a upstream. This avoids a NULL pointer dereference as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=625889 When the WARN condition is hit in ieee80211_get_tx_rate, it will return NULL. So, we need to check the return value and avoid dereferencing it in that case. Signed-off-by: John W. Linville Acked-by: Bob Copeland Signed-off-by: Greg Kroah-Hartman commit 8fdd6243c34ea97465f10be83384f7c9cafb17f5 Author: Christian Lamparter Date: Tue Aug 24 22:54:05 2010 +0200 p54: fix tx feedback status flag check commit f880c2050f30b23c9b6f80028c09f76e693bf309 upstream. Michael reported that p54* never really entered power save mode, even tough it was enabled. It turned out that upon a power save mode change the firmware will set a special flag onto the last outgoing frame tx status (which in this case is almost always the designated PSM nullfunc frame). This flag confused the driver; It erroneously reported transmission failures to the stack, which then generated the next nullfunc. and so on... Reported-by: Michael Buesch Tested-by: Michael Buesch Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a4bc94d437129f5c5fe64b1f58691a6e8d113e74 Author: Frederic Weisbecker Date: Sun Aug 22 04:29:17 2010 +0200 perf: Initialize callchains roots's childen hits commit 5225c45899e872383ca39f5533d28ec63c54b39e upstream. Each histogram entry has a callchain root that stores the callchain samples. However we forgot to initialize the tracking of children hits of these roots, which then got random values on their creation. The root children hits is multiplied by the minimum percentage of hits provided by the user, and the result becomes the minimum hits expected from children branches. If the random value due to the uninitialization is big enough, then this minimum number of hits can be huge and eventually filter every children branches. The end result was invisible callchains. All we need to fix this is to initialize the children hits of the root. Reported-by: Christoph Hellwig Signed-off-by: Frederic Weisbecker Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit 05e0120a463a8ce6337a6e4d6721a7b3aef8c52c Author: KAMEZAWA Hiroyuki Date: Thu Sep 9 16:38:01 2010 -0700 memory hotplug: fix next block calculation in is_removable commit 0dcc48c15f63ee86c2fcd33968b08d651f0360a5 upstream. next_active_pageblock() is for finding next _used_ freeblock. It skips several blocks when it finds there are a chunk of free pages lager than pageblock. But it has 2 bugs. 1. We have no lock. page_order(page) - pageblock_order can be minus. 2. pageblocks_stride += is wrong. it should skip page_order(p) of pages. Signed-off-by: KAMEZAWA Hiroyuki Cc: Michal Hocko Cc: Wu Fengguang Cc: Mel Gorman Cc: KAMEZAWA Hiroyuki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e3327857e9b33f2cb9921e469f9ea1806fdedc9b Author: Dmitry Torokhov Date: Tue Aug 31 17:27:02 2010 -0700 Input: i8042 - fix device removal on unload commit af045b86662f17bf130239a65995c61a34f00a6b upstream. We need to call platform_device_unregister(i8042_platform_device) before calling platform_driver_unregister() because i8042_remove() resets i8042_platform_device to NULL. This leaves the platform device instance behind and prevents driver reload. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=16613 Reported-by: Seryodkin Victor Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 0ca6988df7e449c1e5d8e979e109c83062644a0b Author: Jan Sembera Date: Thu Sep 9 16:37:54 2010 -0700 binfmt_misc: fix binfmt_misc priority commit ee3aebdd8f5f8eac41c25c80ceee3d728f920f3b upstream. Commit 74641f584da ("alpha: binfmt_aout fix") (May 2009) introduced a regression - binfmt_misc is now consulted after binfmt_elf, which will unfortunately break ia32el. ia32 ELF binaries on ia64 used to be matched using binfmt_misc and executed using wrapper. As 32bit binaries are now matched by binfmt_elf before bindmt_misc kicks in, the wrapper is ignored. The fix increases precedence of binfmt_misc to the original state. Signed-off-by: Jan Sembera Cc: Ivan Kokshaysky Cc: Al Viro Cc: Richard Henderson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0776127797119f67f8bc350938e32dbe68631edc Author: Jerome Marchand Date: Thu Sep 9 16:37:59 2010 -0700 kernel/groups.c: fix integer overflow in groups_search commit 1c24de60e50fb19b94d94225458da17c720f0729 upstream. gid_t is a unsigned int. If group_info contains a gid greater than MAX_INT, groups_search() function may look on the wrong side of the search tree. This solves some unfair "permission denied" problems. Signed-off-by: Jerome Marchand Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a0c42c23e8dc2d7f1c3bae407d98c709c9f6b89b Author: Gary King Date: Thu Sep 9 16:38:05 2010 -0700 bounce: call flush_dcache_page() after bounce_copy_vec() commit ac8456d6f9a3011c824176bd6084d39e5f70a382 upstream. I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform cache maintenance lazily), and the root cause appears to be that the mm bouncing code is calling flush_dcache_page before it copies the bounce buffer into the bio. The bounced page needs to be flushed after data is copied into it, to ensure that architecture implementations can synchronize instruction and data caches if necessary. Signed-off-by: Gary King Cc: Tejun Heo Cc: Russell King Acked-by: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 61e3fe7a310a1b99503535987ff2cc926348480e Author: Guennadi Liakhovetski Date: Thu Sep 9 16:37:43 2010 -0700 mmc: fix the use of kunmap_atomic() in tmio_mmc.h commit 5600efb1bc2745d93ae0bc08130117a84f2b9d69 upstream. kunmap_atomic() takes the cookie, returned by the kmap_atomic() as its argument and not the page address, used as an argument to kmap_atomic(). This patch fixes the compile error: In file included from drivers/mmc/host/tmio_mmc.c:37: drivers/mmc/host/tmio_mmc.h: In function 'tmio_mmc_kunmap_atomic': drivers/mmc/host/tmio_mmc.h:192: error: negative width in bit-field '' Signed-off-by: Guennadi Liakhovetski Acked-by: Eric Miao Tested-by: Magnus Damm Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 389e860f1bf15e255ec9ab52e2ede28a4d2a9b5a Author: Yusuke Goda Date: Thu Sep 9 16:37:39 2010 -0700 tmio_mmc: don't clear unhandled pending interrupts commit b78d6c5f51935ba89df8db33a57bacb547aa7325 upstream. Previously, it was possible for ack_mmc_irqs() to clear pending interrupt bits in the CTL_STATUS register, even though the interrupt handler had not been called. This was because of a race that existed when doing a read-modify-write sequence on CTL_STATUS. After the read step in this sequence, if an interrupt occurred (causing one of the bits in CTL_STATUS to be set) the write step would inadvertently clear it. Observed with the TMIO_STAT_RXRDY bit together with CMD53 on AR6002 and BCM4318 SDIO cards in polled mode. This patch eliminates this race by only writing to CTL_STATUS and clearing the interrupts that were passed as an argument to ack_mmc_irqs()." [matt@console-pimps.org: rewrote changelog] Signed-off-by: Yusuke Goda Acked-by: Magnus Damm Tested-by: Arnd Hannemann Acked-by: Ian Molton Cc: Matt Fleming Cc: Samuel Ortiz Cc: Paul Mundt Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4e318f43d2ad9a3f5b1054f1388216d8e001f750 Author: Peter Oberparleiter Date: Thu Sep 9 16:37:35 2010 -0700 gcov: fix null-pointer dereference for certain module types commit 85a0fdfd0f967507f3903e8419bc7e408f5a59de upstream. The gcov-kernel infrastructure expects that each object file is loaded only once. This may not be true, e.g. when loading multiple kernel modules which are linked to the same object file. As a result, loading such kernel modules will result in incorrect gcov results while unloading will cause a null-pointer dereference. This patch fixes these problems by changing the gcov-kernel infrastructure so that multiple profiling data sets can be associated with one debugfs entry. It applies to 2.6.36-rc1. Signed-off-by: Peter Oberparleiter Reported-by: Werner Spies Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f4ee150ede7f8ff1a1d8992579c2e1a7e2520815 Author: Dan Carpenter Date: Sat Sep 4 03:14:35 2010 +0000 irda: off by one commit cf9b94f88bdbe8a02015fc30d7c232b2d262d4ad upstream. This is an off by one. We would go past the end when we NUL terminate the "value" string at end of the function. The "value" buffer is allocated in irlan_client_parse_response() or irlan_provider_parse_command(). CC: stable@kernel.org Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller commit 97c63b87be9bdfa8b1f0fb1d000937df0e5c28a8 Author: Chris Wright Date: Thu Sep 9 16:34:59 2010 -0700 tracing: t_start: reset FTRACE_ITER_HASH in case of seek/pread commit df09162550fbb53354f0c88e85b5d0e6129ee9cc upstream. Be sure to avoid entering t_show() with FTRACE_ITER_HASH set without having properly started the iterator to iterate the hash. This case is degenerate and, as discovered by Robert Swiecki, can cause t_hash_show() to misuse a pointer. This causes a NULL ptr deref with possible security implications. Tracked as CVE-2010-3079. Cc: Robert Swiecki Cc: Eugene Teo Signed-off-by: Chris Wright Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 577fd36b74a2ae18d9c61e65dc5dc6238a6a38c4 Author: Steven Rostedt Date: Wed Sep 8 11:20:37 2010 -0400 tracing: Do not allow llseek to set_ftrace_filter commit 9c55cb12c1c172e2d51e85fbb5a4796ca86b77e7 upstream. Reading the file set_ftrace_filter does three things. 1) shows whether or not filters are set for the function tracer 2) shows what functions are set for the function tracer 3) shows what triggers are set on any functions 3 is independent from 1 and 2. The way this file currently works is that it is a state machine, and as you read it, it may change state. But this assumption breaks when you use lseek() on the file. The state machine gets out of sync and the t_show() may use the wrong pointer and cause a kernel oops. Luckily, this will only kill the app that does the lseek, but the app dies while holding a mutex. This prevents anyone else from using the set_ftrace_filter file (or any other function tracing file for that matter). A real fix for this is to rewrite the code, but that is too much for a -rc release or stable. This patch simply disables llseek on the set_ftrace_filter() file for now, and we can do the proper fix for the next major release. Reported-by: Robert Swiecki Cc: Chris Wright Cc: Tavis Ormandy Cc: Eugene Teo Cc: vendor-sec@lst.de Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit d17babf50abe4f993adae23650b06d7638bc2793 Author: Li Zefan Date: Mon Aug 23 16:50:12 2010 +0800 tracing: Fix a race in function profile commit 3aaba20f26f58843e8f20611e5c0b1c06954310f upstream. While we are reading trace_stat/functionX and someone just disabled function_profile at that time, we can trigger this: divide error: 0000 [#1] PREEMPT SMP ... EIP is at function_stat_show+0x90/0x230 ... This fix just takes the ftrace_profile_lock and checks if rec->counter is 0. If it's 0, we know the profile buffer has been reset. Signed-off-by: Li Zefan LKML-Reference: <4C723644.4040708@cn.fujitsu.com> Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 45665602d901bae2a384e2a332168ea56c82ed34 Author: Tejun Heo Date: Tue Sep 7 14:05:31 2010 +0200 libata: skip EH autopsy and recovery during suspend commit e2f3d75fc0e4a0d03c61872bad39ffa2e74a04ff upstream. For some mysterious reason, certain hardware reacts badly to usual EH actions while the system is going for suspend. As the devices won't be needed until the system is resumed, ask EH to skip usual autopsy and recovery and proceed directly to suspend. Signed-off-by: Tejun Heo Tested-by: Stephan Diestelhorst Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 3df1ba0d074919fef36e919220aec1b379d82684 Author: Alan Stern Date: Fri May 7 10:41:10 2010 -0400 HID: fix suspend crash by moving initializations earlier commit fde4e2f73208b8f34f123791e39c0cb6bc74b32a upstream. Although the usbhid driver allocates its usbhid structure in the probe routine, several critical fields in that structure don't get initialized until usbhid_start(). However if report descriptor parsing fails then usbhid_start() is never called. This leads to problems during system suspend -- the system will freeze. This patch (as1378) fixes the bug by moving the initialization statements up into usbhid_probe(). Signed-off-by: Alan Stern Reported-by: Bruno Prémont Tested-By: Bruno Prémont Signed-off-by: Jiri Kosina Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit c7260ac8c7a413285419dd3835e81d43ec39fba6 Author: Jiri Kosina Date: Wed Feb 17 14:25:01 2010 +0100 HID: usbhid: initialize interface pointers early enough commit 57ab12e418ec4fe24c11788bb1bbdabb29d05679 upstream. Move the initialization of USB interface pointers from _start() over to _probe() callback, which is where it belongs. This fixes case where interface is NULL when parsing of report descriptor fails. LKML-Reference: <20100213135720.603e5f64@neptune.home> Reported-by: Alan Stern Tested-by: Bruno Prémont Signed-off-by: Jiri Kosina Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit a9dd3bc18f34e031d923eb519e8149acdb408327 Author: Robert Richter Date: Wed Sep 1 14:50:50 2010 +0200 oprofile, x86: fix init_sysfs() function stub commit 269f45c25028c75fe10e6d9be86e7202ab461fbc upstream. The use of the return value of init_sysfs() with commit 10f0412 oprofile, x86: fix init_sysfs error handling discovered the following build error for !CONFIG_PM: .../linux/arch/x86/oprofile/nmi_int.c: In function ‘op_nmi_init’: .../linux/arch/x86/oprofile/nmi_int.c:784: error: expected expression before ‘do’ make[2]: *** [arch/x86/oprofile/nmi_int.o] Error 1 make[1]: *** [arch/x86/oprofile] Error 2 This patch fixes this. Reported-by: Ingo Molnar Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit b250d8d2d7b7997252f20d661481c1335878a214 Author: Robert Richter Date: Mon Aug 30 10:56:18 2010 +0200 oprofile, x86: fix init_sysfs error handling commit 10f0412f57f2a76a90eff4376f59cbb0a39e4e18 upstream. On failure init_sysfs() might not properly free resources. The error code of the function is not checked. And, when reinitializing the exit function might be called twice. This patch fixes all this. Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit f4db115e77b11a8ff22bcd9a3900f03d396a7a53 Author: Robert Richter Date: Fri Aug 13 16:29:04 2010 +0200 oprofile: fix crash when accessing freed task structs commit 750d857c682f4db60d14722d430c7ccc35070962 upstream. This patch fixes a crash during shutdown reported below. The crash is caused by accessing already freed task structs. The fix changes the order for registering and unregistering notifier callbacks. All notifiers must be initialized before buffers start working. To stop buffer synchronization we cancel all workqueues, unregister the notifier callback and then flush all buffers. After all of this we finally can free all tasks listed. This should avoid accessing freed tasks. On 22.07.10 01:14:40, Benjamin Herrenschmidt wrote: > So the initial observation is a spinlock bad magic followed by a crash > in the spinlock debug code: > > [ 1541.586531] BUG: spinlock bad magic on CPU#5, events/5/136 > [ 1541.597564] Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6d03 > > Backtrace looks like: > > spin_bug+0x74/0xd4 > ._raw_spin_lock+0x48/0x184 > ._spin_lock+0x10/0x24 > .get_task_mm+0x28/0x8c > .sync_buffer+0x1b4/0x598 > .wq_sync_buffer+0xa0/0xdc > .worker_thread+0x1d8/0x2a8 > .kthread+0xa8/0xb4 > .kernel_thread+0x54/0x70 > > So we are accessing a freed task struct in the work queue when > processing the samples. Reported-by: Benjamin Herrenschmidt Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit 11bb28b4168d940f156b9752e8d12ca403cb0426 Author: Ben Hutchings Date: Thu Sep 9 05:21:16 2010 +0100 tun: Don't add sysfs attributes to devices without sysfs directories This applies to 2.6.32 *only*. It has not been applied upstream since the limitation no longer exists. Prior to Linux 2.6.35, net devices outside the initial net namespace did not have sysfs directories. Attempting to add attributes to them will trigger a BUG(). Reported-and-tested-by: Russell Stuart Signed-off-by: Ben Hutchings Acked-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 88c0bb95c7e71d972f77ec4ea1be611b7e015066 Author: Dan Carpenter Date: Wed Aug 25 09:12:29 2010 +0200 sysfs: checking for NULL instead of ERR_PTR commit 57f9bdac2510cd7fda58e4a111d250861eb1ebeb upstream. d_path() returns an ERR_PTR and it doesn't return NULL. Signed-off-by: Dan Carpenter Reviewed-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 2410490a1429ed3cff56d7fe9a6085d5d2f9eaec Author: Takashi Iwai Date: Mon Sep 6 09:13:45 2010 +0200 ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open() commit 27f7ad53829f79e799a253285318bff79ece15bd upstream. The error handling in snd_seq_oss_open() has several bad codes that do dereferecing released pointers and double-free of kmalloc'ed data. The object dp is release in free_devinfo() that is called via private_free callback. The rest shouldn't touch this object any more. The patch changes delete_port() to call kfree() in any case, and gets rid of unnecessary calls of destructors in snd_seq_oss_open(). Fixes CVE-2010-3080. Reported-and-tested-by: Tavis Ormandy Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9dd88324a92d19152897e47f92fdf6b5cbbd2589 Author: Kailang Yang Date: Fri Apr 9 10:57:33 2010 +0200 ALSA: hda - Fix auto-parser of ALC269vb for HP pin NID 0x21 commit 531d8791accf1464bc6854ff69d08dd866189d17 upstream. ALC269vb has an alternative HP pin 0x21 in addition. Fix the parser to recognize it. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Cc: David Henningsson Signed-off-by: Greg Kroah-Hartman commit e9f19071157e76312b0c3ae3d85d9649189c2963 Author: Toby Gray Date: Thu Sep 2 10:46:20 2010 +0100 USB: cdc-acm: Fixing crash when ACM probing interfaces with no endpoint descriptors. commit 577045c0a76e34294f902a7d5d60e90b04d094d0 upstream. Certain USB devices, such as the Nokia X6 mobile phone, don't expose any endpoint descriptors on some of their interfaces. If the ACM driver is forced to probe all interfaces on a device the a NULL pointer dereference will occur when the ACM driver attempts to use the endpoint of the alternative settings. One way to get the ACM driver to probe all the interfaces is by using the /sys/bus/usb/drivers/cdc_acm/new_id interface. This patch checks that the endpoint pointer for the current alternate settings is non-NULL before using it. Signed-off-by: Toby Gray Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 77192da03aee9acb33a7f5f137c0b422565cc7e2 Author: Philippe Corbes Date: Tue Aug 31 19:31:32 2010 +0200 USB: cdc-acm: Add pseudo modem without AT command capabilities commit 5b239f0aebd4dd6f85b13decf5e18e86e35d57f0 upstream. cdc-acm.c : Manage pseudo-modem without AT commands capabilities Enable to drive electronic simple gadgets based on microcontrolers. The Interface descriptor is like this: bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 None Signed-off-by: Philippe Corbes Signed-off-by: Greg Kroah-Hartman commit 4fd561ee53b4f354193b99a7ecce340f1d366178 Author: Toby Gray Date: Wed Sep 1 16:01:19 2010 +0100 USB: cdc-acm: Adding second ACM channel support for various Nokia and one Samsung phones commit 4035e45632c2a8bb4edae83c20447051bd9a9604 upstream. S60 phones from Nokia and Samsung expose two ACM channels. The first is a modem with a standard AT-command interface, which is picked up correctly by CDC-ACM. The second ACM port is marked as having a vendor-specific protocol. This means that the ACM driver will not claim the second channel by default. This adds support for the second ACM channel for the following devices: Nokia E63 Nokia E75 Nokia 6760 Slide Nokia E52 Nokia E55 Nokia E72 Nokia X6 Nokia N97 Mini Nokia 5800 Xpressmusic Nokia E90 Samsung GTi8510 (INNOV8) Signed-off-by: Toby Gray Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 6d305a8ddb504ec8cdce033445c81e329f526110 Author: Przemo Firszt Date: Mon Jun 28 21:29:34 2010 +0100 USB: Expose vendor-specific ACM channel on Nokia 5230 commit 83a4eae9aeed4a69e89e323a105e653ae06e7c1f upstream. Nokia S60 phones expose two ACM channels. The first is a modem, the second is 'vendor-specific' but is treated as a serial device at the S60 end, so we want to expose it on Linux too. Signed-off-by: Przemo Firszt Signed-off-by: Greg Kroah-Hartman commit 8a69e9bb0cde88b566f6e791b63389e817f3aa39 Author: Russ Nelson Date: Wed Apr 21 23:07:03 2010 -0400 USB: cdc-acm: add another device quirk commit c3baa19b0a9b711b02cec81d9fea33b7b9628957 upstream. The Maretron USB100 needs this quirk in order to work properly. Signed-off-by: Russ Nelson Signed-off-by: Greg Kroah-Hartman commit 54233a5eb7b37824804ae00dd4be51b6023e0131 Author: Adrian Taylor Date: Thu Nov 19 10:35:33 2009 +0000 USB: Exposing second ACM channel as tty for Nokia S60 phones. commit c1479a92cf0a7792298d364e44a781550621cb58 upstream. Nokia S60 phones expose two ACM channels. The first is a modem and is picked up by the standard AT-command interface information in the CDC-ACM driver. The second is marked as having a vendor-specific protocol. Normally, we don't expose those as ttys. (On some other devices, they may be claimed by the rndis_host driver and used as a network interface). But on S60 this second ACM channel is the way that third-party S60 application developers are expected to communicate over USB. It acts as a serial device at the S60 end, and so it should on Linux too. The list of devices is largely derived from: http://wiki.forum.nokia.com/index.php/S60_Platform_and_device_identification_codes http://wiki.forum.nokia.com/index.php/Nokia_USB_Product_IDs and includes only the S60 3rd Edition+ devices documented there. There are many devices for which the USB device ID is not documented, including: Nokia 6290 Nokia E63 Nokia 5630 XpressMusic Nokia 5730 XpressMusic Nokia 6710 Navigator Nokia 6720 classic Nokia 6730 Classic Nokia 6760 slide Nokia 6790 slide Nokia 6790 Surge Nokia E52 Nokia E55 Nokia E71x (AT&T) Nokia E72 Nokia E75 Nokia E75 US+LTA variant Nokia N79 Nokia N86 8MP Nokia 5230 (RM-588) Nokia 5230 (RM-594) Nokia 5530 XpressMusic Nokia 5530 XpressMusic (china) Nokia 5800 XM Nokia N97 (RM-506) Nokia N97 mini Nokia X6 It would be good to add those subsequently. Signed-off-by: Adrian Taylor Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 2f606b9aff30c23894e42da36b885f789a13b92f Author: Dave Ludlow Date: Wed Sep 1 12:33:30 2010 -0400 usb: serial: mos7840: Add USB IDs to support more B&B USB/RS485 converters. commit 870408c8291015872a7a0b583673a9e56b3e73f4 upstream. Add the USB IDs needed to support the B&B USOPTL4-4P, USO9ML2-2P, and USO9ML2-4P. This patch expands and corrects a typo in the patch sent on 08-31-2010. Signed-off-by: Dave Ludlow Signed-off-by: Greg Kroah-Hartman commit 1c4a6ee759c50b18a591e6b9c89687cdf9382724 Author: Johan Hovold Date: Mon Dec 28 23:01:55 2009 +0100 USB: mos7840: fix DMA buffers on stack and endianess bugs commit 9e221a35f82cbef0397d81fed588bafba95b550c upstream. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 694cdee9bd697775de829418203f35ce9e83829b Author: Dave Ludlow Date: Tue Aug 31 14:26:17 2010 -0400 usb: serial: mos7840: Add USB ID to support the B&B Electronics USOPTL4-2P. commit caf3a636a9f809fdca5fa746e6687096457accb1 upstream. Add the USB ID needed to support B&B Electronic's 2-port, optically-isolated, powered, USB to RS485 converter. Signed-off-by: Dave Ludlow Signed-off-by: Greg Kroah-Hartman commit 78224a6457c1522261a6327e509dfab1326187d9 Author: Blaise Gassend Date: Fri Dec 18 15:23:38 2009 -0800 USB: serial: Extra device/vendor ID for mos7840 driver commit 27f1281d5f72e4f161e215ccad3d7d86b9e624a9 upstream. Signed-off-by: Blaise Gassend Signed-off-by: Greg Kroah-Hartman commit c77002ff2e9ce8ebd4b0b5666d8a77e660fc8617 Author: Luke Lowrey Date: Thu Sep 2 11:39:49 2010 +0100 USB: ftdi_sio: Added custom PIDs for ChamSys products commit 657373883417b2618023fd4135d251ba06a2c30a upstream. Added the 0xDAF8 to 0xDAFF PID range for ChamSys limited USB interface/wing products Signed-off-by: Luke Lowrey Signed-off-by: Greg Kroah-Hartman commit cfaa806c66e1b84afa2ad0aecc5c9babd60df8e9 Author: Jason Detring Date: Thu Aug 26 15:08:54 2010 -0500 USB: cp210x: Add B&G H3000 link cable ID commit 0bf7a81c5d447c21db434be35363c44c0a30f598 upstream. This is the cable between an H3000 navigation unit and a multi-function display. http://www.bandg.com/en/Products/H3000/Spares-and-Accessories/Cables/H3000-CPU-USB-Cable-Pack/ Signed-off-by: Jason Detring Signed-off-by: Greg Kroah-Hartman commit ea798ad3b105582b685e5932aeceb7384e76da9b Author: Craig Shelley Date: Mon Aug 23 20:50:57 2010 +0100 USB: CP210x Add new device ID commit 541e05ec3add5ab5bcf238d60161b53480280b20 upstream. New device ID added for Balluff RFID reader. Signed-off-by: Craig Shelley Signed-off-by: Greg Kroah-Hartman commit 2115157f0c9dec388cd19d06bd0384318bf23b36 Author: Maxim Osipov Date: Sat Aug 21 14:54:06 2010 +0400 USB: Fix kernel oops with g_ether and Windows commit 037d3656adbd7e8cb848f01cf5dec423ed76bbe7 upstream. Please find attached patch for https://bugzilla.kernel.org/show_bug.cgi?id=16023 problem. Signed-off-by: Maxim Osipov Signed-off-by: Greg Kroah-Hartman commit 3fd4a383a86980639a951496de13b6be16531345 Author: Dan Carpenter Date: Sat Aug 14 11:06:19 2010 +0200 USB: ehci-ppc-of: problems in unwind commit 08a3b3b1c2e622e378d9086aee9e2e42ce37591d upstream. The iounmap(ehci->ohci_hcctrl_reg); should be the first thing we do because the ioremap() was the last thing we did. Also if we hit any of the goto statements in the original code then it would have led to a NULL dereference of "ehci". This bug was introduced in: 796bcae7361c "USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]" I modified the few lines in front a little so that my code didn't obscure the return success code path. Signed-off-by: Dan Carpenter Reviewed-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit 18b4e9d89260347957cc39f200e8563f51ff970f Author: Sunil Mushran Date: Thu Aug 12 16:24:26 2010 -0700 ocfs2: Fix incorrect checksum validation error commit f5ce5a08a40f2086435858ddc80cb40394b082eb upstream. For local mounts, ocfs2_read_locked_inode() calls ocfs2_read_blocks_sync() to read the inode off the disk. The latter first checks to see if that block is cached in the journal, and, if so, returns that block. That is ok. But ocfs2_read_locked_inode() goes wrong when it tries to validate the checksum of such blocks. Blocks that are cached in the journal may not have had their checksum computed as yet. We should not validate the checksums of such blocks. Fixes ossbz#1282 http://oss.oracle.com/bugzilla/show_bug.cgi?id=1282 Signed-off-by: Sunil Mushran Singed-off-by: Tao Ma Signed-off-by: Greg Kroah-Hartman commit 2a0c8c9125dc05546e6d696897eb1d14a97ae28c Author: Luis R. Rodriguez Date: Mon Aug 30 19:26:33 2010 -0400 ath9k_hw: fix parsing of HT40 5 GHz CTLs commit 904879748d7439a6dabdc6be9aad983e216b027d upstream. The 5 GHz CTL indexes were not being read for all hardware devices due to the masking out through the CTL_MODE_M mask being one bit too short. Without this the calibrated regulatory maximum values were not being picked up when devices operate on 5 GHz in HT40 mode. The final output power used for Atheros devices is the minimum between the calibrated CTL values and what CRDA provides. Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit eeea0346fcb0846d1bfe42e3c87486ab0d26e950 Author: Miklos Szeredi Date: Tue Sep 7 13:42:41 2010 +0200 fuse: flush background queue on connection close commit 595afaf9e6ee1b48e13ec4b8bcc8c7dee888161a upstream. David Bartly reported that fuse can hang in fuse_get_req_nofail() when the connection to the filesystem server is no longer active. If bg_queue is not empty then flush_bg_queue() called from request_end() can put more requests on to the pending queue. If this happens while ending requests on the processing queue then those background requests will be queued to the pending list and never ended. Another problem is that fuse_dev_release() didn't wake up processes sleeping on blocked_waitq. Solve this by: a) flushing the background queue before calling end_requests() on the pending and processing queues b) setting blocked = 0 and waking up processes waiting on blocked_waitq() Thanks to David for an excellent bug report. Reported-by: David Bartley Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit f60f79f09b780ba847f5ff78b0c86c740bd07d99 Author: Hank Janssen Date: Wed Sep 1 11:10:41 2010 -0700 staging: hv: Fixed lockup problem with bounce_buffer scatter list commit 77c5ceaff31645ea049c6706b99e699eae81fb88 upstream. Fixed lockup problem with bounce_buffer scatter list which caused crashes in heavy loads. And minor code indentation cleanup in effected area. Removed whitespace and noted minor indentation changes in description as pointed out by Joe Perches. (Thanks for reviewing Joe) Signed-off-by: Hank Janssen Signed-off-by: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman commit 69e313042c71209ee0ace4b01b3099694ea1d7db Author: Hank Janssen Date: Thu Aug 5 19:30:31 2010 +0000 staging: hv: Increased storvsc ringbuffer and max_io_requests commit 15dd1c9f53b31cdc84b8072a88c23fa09527c596 upstream. Increased storvsc ringbuffer and max_io_requests. This now more closely mimics the numbers on Hyper-V. And will allow more IO requests to take place for the SCSI driver. Max_IO is set to double from what it was before, Hyper-V allows it and we have had appliance builder requests to see if it was a problem to increase the number. Ringbuffer size for storvsc is now increased because I have seen A few buffer problems on extremely busy systems. They were Set pretty low before. And since max_io_requests is increased I Really needed to increase the buffer as well. Signed-off-by: Hank Janssen Signed-off-by: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman commit 323f2e45fb38694cd000f7227651af9a2d4c78c8 Author: Haiyang Zhang Date: Thu Aug 5 19:30:01 2010 +0000 staging: hv: Fixed the value of the 64bit-hole inside ring buffer commit e5fa721d1c2a54261a37eb59686e18dee34b6af6 upstream. Fixed the value of the 64bit-hole inside ring buffer, this caused a problem on Hyper-V when running checked Windows builds. Checked builds of Windows are used internally and given to external system integrators at times. They are builds that for example that all elements in a structure follow the definition of that Structure. The bug this fixed was for a field that we did not fill in at all (Because we do Not use it on the Linux side), and the checked build of windows gives errors on it internally to the Windows logs. This fixes that error. Signed-off-by: Hank Janssen Signed-off-by: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman commit 8eccb26da55a81c0bf0b84dacfb7847755203bab Author: Hank Janssen Date: Thu Aug 5 19:29:44 2010 +0000 staging: hv: Fixed bounce kmap problem by using correct index commit 0c47a70a9a8a6d1ec37a53d2f9cb82f8b8ef8aa2 upstream. Fixed bounce offset kmap problem by using correct index. The symptom of the problem is that in some NAS appliances this problem represents Itself by a unresponsive VM under a load with many clients writing small files. Signed-off-by:Hank Janssen Signed-off-by:Haiyang Zhang Signed-off-by: Greg Kroah-Hartman commit 0d145eb2c1a76cbf0f9ea64fb8fd0dd890386068 Author: Haiyang Zhang Date: Tue Aug 3 19:15:31 2010 +0000 staging: hv: Fix missing functions for net_device_ops commit b681b5886bb5d1f5b6750a0ed7c62846da7ccea4 upstream. Fix missing functions for net_device_ops. It's a bug when porting the drivers from 2.6.27 to 2.6.32. In 2.6.27, the default functions for Ethernet, like eth_change_mtu(), were assigned by ether_setup(). But in 2.6.32, these function pointers moved to net_device_ops structure and no longer be assigned in ether_setup(). So we need to set these functions in our driver code. It will ensure the MTU won't be set beyond 1500. Otherwise, this can cause an error on the server side, because the HyperV linux driver doesn't support jumbo frame yet. Signed-off-by: Haiyang Zhang Signed-off-by: Hank Janssen Signed-off-by: Greg Kroah-Hartman commit 8c5217d732d576bcdacf7cd515165f246e6a4912 Author: Mike Galbraith Date: Thu Aug 26 05:29:16 2010 +0200 sched: revert stable c6fc81a sched: Fix a race between ttwu() and migrate_task() This commit does not appear to have been meant for 32-stable, and causes ltp's cpusets testcases to fail, revert it. Original commit text: sched: Fix a race between ttwu() and migrate_task() Based on commit e2912009fb7b715728311b0d8fe327a1432b3f79 upstream, but done differently as this issue is not present in .33 or .34 kernels due to rework in this area. If a task is in the TASK_WAITING state, then try_to_wake_up() is working on it, and it will place it on the correct cpu. This commit ensures that neither migrate_task() nor __migrate_task() calls set_task_cpu(p) while p is in the TASK_WAKING state. Otherwise, there could be two concurrent calls to set_task_cpu(p), resulting in the task's cfs_rq being inconsistent with its cpu. Signed-off-by: Mike Galbraith Cc: Ingo Molnar Cc: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit 6f6198a78a34e3d8623f717d05087267e8dedef2 Author: Amit Arora Date: Wed May 19 14:35:57 2010 +0530 sched: kill migration thread in CPU_POST_DEAD instead of CPU_DEAD [Fixed in a different manner upstream, due to rewrites in this area] Problem : In a stress test where some heavy tests were running along with regular CPU offlining and onlining, a hang was observed. The system seems to be hung at a point where migration_call() tries to kill the migration_thread of the dying CPU, which just got moved to the current CPU. This migration thread does not get a chance to run (and die) since rt_throttled is set to 1 on current, and it doesn't get cleared as the hrtimer which is supposed to reset the rt bandwidth (sched_rt_period_timer) is tied to the CPU which we just marked dead! Solution : This patch pushes the killing of migration thread to "CPU_POST_DEAD" event. By then all the timers (including sched_rt_period_timer) should have got migrated (along with other callbacks). Signed-off-by: Amit Arora Signed-off-by: Gautham R Shenoy Signed-off-by: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit bd614669ff84a58b5605e7a3c27372ecbf9ff3d1 Author: Ben Hutchings Date: Fri Jul 23 14:56:28 2010 +0100 PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc() commit 30da55242818a8ca08583188ebcbaccd283ad4d9 upstream. commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove unsafe and unnecessary hardware access" changed read_msi_msg_desc() to return the last MSI message written instead of reading it from the device, since it may be called while the device is in a reduced power state. However, the pSeries platform code really does need to read messages from the device, since they are initially written by firmware. Therefore: - Restore the previous behaviour of read_msi_msg_desc() - Add new functions get_cached_msi_msg{,_desc}() which return the last MSI message written - Use the new functions where appropriate Acked-by: Michael Ellerman Signed-off-by: Ben Hutchings Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit ed6fd21943f0e2bbab458755fe44c71c47660c4d Author: Ben Hutchings Date: Thu Jun 17 20:16:36 2010 +0100 PCI: MSI: Remove unsafe and unnecessary hardware access commit fcd097f31a6ee207cc0c3da9cccd2a86d4334785 upstream. During suspend on an SMP system, {read,write}_msi_msg_desc() may be called to mask and unmask interrupts on a device that is already in a reduced power state. At this point memory-mapped registers including MSI-X tables are not accessible, and config space may not be fully functional either. While a device is in a reduced power state its interrupts are effectively masked and its MSI(-X) state will be restored when it is brought back to D0. Therefore these functions can simply read and write msi_desc::msg for devices not in D0. Further, read_msi_msg_desc() should only ever be used to update a previously written message, so it can always read msi_desc::msg and never needs to touch the hardware. Tested-by: "Michael Chan" Signed-off-by: Ben Hutchings Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 9d550e4071d7734f3dc4ec8a10971091782f281e Author: Suresh Siddha Date: Thu Aug 19 17:03:38 2010 -0700 x86, tsc, sched: Recompute cyc2ns_offset's during resume from sleep states commit cd7240c0b900eb6d690ccee088a6c9b46dae815a upstream. TSC's get reset after suspend/resume (even on cpu's with invariant TSC which runs at a constant rate across ACPI P-, C- and T-states). And in some systems BIOS seem to reinit TSC to arbitrary large value (still sync'd across cpu's) during resume. This leads to a scenario of scheduler rq->clock (sched_clock_cpu()) less than rq->age_stamp (introduced in 2.6.32). This leads to a big value returned by scale_rt_power() and the resulting big group power set by the update_group_power() is causing improper load balancing between busy and idle cpu's after suspend/resume. This resulted in multi-threaded workloads (like kernel-compilation) go slower after suspend/resume cycle on core i5 laptops. Fix this by recomputing cyc2ns_offset's during resume, so that sched_clock() continues from the point where it was left off during suspend. Reported-by: Florian Pritz Signed-off-by: Suresh Siddha Signed-off-by: Peter Zijlstra LKML-Reference: <1282262618.2675.24.camel@sbsiddha-MOBL3.sc.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e400b099fd811ffd80830c55f074a8b1281ab0be Author: Mark Lord Date: Thu Aug 19 21:40:44 2010 -0400 sata_mv: fix broken DSM/TRIM support (v2) commit 44b733809a5aba7f6b15a548d31a56d25bf3851c upstream. Fix DSM/TRIM commands in sata_mv (v2). These need to be issued using old-school "BM DMA", rather than via the EDMA host queue. Since the chips don't have proper BM DMA status, we need to be more careful with setting the ATA_DMA_INTR bit, since DSM/TRIM often has a long delay between "DMA complete" and "command complete". GEN_I chips don't have BM DMA, so no TRIM for them. Signed-off-by: Mark Lord Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit eeee02441b1a6063313b31d37b6eba601e48fe42 Author: David Henningsson Date: Thu Jul 29 14:46:42 2010 +0200 ALSA: hda - Rename iMic to Int Mic on Lenovo NB0763 commit 150b432f448281d5518f5229d240923f9a9c5459 upstream. The non-standard name "iMic" makes PulseAudio ignore the microphone. BugLink: https://launchpad.net/bugs/605101 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c7b28349a66e0aa9a24872dfc55a5296fc01a360 Author: Jeremy Fitzhardinge Date: Fri Aug 20 18:57:53 2010 -0700 xen: use percpu interrupts for IPIs and VIRQs commit aaca49642b92c8a57d3ca5029a5a94019c7af69f upstream. IPIs and VIRQs are inherently per-cpu event types, so treat them as such: - use a specific percpu irq_chip implementation, and - handle them with handle_percpu_irq This makes the path for delivering these interrupts more efficient (no masking/unmasking, no locks), and it avoid problems with attempts to migrate them. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit c5783925493e315f91330241546da7915dcc46e3 Author: Jeremy Fitzhardinge Date: Fri Aug 20 19:10:01 2010 -0700 xen: handle events as edge-triggered commit dffe2e1e1a1ddb566a76266136c312801c66dcf7 upstream. Xen events are logically edge triggered, as Xen only calls the event upcall when an event is newly set, but not continuously as it remains set. As a result, use handle_edge_irq rather than handle_level_irq. This has the important side-effect of fixing a long-standing bug of events getting lost if: - an event's interrupt handler is running - the event is migrated to a different vcpu - the event is re-triggered The most noticable symptom of these lost events is occasional lockups of blkfront. Many thanks to Tom Kopec and Daniel Stodden in tracking this down. Signed-off-by: Jeremy Fitzhardinge Cc: Tom Kopec Cc: Daniel Stodden Signed-off-by: Greg Kroah-Hartman commit 0f1c8eaac1476a3c03743fa543bc110d5a53ff76 Author: Andreas Herrmann Date: Wed Aug 25 15:42:12 2010 +0200 hwmon: (k8temp) Differentiate between AM2 and ASB1 commit a05e93f3b3fc2f53c1d0de3b17019e207c482349 upstream. Commit 8bf0223ed515be24de0c671eedaff49e78bebc9c (hwmon, k8temp: Fix temperature reporting for ASB1 processor revisions) fixed temperature reporting for ASB1 CPUs. But those CPU models (model 0x6b, 0x6f, 0x7f) were packaged both as AM2 (desktop) and ASB1 (mobile). Thus the commit leads to wrong temperature reporting for AM2 CPU parts. The solution is to determine the package type for models 0x6b, 0x6f, 0x7f. This is done using BrandId from CPUID Fn8000_0001_EBX[15:0]. See "Constructing the processor Name String" in "Revision Guide for AMD NPT Family 0Fh Processors" (Rev. 3.46). Cc: Rudolf Marek Reported-by: Vladislav Guberinic Signed-off-by: Andreas Herrmann Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman