linux-stable.git, branch v3.12.16

Linux 3.12.16

2014-03-31T12:23:22+00:00

libceph: fix preallocation check in get_reply()

2014-03-31T12:22:36+00:00

commit f2be82b0058e90b5d9ac2cb896b4914276fb50ef upstream.

The check that makes sure that we have enough memory allocated to read
in the entire header of the message in question is currently busted.
It compares front_len of the incoming message with iov_len field of
ceph_msg::front structure, which is used primarily to indicate the
amount of data already read in, and not the size of the allocated
buffer.  Under certain conditions (e.g. a short read from a socket
followed by that socket's shutdown and owning ceph_connection reset)
this results in a warning similar to

[85688.975866] libceph: get_reply front 198 > preallocated 122 (4#0)

and, through another bug, leads to forever hung tasks and forced
reboots.  Fix this by comparing front_len with front_alloc_len field of
struct ceph_msg, which stores the actual size of the buffer.

Fixes: http://tracker.ceph.com/issues/5425

Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil 
Signed-off-by: Jiri Slaby

libceph: rename front to front_len in get_reply()

2014-03-31T12:22:35+00:00

commit 3f0a4ac55fe036902e3666be740da63528ad8639 upstream.

Rename front local variable to front_len in get_reply() to make its
purpose more clear.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil 
Signed-off-by: Jiri Slaby

libceph: rename ceph_msg::front_max to front_alloc_len

2014-03-31T12:22:35+00:00

commit 3cea4c3071d4e55e9d7356efe9d0ebf92f0c2204 upstream.

Rename front_max field of struct ceph_msg to front_alloc_len to make
its purpose more clear.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil 
Signed-off-by: Jiri Slaby

e100: Fix "disabling already-disabled device" warning

2014-03-31T12:22:34+00:00

commit 2b6e0ca175fe4a20f21ba82b1e7ccc71029c4dd4 upstream.

In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
https://bugzilla.redhat.com/show_bug.cgi?id=970480  we
received different reports of e100 throwing the following
warning:

 [] ? pci_disable_device+0x85/0x90
 [] warn_slowpath_fmt+0x33/0x40
 [] pci_disable_device+0x85/0x90
 [] __e100_shutdown+0x80/0x120 [e100]
 [] ? check_preempt_curr+0x65/0x90
 [] e100_suspend+0x16/0x30 [e100]
 [] pci_legacy_suspend+0x2b/0xb0
 [] ? wait_for_completion+0x1f/0xd0
 [] ? pci_pm_poweroff+0xb0/0xb0
 [] pci_pm_freeze+0x94/0xa0
 [] dpm_run_callback+0x37/0x80
 [] ? pm_wakeup_pending+0xc4/0x140
 [] __device_suspend+0xb2/0x1f0
 [] async_suspend+0x1f/0x90
 [] async_run_entry_fn+0x35/0x140
 [] ? wake_up_process+0x1f/0x40
 [] process_one_work+0x115/0x370
 [] ? start_worker+0x25/0x30
 [] ? manage_workers.isra.27+0x1a5/0x250
 [] worker_thread+0xfe/0x330
 [] ? manage_workers.isra.27+0x250/0x250
 [] kthread+0x94/0xa0
 [] ret_from_kernel_thread+0x1b/0x28
 [] ? insert_kthread_work+0x30/0x30

This patch removes pci_disable_device() from __e100_shutdown().
pci_clear_master() is enough.

Signed-off-by: Michele Baldessari 
Tested-by: Mark Harig 
Signed-off-by: Aaron Brown 
Signed-off-by: David S. Miller 
Cc: Josh Boyer 
Signed-off-by: Jiri Slaby

xhci: Fix resume issues on Renesas chips in Samsung laptops

2014-03-31T12:22:34+00:00

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: Jiri Slaby

Input: wacom - make sure touch_max is set for touch devices

2014-03-31T12:22:34+00:00

commit 1d0d6df02750b4a6f466768cbfbf860e24f4c8d4 upstream.

Old single touch Tablet PCs do not have touch_max set at
wacom_features. Since touch device at lease supports one
finger, assign touch_max to 1 when touch usage is defined
in its HID Descriptor and touch_max is not pre-defined.

Tested-by: Jason Gerecke 
Signed-off-by: Ping Cheng 
Reviewed-by: Chris Bagwell 
Signed-off-by: Dmitry Torokhov 
Cc: Josh Boyer 
Signed-off-by: Jiri Slaby

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

2014-03-31T12:22:33+00:00

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: Jiri Slaby

KVM: x86: handle invalid root_hpa everywhere

2014-03-31T12:22:33+00:00

commit 37f6a4e237303549c8676dfe1fd1991ceab512eb upstream.

Rom Freiman  notes other code paths vulnerable to
bug fixed by 989c6b34f6a9480e397b.

Signed-off-by: Marcelo Tosatti 
Cc: Josh Boyer 
Signed-off-by: Jiri Slaby

KVM: MMU: handle invalid root_hpa at __direct_map

2014-03-31T12:22:32+00:00

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: Jiri Slaby