--- /dev/null
+From 5d07384a666d4b2f781dc056bfeec2c27fbdf383 Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Tue, 25 Sep 2018 20:56:02 -0400
+Subject: dm cache: fix resize crash if user doesn't reload cache table
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit 5d07384a666d4b2f781dc056bfeec2c27fbdf383 upstream.
+
+A reload of the cache's DM table is needed during resize because
+otherwise a crash will occur when attempting to access smq policy
+entries associated with the portion of the cache that was recently
+extended.
+
+The reason is cache-size based data structures in the policy will not be
+resized, the only way to safely extend the cache is to allow for a
+proper cache policy initialization that occurs when the cache table is
+loaded. For example the smq policy's space_init(), init_allocator(),
+calc_hotspot_params() must be sized based on the extended cache size.
+
+The fix for this is to disallow cache resizes of this pattern:
+1) suspend "cache" target's device
+2) resize the fast device used for the cache
+3) resume "cache" target's device
+
+Instead, the last step must be a full reload of the cache's DM table.
+
+Fixes: 66a636356 ("dm cache: add stochastic-multi-queue (smq) policy")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-cache-target.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/md/dm-cache-target.c
++++ b/drivers/md/dm-cache-target.c
+@@ -3391,8 +3391,13 @@ static dm_cblock_t get_cache_dev_size(st
+
+ static bool can_resize(struct cache *cache, dm_cblock_t new_size)
+ {
+- if (from_cblock(new_size) > from_cblock(cache->cache_size))
+- return true;
++ if (from_cblock(new_size) > from_cblock(cache->cache_size)) {
++ if (cache->sized) {
++ DMERR("%s: unable to extend cache due to missing cache table reload",
++ cache_device_name(cache));
++ return false;
++ }
++ }
+
+ /*
+ * We can't drop a dirty block when shrinking the cache.
--- /dev/null
+From 1bafcbf59fed92af58955024452f45430d3898c5 Mon Sep 17 00:00:00 2001
+From: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Date: Wed, 26 Sep 2018 18:11:22 +0200
+Subject: fbdev/omapfb: fix omapfb_memory_read infoleak
+
+From: Tomi Valkeinen <tomi.valkeinen@ti.com>
+
+commit 1bafcbf59fed92af58955024452f45430d3898c5 upstream.
+
+OMAPFB_MEMORY_READ ioctl reads pixels from the LCD's memory and copies
+them to a userspace buffer. The code has two issues:
+
+- The user provided width and height could be large enough to overflow
+ the calculations
+- The copy_to_user() can copy uninitialized memory to the userspace,
+ which might contain sensitive kernel information.
+
+Fix these by limiting the width & height parameters, and only copying
+the amount of data that we actually received from the LCD.
+
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Reported-by: Jann Horn <jannh@google.com>
+Cc: stable@vger.kernel.org
+Cc: security@kernel.org
+Cc: Will Deacon <will.deacon@arm.com>
+Cc: Jann Horn <jannh@google.com>
+Cc: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
++++ b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
+@@ -496,6 +496,9 @@ static int omapfb_memory_read(struct fb_
+ if (!access_ok(VERIFY_WRITE, mr->buffer, mr->buffer_size))
+ return -EFAULT;
+
++ if (mr->w > 4096 || mr->h > 4096)
++ return -EINVAL;
++
+ if (mr->w * mr->h * 3 > mr->buffer_size)
+ return -EINVAL;
+
+@@ -509,7 +512,7 @@ static int omapfb_memory_read(struct fb_
+ mr->x, mr->y, mr->w, mr->h);
+
+ if (r > 0) {
+- if (copy_to_user(mr->buffer, buf, mr->buffer_size))
++ if (copy_to_user(mr->buffer, buf, r))
+ r = -EFAULT;
+ }
+
--- /dev/null
+From 211710ca74adf790b46ab3867fcce8047b573cd1 Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@nbd.name>
+Date: Sat, 29 Sep 2018 16:01:58 +0200
+Subject: mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys
+
+From: Felix Fietkau <nbd@nbd.name>
+
+commit 211710ca74adf790b46ab3867fcce8047b573cd1 upstream.
+
+key->sta is only valid after ieee80211_key_link, which is called later
+in this function. Because of that, the IEEE80211_KEY_FLAG_RX_MGMT is
+never set when management frame protection is enabled.
+
+Fixes: e548c49e6dc6b ("mac80211: add key flag for management keys")
+Cc: stable@vger.kernel.org
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/cfg.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mac80211/cfg.c
++++ b/net/mac80211/cfg.c
+@@ -219,7 +219,7 @@ static int ieee80211_add_key(struct wiph
+ case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_AP_VLAN:
+ /* Keys without a station are used for TX only */
+- if (key->sta && test_sta_flag(key->sta, WLAN_STA_MFP))
++ if (sta && test_sta_flag(sta, WLAN_STA_MFP))
+ key->conf.flags |= IEEE80211_KEY_FLAG_RX_MGMT;
+ break;
+ case NL80211_IFTYPE_ADHOC:
--- /dev/null
+From 58bc4c34d249bf1bc50730a9a209139347cfacfe Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Fri, 5 Oct 2018 15:52:07 -0700
+Subject: mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly
+
+From: Jann Horn <jannh@google.com>
+
+commit 58bc4c34d249bf1bc50730a9a209139347cfacfe upstream.
+
+5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even
+on UP") made the availability of the NR_TLB_REMOTE_FLUSH* counters inside
+the kernel unconditional to reduce #ifdef soup, but (either to avoid
+showing dummy zero counters to userspace, or because that code was missed)
+didn't update the vmstat_array, meaning that all following counters would
+be shown with incorrect values.
+
+This only affects kernel builds with
+CONFIG_VM_EVENT_COUNTERS=y && CONFIG_DEBUG_TLBFLUSH=y && CONFIG_SMP=n.
+
+Link: http://lkml.kernel.org/r/20181001143138.95119-2-jannh@google.com
+Fixes: 5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even on UP")
+Signed-off-by: Jann Horn <jannh@google.com>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Roman Gushchin <guro@fb.com>
+Cc: Davidlohr Bueso <dave@stgolabs.net>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Christoph Lameter <clameter@sgi.com>
+Cc: Kemi Wang <kemi.wang@intel.com>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/vmstat.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/mm/vmstat.c
++++ b/mm/vmstat.c
+@@ -858,6 +858,9 @@ const char * const vmstat_text[] = {
+ #ifdef CONFIG_SMP
+ "nr_tlb_remote_flush",
+ "nr_tlb_remote_flush_received",
++#else
++ "", /* nr_tlb_remote_flush */
++ "", /* nr_tlb_remote_flush_received */
+ #endif /* CONFIG_SMP */
+ "nr_tlb_local_flush_all",
+ "nr_tlb_local_flush_one",
--- /dev/null
+From 083874549fdfefa629dfa752785e20427dde1511 Mon Sep 17 00:00:00 2001
+From: Daniel Drake <drake@endlessm.com>
+Date: Thu, 27 Sep 2018 15:47:33 -0500
+Subject: PCI: Reprogram bridge prefetch registers on resume
+
+From: Daniel Drake <drake@endlessm.com>
+
+commit 083874549fdfefa629dfa752785e20427dde1511 upstream.
+
+On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
+suspend/resume. The affected products include multiple generations of
+NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such
+as:
+
+ fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
+ [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
+ DRM: failed to idle channel 0 [DRM]
+
+Similarly, the NVIDIA proprietary driver also fails after resume (black
+screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for
+diagnosis, and their response indicated that it's a problem with the parent
+PCI bridge (on the Intel SoC), not the GPU.
+
+Runtime suspend/resume works fine, only S3 suspend is affected.
+
+We found a workaround: on resume, rewrite the Intel PCI bridge
+'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the
+cases that I checked, this register has value 0 and we just have to rewrite
+that value.
+
+Linux already saves and restores PCI config space during suspend/resume,
+but this register was being skipped because upon resume, it already has
+value 0 (the correct, pre-suspend value).
+
+Intel appear to have previously acknowledged this behaviour and the
+requirement to rewrite this register:
+https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
+
+Based on that, rewrite the prefetch register values even when that appears
+unnecessary.
+
+We have confirmed this solution on all the affected models we have in-hands
+(X542UQ, UX533FD, X530UN, V272UN).
+
+Additionally, this solves an issue where r8169 MSI-X interrupts were broken
+after S3 suspend/resume on ASUS X441UAR. This issue was recently worked
+around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It
+also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
+that we had not yet patched. I suspect it will also fix the issue that was
+worked around in commit 7c53a722459c ("r8169: don't use MSI-X on
+RTL8168g").
+
+Thomas Martitz reports that this change also solves an issue where the AMD
+Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
+suspend/resume.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
+Signed-off-by: Daniel Drake <drake@endlessm.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Reviewed-By: Peter Wu <peter@lekensteyn.nl>
+CC: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/pci.c | 27 +++++++++++++++++++--------
+ 1 file changed, 19 insertions(+), 8 deletions(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -1064,12 +1064,12 @@ int pci_save_state(struct pci_dev *dev)
+ EXPORT_SYMBOL(pci_save_state);
+
+ static void pci_restore_config_dword(struct pci_dev *pdev, int offset,
+- u32 saved_val, int retry)
++ u32 saved_val, int retry, bool force)
+ {
+ u32 val;
+
+ pci_read_config_dword(pdev, offset, &val);
+- if (val == saved_val)
++ if (!force && val == saved_val)
+ return;
+
+ for (;;) {
+@@ -1088,25 +1088,36 @@ static void pci_restore_config_dword(str
+ }
+
+ static void pci_restore_config_space_range(struct pci_dev *pdev,
+- int start, int end, int retry)
++ int start, int end, int retry,
++ bool force)
+ {
+ int index;
+
+ for (index = end; index >= start; index--)
+ pci_restore_config_dword(pdev, 4 * index,
+ pdev->saved_config_space[index],
+- retry);
++ retry, force);
+ }
+
+ static void pci_restore_config_space(struct pci_dev *pdev)
+ {
+ if (pdev->hdr_type == PCI_HEADER_TYPE_NORMAL) {
+- pci_restore_config_space_range(pdev, 10, 15, 0);
++ pci_restore_config_space_range(pdev, 10, 15, 0, false);
+ /* Restore BARs before the command register. */
+- pci_restore_config_space_range(pdev, 4, 9, 10);
+- pci_restore_config_space_range(pdev, 0, 3, 0);
++ pci_restore_config_space_range(pdev, 4, 9, 10, false);
++ pci_restore_config_space_range(pdev, 0, 3, 0, false);
++ } else if (pdev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
++ pci_restore_config_space_range(pdev, 12, 15, 0, false);
++
++ /*
++ * Force rewriting of prefetch registers to avoid S3 resume
++ * issues on Intel PCI bridges that occur when these
++ * registers are not explicitly written.
++ */
++ pci_restore_config_space_range(pdev, 9, 11, 0, true);
++ pci_restore_config_space_range(pdev, 0, 8, 0, false);
+ } else {
+- pci_restore_config_space_range(pdev, 0, 15, 0);
++ pci_restore_config_space_range(pdev, 0, 15, 0, false);
+ }
+ }
+
--- /dev/null
+From 69e445ab8b66a9f30519842ef18be555d3ee9b51 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Thu, 4 Oct 2018 11:08:12 +0200
+Subject: PM / core: Clear the direct_complete flag on errors
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 69e445ab8b66a9f30519842ef18be555d3ee9b51 upstream.
+
+If __device_suspend() runs asynchronously (in which case the device
+passed to it is in dpm_suspended_list at that point) and it returns
+early on an error or pending wakeup, and the power.direct_complete
+flag has been set for the device already, the subsequent
+device_resume() will be confused by that and it will call
+pm_runtime_enable() incorrectly, as runtime PM has not been
+disabled for the device by __device_suspend().
+
+To avoid that, clear power.direct_complete if __device_suspend()
+is not going to disable runtime PM for the device before returning.
+
+Fixes: aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily)
+Reported-by: Al Cooper <alcooperx@gmail.com>
+Tested-by: Al Cooper <alcooperx@gmail.com>
+Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
+Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/power/main.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/base/power/main.c
++++ b/drivers/base/power/main.c
+@@ -1355,8 +1355,10 @@ static int __device_suspend(struct devic
+
+ dpm_wait_for_children(dev, async);
+
+- if (async_error)
++ if (async_error) {
++ dev->power.direct_complete = false;
+ goto Complete;
++ }
+
+ /*
+ * If a device configured to wake up the system from sleep states
+@@ -1368,6 +1370,7 @@ static int __device_suspend(struct devic
+ pm_wakeup_event(dev, 0);
+
+ if (pm_wakeup_pending()) {
++ dev->power.direct_complete = false;
+ async_error = -EBUSY;
+ goto Complete;
+ }
--- /dev/null
+From f5fad711c06e652f90f581fc7c2caee327c33d31 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 24 Sep 2018 15:28:10 +0200
+Subject: USB: serial: simple: add Motorola Tetra MTP6550 id
+
+From: Johan Hovold <johan@kernel.org>
+
+commit f5fad711c06e652f90f581fc7c2caee327c33d31 upstream.
+
+Add device-id for the Motorola Tetra radio MTP6550.
+
+Bus 001 Device 004: ID 0cad:9012 Motorola CGISS
+Device Descriptor:
+ bLength 18
+ bDescriptorType 1
+ bcdUSB 2.00
+ bDeviceClass 0 (Defined at Interface level)
+ bDeviceSubClass 0
+ bDeviceProtocol 0
+ bMaxPacketSize0 64
+ idVendor 0x0cad Motorola CGISS
+ idProduct 0x9012
+ bcdDevice 24.16
+ iManufacturer 1 Motorola Solutions, Inc.
+ iProduct 2 TETRA PEI interface
+ iSerial 0
+ bNumConfigurations 1
+ Configuration Descriptor:
+ bLength 9
+ bDescriptorType 2
+ wTotalLength 55
+ bNumInterfaces 2
+ bConfigurationValue 1
+ iConfiguration 3 Generic Serial config
+ bmAttributes 0x80
+ (Bus Powered)
+ MaxPower 500mA
+ Interface Descriptor:
+ bLength 9
+ bDescriptorType 4
+ bInterfaceNumber 0
+ bAlternateSetting 0
+ bNumEndpoints 2
+ bInterfaceClass 255 Vendor Specific Class
+ bInterfaceSubClass 0
+ bInterfaceProtocol 0
+ iInterface 0
+ Endpoint Descriptor:
+ bLength 7
+ bDescriptorType 5
+ bEndpointAddress 0x81 EP 1 IN
+ bmAttributes 2
+ Transfer Type Bulk
+ Synch Type None
+ Usage Type Data
+ wMaxPacketSize 0x0200 1x 512 bytes
+ bInterval 0
+ Endpoint Descriptor:
+ bLength 7
+ bDescriptorType 5
+ bEndpointAddress 0x01 EP 1 OUT
+ bmAttributes 2
+ Transfer Type Bulk
+ Synch Type None
+ Usage Type Data
+ wMaxPacketSize 0x0200 1x 512 bytes
+ Interface Descriptor:
+ bLength 9
+ bDescriptorType 4
+ bInterfaceNumber 1
+ bAlternateSetting 0
+ bNumEndpoints 2
+ bInterfaceClass 255 Vendor Specific Class
+ bInterfaceSubClass 0
+ bInterfaceProtocol 0
+ iInterface 0
+ Endpoint Descriptor:
+ bLength 7
+ bDescriptorType 5
+ bEndpointAddress 0x82 EP 2 IN
+ bmAttributes 2
+ Transfer Type Bulk
+ Synch Type None
+ Usage Type Data
+ wMaxPacketSize 0x0200 1x 512 bytes
+ bInterval 0
+ Endpoint Descriptor:
+ bLength 7
+ bDescriptorType 5
+ bEndpointAddress 0x02 EP 2 OUT
+ bmAttributes 2
+ Transfer Type Bulk
+ Synch Type None
+ Usage Type Data
+ wMaxPacketSize 0x0200 1x 512 bytes
+ bInterval 0
+Device Qualifier (for other device speed):
+ bLength 10
+ bDescriptorType 6
+ bcdUSB 2.00
+ bDeviceClass 0 (Defined at Interface level)
+ bDeviceSubClass 0
+ bDeviceProtocol 0
+ bMaxPacketSize0 64
+ bNumConfigurations 1
+Device Status: 0x0000
+ (Bus Powered)
+
+Reported-by: Hans Hult <hanshult35@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/usb-serial-simple.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/serial/usb-serial-simple.c
++++ b/drivers/usb/serial/usb-serial-simple.c
+@@ -87,7 +87,8 @@ DEVICE(moto_modem, MOTO_IDS);
+
+ /* Motorola Tetra driver */
+ #define MOTOROLA_TETRA_IDS() \
+- { USB_DEVICE(0x0cad, 0x9011) } /* Motorola Solutions TETRA PEI */
++ { USB_DEVICE(0x0cad, 0x9011) }, /* Motorola Solutions TETRA PEI */ \
++ { USB_DEVICE(0x0cad, 0x9012) } /* MTP6550 */
+ DEVICE(motorola_tetra, MOTOROLA_TETRA_IDS);
+
+ /* Novatel Wireless GPS driver */
--- /dev/null
+From 715bd9d12f84d8f5cc8ad21d888f9bc304a8eb0b Mon Sep 17 00:00:00 2001
+From: Andy Lutomirski <luto@kernel.org>
+Date: Mon, 1 Oct 2018 12:52:15 -0700
+Subject: x86/vdso: Fix asm constraints on vDSO syscall fallbacks
+
+From: Andy Lutomirski <luto@kernel.org>
+
+commit 715bd9d12f84d8f5cc8ad21d888f9bc304a8eb0b upstream.
+
+The syscall fallbacks in the vDSO have incorrect asm constraints.
+They are not marked as writing to their outputs -- instead, they are
+marked as clobbering "memory", which is useless. In particular, gcc
+is smart enough to know that the timespec parameter hasn't escaped,
+so a memory clobber doesn't clobber it. And passing a pointer as an
+asm *input* does not tell gcc that the pointed-to value is changed.
+
+Add in the fact that the asm instructions weren't volatile, and gcc
+was free to omit them entirely unless their sole output (the return
+value) is used. Which it is (phew!), but that stops happening with
+some upcoming patches.
+
+As a trivial example, the following code:
+
+void test_fallback(struct timespec *ts)
+{
+ vdso_fallback_gettime(CLOCK_MONOTONIC, ts);
+}
+
+compiles to:
+
+00000000000000c0 <test_fallback>:
+ c0: c3 retq
+
+To add insult to injury, the RCX and R11 clobbers on 64-bit
+builds were missing.
+
+The "memory" clobber is also unnecessary -- no ordering with respect to
+other memory operations is needed, but that's going to be fixed in a
+separate not-for-stable patch.
+
+Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu")
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/2c0231690551989d2fafa60ed0e7b5cc8b403908.1538422295.git.luto@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/entry/vdso/vclock_gettime.c | 18 ++++++++++--------
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+--- a/arch/x86/entry/vdso/vclock_gettime.c
++++ b/arch/x86/entry/vdso/vclock_gettime.c
+@@ -51,8 +51,9 @@ extern u8 pvclock_page
+ notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+ {
+ long ret;
+- asm("syscall" : "=a" (ret) :
+- "0" (__NR_clock_gettime), "D" (clock), "S" (ts) : "memory");
++ asm ("syscall" : "=a" (ret), "=m" (*ts) :
++ "0" (__NR_clock_gettime), "D" (clock), "S" (ts) :
++ "memory", "rcx", "r11");
+ return ret;
+ }
+
+@@ -60,8 +61,9 @@ notrace static long vdso_fallback_gtod(s
+ {
+ long ret;
+
+- asm("syscall" : "=a" (ret) :
+- "0" (__NR_gettimeofday), "D" (tv), "S" (tz) : "memory");
++ asm ("syscall" : "=a" (ret), "=m" (*tv), "=m" (*tz) :
++ "0" (__NR_gettimeofday), "D" (tv), "S" (tz) :
++ "memory", "rcx", "r11");
+ return ret;
+ }
+
+@@ -143,12 +145,12 @@ notrace static long vdso_fallback_gettim
+ {
+ long ret;
+
+- asm(
++ asm (
+ "mov %%ebx, %%edx \n"
+ "mov %2, %%ebx \n"
+ "call __kernel_vsyscall \n"
+ "mov %%edx, %%ebx \n"
+- : "=a" (ret)
++ : "=a" (ret), "=m" (*ts)
+ : "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
+ : "memory", "edx");
+ return ret;
+@@ -158,12 +160,12 @@ notrace static long vdso_fallback_gtod(s
+ {
+ long ret;
+
+- asm(
++ asm (
+ "mov %%ebx, %%edx \n"
+ "mov %2, %%ebx \n"
+ "call __kernel_vsyscall \n"
+ "mov %%edx, %%ebx \n"
+- : "=a" (ret)
++ : "=a" (ret), "=m" (*tv), "=m" (*tz)
+ : "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
+ : "memory", "edx");
+ return ret;
--- /dev/null
+From 02e425668f5c9deb42787d10001a3b605993ad15 Mon Sep 17 00:00:00 2001
+From: Andy Lutomirski <luto@kernel.org>
+Date: Wed, 3 Oct 2018 16:23:49 -0700
+Subject: x86/vdso: Fix vDSO syscall fallback asm constraint regression
+
+From: Andy Lutomirski <luto@kernel.org>
+
+commit 02e425668f5c9deb42787d10001a3b605993ad15 upstream.
+
+When I added the missing memory outputs, I failed to update the
+index of the first argument (ebx) on 32-bit builds, which broke the
+fallbacks. Somehow I must have screwed up my testing or gotten
+lucky.
+
+Add another test to cover gettimeofday() as well.
+
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Fixes: 715bd9d12f84 ("x86/vdso: Fix asm constraints on vDSO syscall fallbacks")
+Link: http://lkml.kernel.org/r/21bd45ab04b6d838278fa5bebfa9163eceffa13c.1538608971.git.luto@kernel.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/entry/vdso/vclock_gettime.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/entry/vdso/vclock_gettime.c
++++ b/arch/x86/entry/vdso/vclock_gettime.c
+@@ -147,11 +147,11 @@ notrace static long vdso_fallback_gettim
+
+ asm (
+ "mov %%ebx, %%edx \n"
+- "mov %2, %%ebx \n"
++ "mov %[clock], %%ebx \n"
+ "call __kernel_vsyscall \n"
+ "mov %%edx, %%ebx \n"
+ : "=a" (ret), "=m" (*ts)
+- : "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
++ : "0" (__NR_clock_gettime), [clock] "g" (clock), "c" (ts)
+ : "memory", "edx");
+ return ret;
+ }
+@@ -162,11 +162,11 @@ notrace static long vdso_fallback_gtod(s
+
+ asm (
+ "mov %%ebx, %%edx \n"
+- "mov %2, %%ebx \n"
++ "mov %[tv], %%ebx \n"
+ "call __kernel_vsyscall \n"
+ "mov %%edx, %%ebx \n"
+ : "=a" (ret), "=m" (*tv), "=m" (*tz)
+- : "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
++ : "0" (__NR_gettimeofday), [tv] "g" (tv), "c" (tz)
+ : "memory", "edx");
+ return ret;
+ }
--- /dev/null
+From ffe84e01bb1b38c7eb9c6b6da127a6c136d251df Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Mon, 1 Oct 2018 18:36:07 +0300
+Subject: xhci: Add missing CAS workaround for Intel Sunrise Point xHCI
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit ffe84e01bb1b38c7eb9c6b6da127a6c136d251df upstream.
+
+The workaround for missing CAS bit is also needed for xHC on Intel
+sunrisepoint PCH. For more details see:
+
+Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8
+
+Cc: <stable@vger.kernel.org>
+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 | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -174,6 +174,8 @@ static void xhci_pci_quirks(struct devic
+ }
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ (pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
++ pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI ||
++ pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_DNV_XHCI))
+ xhci->quirks |= XHCI_MISSING_CAS;
projects / thirdparty / kernel / stable-queue.git / commitdiff
