linux, branch v3.4.85

Linux 3.4.85

2014-03-31T04:40:45Z

ipc/msg: fix race around refcount

2014-03-31T04:40:31Z

[fixed differently in 6062a8dc0517bce23e3c2f7d2fea5e22411269a3 upstream.] In older kernels (before v3.10) ipc_rcu_hdr->refcount was non-atomic int. There was possuble double-free bug: do_msgsnd() calls ipc_rcu_putref() under msq->q_perm->lock and RCU, while freequeue() calls it while it holds only 'rw_mutex', so there is no sinchronization between them. Two function decrements '2' non-atomically, they both can get '0' as result. do_msgsnd() freequeue() msq = msg_lock_check(ns, msqid); ... ipc_rcu_getref(msq); msg_unlock(msq); schedule(); (caller locks spinlock) expunge_all(msq, -EIDRM); ss_wakeup(&msq->q_senders, 1); msg_rmid(ns, msq); msg_unlock(msq); ipc_lock_by_ptr(&msq->q_perm); ipc_rcu_putref(msq); ipc_rcu_putref(msq); < both may get get --(...)->refcount == 0 > This patch locks ipc_lock and RCU around ipc_rcu_putref in freequeue. ( RCU protects memory for spin_unlock() ) Similar bugs might be in other users of ipc_rcu_putref(). In the mainline this has been fixed in v3.10 indirectly in commmit 6062a8dc0517bce23e3c2f7d2fea5e22411269a3 ("ipc,sem: fine grained locking for semtimedop") by Rik van Riel. That commit optimized locking and converted refcount into atomic. I'm not sure that anybody should care about this bug: it's very-very unlikely and no longer exists in actual mainline. I've found this just by looking into the code, probably this never happens in real life. Signed-off-by: Konstantin Khlebnikov

xhci: Fix resume issues on Renesas chips in Samsung laptops

2014-03-31T04:40:31Z

commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d upstream. Don Zickus writes: Some co-workers of mine bought Samsung laptops that had mostly usb3 ports. Those ports did not resume correctly (the driver would timeout communicating and fail). This led to frustration as suspend/resume is a common use for laptops. Poking around, I applied the reset on resume quirk to this chipset and the resume started working. Reloading the xhci_hcd module had been the temporary workaround. Signed-off-by: Sarah Sharp Reported-by: Don Zickus Tested-by: Prarit Bhargava Signed-off-by: Greg Kroah-Hartman

KVM: VMX: fix use after free of vmx->loaded_vmcs

2014-03-31T04:40:31Z

commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream. After free_loaded_vmcs executes, the "loaded_vmcs" structure is kfreed, and now vmx->loaded_vmcs points to a kfreed area. Subsequent free_loaded_vmcs then attempts to manipulate vmx->loaded_vmcs. Switch the order to avoid the problem. https://bugzilla.redhat.com/show_bug.cgi?id=1047892 Reviewed-by: Jan Kiszka Signed-off-by: Marcelo Tosatti Cc: Josh Boyer Signed-off-by: Greg Kroah-Hartman

KVM: MMU: handle invalid root_hpa at __direct_map

2014-03-31T04:40:31Z

commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream. It is possible for __direct_map to be called on invalid root_hpa (-1), two examples: 1) try_async_pf -> can_do_async_pf -> vmx_interrupt_allowed -> nested_vmx_vmexit 2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit Then to load_vmcs12_host_state and kvm_mmu_reset_context. Check for this possibility, let fault exception be regenerated. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916 Signed-off-by: Marcelo Tosatti Signed-off-by: Paolo Bonzini Cc: Josh Boyer Signed-off-by: Greg Kroah-Hartman

Input: elantech - improve clickpad detection

2014-03-31T04:40:30Z

commit c15bdfd5b9831e4cab8cfc118243956e267dd30e upstream. The current assumption in the elantech driver that hw version 3 touchpads are never clickpads and hw version 4 touchpads are always clickpads is wrong. There are several bug reports for this, ie: https://bugzilla.redhat.com/show_bug.cgi?id=1030802 http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux I've spend a couple of hours wading through various bugzillas, launchpads and forum posts to create a list of fw-versions and capabilities for different laptop models to find a good method to differentiate between clickpads and versions with separate hardware buttons. Which shows that a device being a clickpad is reliable indicated by bit 12 being set in the fw_version. I've included the gathered list inside the driver, so that we've this info at hand if we need to revisit this later. Signed-off-by: Hans de Goede Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Cc: Josh Boyer Signed-off-by: Greg Kroah-Hartman

ARM: move outer_cache declaration out of ifdef

2014-03-31T04:40:30Z

commit 0b53c11d533a8f6688d73fad0baf67dd08ec1b90 upstream. Move the outer_cache declaration of the CONFIG_OUTER_CACHE ifdef so that outer_cache can be used inside IS_ENABLED condition. Signed-off-by: Rob Herring Cc: Russell King Signed-off-by: Ian Campbell Signed-off-by: Greg Kroah-Hartman

i7300_edac: Fix device reference count

2014-03-31T04:40:30Z

commit 75135da0d68419ef8a925f4c1d5f63d8046e314d upstream. pci_get_device() decrements the reference count of "from" (last argument) so when we break off the loop successfully we have only one device reference - and we don't know which device we have. If we want a reference to each device, we must take them explicitly and let the pci_get_device() walk complete to avoid duplicate references. This is serious, as over-putting device references will cause the device to eventually disappear. Without this fix, the kernel crashes after a few insmod/rmmod cycles. Tested on an Intel S7000FC4UR system with a 7300 chipset. Signed-off-by: Jean Delvare Link: http://lkml.kernel.org/r/20140224111656.09bbb7ed@endymion.delvare Cc: Mauro Carvalho Chehab Cc: Doug Thompson Cc: stable@vger.kernel.org Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman

p54: clamp properly instead of just truncating

2014-03-31T04:40:30Z

commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream. The call to clamp_t() first truncates the variable signed 8 bit and as a result, the actual clamp is a no-op. Fixes: 0d78156eef1d ('p54: improve site survey') Signed-off-by: Dan Carpenter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

deb-pkg: Fix cross-building linux-headers package

2014-03-31T04:40:30Z

commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream. builddeb generates a control file that says the linux-headers package can only be built for the build system primary architecture. This breaks cross-building configurations. We should use $debarch for this instead. Since $debarch is not yet set when generating the control file, set Architecture: any and use control file variables to fill in the description. Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg') Reported-and-tested-by: "Niew, Sh." Signed-off-by: Ben Hutchings Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman