kernel/linux.git, branch v3.0.44

Linux 3.0.44

2012-10-02T16:50:36+00:00

ARM: 7467/1: mutex: use generic xchg-based implementation for ARMv6+

2012-10-02T16:47:55+00:00

commit a76d7bd96d65fa5119adba97e1b58d95f2e78829 upstream. The open-coded mutex implementation for ARMv6+ cores suffers from a severe lack of barriers, so in the uncontended case we don't actually protect any accesses performed during the critical section. Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec code but optimised to remove a branch instruction, as the mutex fastpath was previously inlined. Now that this is executed out-of-line, we can reuse the atomic access code for the locking (in fact, we use the xchg code as this produces shorter critical sections). This patch uses the generic xchg based implementation for mutexes on ARMv6+, which introduces barriers to the lock/unlock operations and also has the benefit of removing a fair amount of inline assembly code. Acked-by: Arnd Bergmann Acked-by: Nicolas Pitre Reported-by: Shan Kang Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

USB: Fix race condition when removing host controllers

2012-10-02T16:47:55+00:00

commit 0d00dc2611abbe6ad244d50569c2ee82ce42846c upstream. This patch (as1607) fixes a race that can occur if a USB host controller is removed while a process is reading the /sys/kernel/debug/usb/devices file. The usb_device_read() routine uses the bus->root_hub pointer to determine whether or not the root hub is registered. The is not a valid test, because the pointer is set before the root hub gets registered and remains set even after the root hub is unregistered and deallocated. As a result, usb_device_read() or usb_device_dump() can access freed memory, causing an oops. The patch changes the test to use the hcd->rh_registered flag, which does get set and cleared at the appropriate times. It also makes sure to hold the usb_bus_list_lock mutex while setting the flag, so that usb_device_read() will become aware of new root hubs as soon as they are registered. Signed-off-by: Alan Stern Reported-by: Don Zickus Signed-off-by: Greg Kroah-Hartman

MCE: Fix vm86 handling for 32bit mce handler

2012-10-02T16:47:55+00:00

commit a129a7c84582629741e5fa6f40026efcd7a65bd4 upstream. When running on 32bit the mce handler could misinterpret vm86 mode as ring 0. This can affect whether it does recovery or not; it was possible to panic when recovery was actually possible. Fix this by always forcing vm86 to look like ring 3. [ Backport to 3.0 notes: Things changed there slightly: - move mce_get_rip() up. It fills up m->cs and m->ip values which are evaluated in mce_severity(). Therefore move it up right before the mce_severity call. This seem to be another bug in 3.0? - Place the backport (fix m->cs in V86 case) to where m->cs gets filled which is mce_get_rip() in 3.0 ] Signed-off-by: Andi Kleen Signed-off-by: Tony Luck Signed-off-by: Thomas Renninger Reviewed-by: Tony Luck Signed-off-by: Greg Kroah-Hartman

sched: Fix ancient race in do_exit()

2012-10-02T16:47:55+00:00

commit b5740f4b2cb3503b436925eb2242bc3d75cd3dfe upstream. try_to_wake_up() has a problem which may change status from TASK_DEAD to TASK_RUNNING in race condition with SMI or guest environment of virtual machine. As a result, exited task is scheduled() again and panic occurs. Here is the sequence how it occurs: ----------------------------------+----------------------------- | CPU A | CPU B ----------------------------------+----------------------------- TASK A calls exit().... do_exit() exit_mm() down_read(mm->mmap_sem); rwsem_down_failed_common() set TASK_UNINTERRUPTIBLE set waiter.task <= task A list_add to sem->wait_list : raw_spin_unlock_irq() (I/O interruption occured) __rwsem_do_wake(mmap_sem) list_del(&waiter->list); waiter->task = NULL wake_up_process(task A) try_to_wake_up() (task is still TASK_UNINTERRUPTIBLE) p->on_rq is still 1.) ttwu_do_wakeup() (*A) : (I/O interruption handler finished) if (!waiter.task) schedule() is not called due to waiter.task is NULL. tsk->state = TASK_RUNNING : check_preempt_curr(); : task->state = TASK_DEAD (*B) <--- set TASK_RUNNING (*C) schedule() (exit task is running again) BUG_ON() is called! -------------------------------------------------------- The execution time between (*A) and (*B) is usually very short, because the interruption is disabled, and setting TASK_RUNNING at (*C) must be executed before setting TASK_DEAD. HOWEVER, if SMI is interrupted between (*A) and (*B), (*C) is able to execute AFTER setting TASK_DEAD! Then, exited task is scheduled again, and BUG_ON() is called.... If the system works on guest system of virtual machine, the time between (*A) and (*B) may be also long due to scheduling of hypervisor, and same phenomenon can occur. By this patch, do_exit() waits for releasing task->pi_lock which is used in try_to_wake_up(). It guarantees the task becomes TASK_DEAD after waking up. Signed-off-by: Yasunori Goto Acked-by: Oleg Nesterov Signed-off-by: Peter Zijlstra Cc: Linus Torvalds Cc: Andrew Morton Link: http://lkml.kernel.org/r/20120117174031.3118.E1E9C6FF@jp.fujitsu.com Signed-off-by: Ingo Molnar Cc: Michal Hocko Signed-off-by: Greg Kroah-Hartman

