TTY: make tty_add_file non-failing

commit fa90e1c935472281de314e6d7c9a37db9cbc2e4e upstream.

If tty_add_file fails at the point it is now, we have to revert all
the changes we did to the tty. It means either decrease all refcounts
if this was a tty reopen or delete the tty if it was newly allocated.

There was a try to fix this in v3.0-rc2 using tty_release in 0259894c7
(TTY: fix fail path in tty_open). But instead it introduced a NULL
dereference. It's because tty_release dereferences
filp->private_data, but that one is set even in our tty_add_file. And
when tty_add_file fails, it's still NULL/garbage. Hence tty_release
cannot be called there.

To circumvent the original leak (and the current NULL deref) we split
tty_add_file into two functions, making the latter non-failing. In
that case we may do the former early in open, where handling failures
is easy. The latter stays as it is now. So there is no change in
functionality.

The original bug (leak) was introduced by f573bd176 (tty: Remove
__GFP_NOFAIL from tty_add_file()). Thanks Dan for reporting this.

Later, we may split tty_release into more functions and call only some
of them in this fail path instead. (If at all possible.)

Introduced-in: v2.6.37-rc2
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
TTY: pty, release tty in all ptmx_open fail paths

commit 1177c0efc04d032644895b8d757f55b433912596 upstream.

Mistakenly, commit 64ba3dc3143d (tty: never hold BTM while getting
tty_mutex) switched one fail path in ptmx_open to not free the newly
allocated tty.

Fix that by jumping to the appropriate place. And rename the labels so
that it's clear what is going on there.

Introduced-in: v2.6.36-rc2
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: for usb_autopm_get_interface_async -EINPROGRESS is not an error

commit c5a48592d874ddef8c7880311581eccf0eb30c3b upstream.

A return value of -EINPROGRESS from pm_runtime_get indicates that
the device is already resuming due to a previous call.  Internally,
usb_autopm_get_interface_async doesn't treat this as an error and
increments the usage count, but passes the error status along
to the caller.  The logical assumption of the caller is that
any negative return value reflects the device not resuming
and the pm_usage_cnt not being incremented.  Since the usage count
is being incremented and the device is resuming, return success (0)
instead.

Signed-off-by: James Wylder <james.wylder@motorola.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: serqt_usb2: remove ssu100 from supported devices

commit 7cbf3c7cd59288fb5e9f31815c74773549668d43 upstream.

The serqt_usb2 driver will not work properly with the ssu100 device
even though it claims to support it.  The ssu100 is supported by the
ssu100 driver in mainline so there is no need to have it claimed by
serqt_usb2.

Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: quatech_usb2: Potential lost wakeup scenario in TIOCMIWAIT

commit e8df1674d383d2ecc6efa8d7dba74c03aafdfdd7 upstream.

If the usermode app does an ioctl over this serial device  by
using TIOCMIWAIT, then the code will wait by setting the current
task state to TASK_INTERRUPTIBLE and then calling schedule().
This will be woken up by the qt2_process_modem_status on URB
completion when the port_extra->shadowMSR is set to the new
modem status.

However, this could result in a lost wakeup scenario due to a race
in the logic in the qt2_ioctl(TIOCMIWAIT) loop and the URB completion
for new modem status in qt2_process_modem_status.
Due to this, the usermode app's task will continue to sleep despite a
change in the modem status.

Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: hv: Add support for >2 TB LUN in storage driver.

commit cf55f4a8b6243b42fb91c56d1421db0d36d60f96 upstream.

If a LUN larger than 2 TB is attached to a Linux VM on Hyper-V, we currently
report a maximum size of 2 TB. This patch resolves the issue in hv_storvsc.
Thanks to Robert Scheck <robert.scheck@etes.de> for reporting the issue.

Reported-by: Robert Scheck <robert.scheck@etes.de>
Signed-off-by: Mike Sterling <mike.sterling@microsoft.com>
Signed-off-by: K.Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: qcserial: Add support for Sierra Wireless MC8355/Gobi 3000

commit 68c79e5756903229fa96826a2493c2265a3b395f upstream.

Simple patch to make qcserial recognize the USB id of the Sierra
Wireless MC8355 which is based on the Gobi 3000 chip.

Both UMTS and GPS work fine.

Signed-off-by: Richard Hartmann <richih.mailinglist@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>