--- /dev/null
+From d09960b0032174eb493c4c13be5b9c9ef36dc9a7 Mon Sep 17 00:00:00 2001
+From: Tahsin Erdogan <tahsin@google.com>
+Date: Mon, 10 Oct 2016 05:35:19 -0700
+Subject: dm: free io_barrier after blk_cleanup_queue call
+
+From: Tahsin Erdogan <tahsin@google.com>
+
+commit d09960b0032174eb493c4c13be5b9c9ef36dc9a7 upstream.
+
+dm_old_request_fn() has paths that access md->io_barrier. The party
+destroying io_barrier should ensure that no future execution of
+dm_old_request_fn() is possible. Move io_barrier destruction to below
+blk_cleanup_queue() to ensure this and avoid a NULL pointer crash during
+request-based DM device shutdown.
+
+Signed-off-by: Tahsin Erdogan <tahsin@google.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/md/dm.c
++++ b/drivers/md/dm.c
+@@ -2260,8 +2260,6 @@ static void cleanup_mapped_device(struct
+ if (md->bs)
+ bioset_free(md->bs);
+
+- cleanup_srcu_struct(&md->io_barrier);
+-
+ if (md->disk) {
+ spin_lock(&_minor_lock);
+ md->disk->private_data = NULL;
+@@ -2273,6 +2271,8 @@ static void cleanup_mapped_device(struct
+ if (md->queue)
+ blk_cleanup_queue(md->queue);
+
++ cleanup_srcu_struct(&md->io_barrier);
++
+ if (md->bdev) {
+ bdput(md->bdev);
+ md->bdev = NULL;
--- /dev/null
+From foo@baz Tue Nov 8 11:17:00 CET 2016
+Date: Tue, 08 Nov 2016 11:17:00 +0100
+To: Greg KH <gregkh@linuxfoundation.org>
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Subject: Fix potential infoleak in older kernels
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+Not upstream as it is not needed there.
+
+So a patch something like this might be a safe way to fix the
+potential infoleak in older kernels.
+
+THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles
+it probably works. It just initializes the output variable with 0 in
+the inline asm description, instead of doing it in the exception
+handler.
+
+It will generate slightly worse code (a few unnecessary ALU
+operations), but it doesn't have any interactions with the exception
+handler implementation.
+
+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/uaccess.h | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/include/asm/uaccess.h
++++ b/arch/x86/include/asm/uaccess.h
+@@ -332,7 +332,7 @@ do { \
+ #define __get_user_asm_u64(x, ptr, retval, errret) \
+ __get_user_asm(x, ptr, retval, "q", "", "=r", errret)
+ #define __get_user_asm_ex_u64(x, ptr) \
+- __get_user_asm_ex(x, ptr, "q", "", "=r")
++ __get_user_asm_ex(x, ptr, "q", "", "=&r")
+ #endif
+
+ #define __get_user_size(x, ptr, size, retval, errret) \
+@@ -375,13 +375,13 @@ do { \
+ __chk_user_ptr(ptr); \
+ switch (size) { \
+ case 1: \
+- __get_user_asm_ex(x, ptr, "b", "b", "=q"); \
++ __get_user_asm_ex(x, ptr, "b", "b", "=&q"); \
+ break; \
+ case 2: \
+- __get_user_asm_ex(x, ptr, "w", "w", "=r"); \
++ __get_user_asm_ex(x, ptr, "w", "w", "=&r"); \
+ break; \
+ case 4: \
+- __get_user_asm_ex(x, ptr, "l", "k", "=r"); \
++ __get_user_asm_ex(x, ptr, "l", "k", "=&r"); \
+ break; \
+ case 8: \
+ __get_user_asm_ex_u64(x, ptr); \
+@@ -395,7 +395,7 @@ do { \
+ asm volatile("1: mov"itype" %1,%"rtype"0\n" \
+ "2:\n" \
+ _ASM_EXTABLE_EX(1b, 2b) \
+- : ltype(x) : "m" (__m(addr)))
++ : ltype(x) : "m" (__m(addr)), "0" (0))
+
+ #define __put_user_nocheck(x, ptr, size) \
+ ({ \
--- /dev/null
+From 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c Mon Sep 17 00:00:00 2001
+From: Long Li <longli@microsoft.com>
+Date: Wed, 5 Oct 2016 16:57:46 -0700
+Subject: hv: do not lose pending heartbeat vmbus packets
+
+From: Long Li <longli@microsoft.com>
+
+commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c upstream.
+
+The host keeps sending heartbeat packets independent of the
+guest responding to them. Even though we respond to the heartbeat messages at
+interrupt level, we can have situations where there maybe multiple heartbeat
+messages pending that have not been responded to. For instance this occurs when the
+VM is paused and the host continues to send the heartbeat messages.
+Address this issue by draining and responding to all
+the heartbeat messages that maybe pending.
+
+Signed-off-by: Long Li <longli@microsoft.com>
+Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hv/hv_util.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/hv/hv_util.c
++++ b/drivers/hv/hv_util.c
+@@ -283,10 +283,14 @@ static void heartbeat_onchannelcallback(
+ u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
+ struct icmsg_negotiate *negop = NULL;
+
+- vmbus_recvpacket(channel, hbeat_txf_buf,
+- PAGE_SIZE, &recvlen, &requestid);
++ while (1) {
++
++ vmbus_recvpacket(channel, hbeat_txf_buf,
++ PAGE_SIZE, &recvlen, &requestid);
++
++ if (!recvlen)
++ break;
+
+- if (recvlen > 0) {
+ icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
+ sizeof(struct vmbuspipe_hdr)];
+
xhci-use-default-usb_resume_timeout-when-resuming-ports.patch
usb-increase-ohci-watchdog-delay-to-275-msec.patch
genwqe-fix-bad-page-access-during-abort-of-resource-allocation.patch
+fix-potential-infoleak-in-older-kernels.patch
+vt-clear-selection-before-resizing.patch
+hv-do-not-lose-pending-heartbeat-vmbus-packets.patch
+xhci-add-restart-quirk-for-intel-wildcatpoint-pch.patch
+tty-limit-terminal-size-to-4m-chars.patch
+usb-serial-cp210x-fix-tiocmget-error-handling.patch
+dm-free-io_barrier-after-blk_cleanup_queue-call.patch
--- /dev/null
+From 32b2921e6a7461fe63b71217067a6cf4bddb132f Mon Sep 17 00:00:00 2001
+From: Dmitry Vyukov <dvyukov@google.com>
+Date: Fri, 14 Oct 2016 15:18:28 +0200
+Subject: tty: limit terminal size to 4M chars
+
+From: Dmitry Vyukov <dvyukov@google.com>
+
+commit 32b2921e6a7461fe63b71217067a6cf4bddb132f upstream.
+
+Size of kmalloc() in vc_do_resize() is controlled by user.
+Too large kmalloc() size triggers WARNING message on console.
+Put a reasonable upper bound on terminal size to prevent WARNINGs.
+
+Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
+CC: David Rientjes <rientjes@google.com>
+Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Jiri Slaby <jslaby@suse.com>
+Cc: Peter Hurley <peter@hurleysoftware.com>
+Cc: linux-kernel@vger.kernel.org
+Cc: syzkaller@googlegroups.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/vt.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/tty/vt/vt.c
++++ b/drivers/tty/vt/vt.c
+@@ -872,6 +872,8 @@ static int vc_do_resize(struct tty_struc
+ if (new_cols == vc->vc_cols && new_rows == vc->vc_rows)
+ return 0;
+
++ if (new_screen_size > (4 << 20))
++ return -EINVAL;
+ newscreen = kmalloc(new_screen_size, GFP_USER);
+ if (!newscreen)
+ return -ENOMEM;
--- /dev/null
+From de24e0a108bc48062e1c7acaa97014bce32a919f Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Wed, 19 Oct 2016 15:45:07 +0200
+Subject: USB: serial: cp210x: fix tiocmget error handling
+
+From: Johan Hovold <johan@kernel.org>
+
+commit de24e0a108bc48062e1c7acaa97014bce32a919f upstream.
+
+The current tiocmget implementation would fail to report errors up the
+stack and instead leaked a few bits from the stack as a mask of
+modem-status flags.
+
+Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/cp210x.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/serial/cp210x.c
++++ b/drivers/usb/serial/cp210x.c
+@@ -845,7 +845,9 @@ static int cp210x_tiocmget(struct tty_st
+ unsigned int control;
+ int result;
+
+- cp210x_get_config(port, CP210X_GET_MDMSTS, &control, 1);
++ result = cp210x_get_config(port, CP210X_GET_MDMSTS, &control, 1);
++ if (result)
++ return result;
+
+ result = ((control & CONTROL_DTR) ? TIOCM_DTR : 0)
+ |((control & CONTROL_RTS) ? TIOCM_RTS : 0)
--- /dev/null
+From 009e39ae44f4191188aeb6dfbf661b771dbbe515 Mon Sep 17 00:00:00 2001
+From: Scot Doyle <lkml14@scotdoyle.com>
+Date: Thu, 13 Oct 2016 12:12:43 -0500
+Subject: vt: clear selection before resizing
+
+From: Scot Doyle <lkml14@scotdoyle.com>
+
+commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 upstream.
+
+When resizing a vt its selection may exceed the new size, resulting in
+an invalid memory access [1]. Clear the selection before resizing.
+
+[1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com
+
+Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
+Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/vt.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/tty/vt/vt.c
++++ b/drivers/tty/vt/vt.c
+@@ -876,6 +876,9 @@ static int vc_do_resize(struct tty_struc
+ if (!newscreen)
+ return -ENOMEM;
+
++ if (vc == sel_cons)
++ clear_selection();
++
+ old_rows = vc->vc_rows;
+ old_row_size = vc->vc_size_row;
+
--- /dev/null
+From 4c39135aa412d2f1381e43802523da110ca7855c Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Thu, 20 Oct 2016 18:09:18 +0300
+Subject: xhci: add restart quirk for Intel Wildcatpoint PCH
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 4c39135aa412d2f1381e43802523da110ca7855c upstream.
+
+xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the
+same quirks to prevent machines from spurious restart while
+shutting them down.
+
+Reported-by: Hasan Mahmood <hasan.mahm@gmail.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-pci.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -45,6 +45,7 @@
+
+ #define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI 0x8c31
+ #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI 0x9c31
++#define PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_XHCI 0x9cb1
+ #define PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI 0x22b5
+ #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI 0xa12f
+ #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI 0x9d2f
+@@ -154,7 +155,8 @@ static void xhci_pci_quirks(struct devic
+ xhci->quirks |= XHCI_SPURIOUS_REBOOT;
+ }
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+- pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
++ (pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI ||
++ pdev->device == PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_XHCI)) {
+ xhci->quirks |= XHCI_SPURIOUS_REBOOT;
+ xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+ }