spi/spi-fsl-spi: reference correct pdata in fsl_spi_cs_control

2012-10-02T16:47:54+00:00

commit 067aa4815a9bc12a569d8a06afef50ba5773afbf upstream. Commit 178db7d3, "spi: Fix device unregistration when unregistering the bus master", changed spi device initialization of dev.parent pointer to be the master's device pointer instead of his parent. This introduced a bug in spi-fsl-spi, since its usage of spi device pointer was not updated accordingly. This was later fixed by commit 5039a86, "spi/mpc83xx: fix NULL pdata dereference bug", but it missed another spot on fsl_spi_cs_control function where we also need to update usage of spi device pointer. This change address that. Signed-off-by: Herton Ronaldo Krzesinski Acked-by: Joakim Tjernlund Signed-off-by: Grant Likely Cc: Alfredo Capella Signed-off-by: Greg Kroah-Hartman

spi/mpc83xx: fix NULL pdata dereference bug

2012-10-02T16:47:54+00:00

commit 5039a86973cd35bdb2f64d28ee12f13fe2bb5a4c upstream. Commit 178db7d3, "spi: Fix device unregistration when unregistering the bus master", changed device initialization to be children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization. Signed-off-by: Kenth Eriksson Acked-by: Joakim Tjernlund Signed-off-by: Grant Likely Cc: Alfredo Capella Signed-off-by: Greg Kroah-Hartman

UBI: fix a horrible memory deallocation bug

2012-10-02T16:47:54+00:00

commit 78b495c39add820ab66ab897af9bd77a5f2e91f6 upstream UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened only when we were doing auto-format, so many systems were unaffected. However, there are still many users affected. It is strange, but the system did not crash and nothing bad happened when the SLUB memory allocator was used. However, in case of SLOB we observed an crash right away. This problem was introduced in 2.6.39 by commit "6c1e875 UBI: add slab cache for ubi_scan_leb objects" Reported-by: Richard Genoud Signed-off-by: Artem Bityutskiy Signed-off-by: Richard Genoud Signed-off-by: Greg Kroah-Hartman

e1000e: Disable ASPM L1 on 82574

2012-10-02T16:47:54+00:00

commit d4a4206ebbaf48b55803a7eb34e330530d83a889 upstream. ASPM on the 82574 causes trouble. Currently the driver disables L0s for this NIC but only disables L1 if the MTU is >1500. This patch simply causes L1 to be disabled regardless of the MTU setting. Signed-off-by: Chris Boot Cc: "Wyborny, Carolyn" Cc: Nix Link: https://lkml.org/lkml/2012/3/19/362 Tested-by: Jeff Pieper Signed-off-by: Jeff Kirsher Signed-off-by: Nikola Ciprich Signed-off-by: Greg Kroah-Hartman

mmc: Prevent 1.8V switch for SD hosts that don't support UHS modes.

2012-10-02T16:47:54+00:00

commit 4188bba0e9e7ba58d231b528df495666f2742b74 upstream. The driver should not try to switch to 1.8V when the SD 3.0 host controller does not have any UHS capabilities bits set (SDR50, DDR50 or SDR104). See page 72 of "SD Specifications Part A2 SD Host Controller Simplified Specification Version 3.00" under "1.8V Signaling Enable". Instead of setting SDR12 and SDR25 in the host capabilities data structure for all V3.0 host controllers, only set them if SDR104, SDR50 or DDR50 is set in the host capabilities register. This will prevent the switch to 1.8V later. Signed-off-by: Al Cooper Acked-by: Arindam Nath Acked-by: Philip Rakity Acked-by: Girish K S Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman