commit be9b6782a9eb128a45b4d4fce556f7053234773d Author: Greg Kroah-Hartman Date: Sun Jul 21 09:03:18 2019 +0200 Linux 4.19.60 commit d173ce091c1aab04cf704e73dee6cdd9faafb1ab Author: Jiri Slaby Date: Tue Jul 9 08:34:02 2019 +0200 x86/entry/32: Fix ENDPROC of common_spurious [ Upstream commit 1cbec37b3f9cff074a67bef4fc34b30a09958a0a ] common_spurious is currently ENDed erroneously. common_interrupt is used in its ENDPROC. So fix this mistake. Found by my asm macros rewrite patchset. Fixes: f8a8fe61fec8 ("x86/irq: Seperate unused system vectors from spurious entry again") Signed-off-by: Jiri Slaby Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20190709063402.19847-1-jslaby@suse.cz Signed-off-by: Sasha Levin commit 466bdfc6c4d62c7e28e6785c7d2e106a906f7754 Author: Dave Airlie Date: Mon Jul 15 12:05:58 2019 -0600 drm/udl: move to embedding drm device inside udl device. commit 6ecac85eadb9d4065b9038fa3d3c66d49038e14b upstream. This should help with some of the lifetime issues, and move us away from load/unload. Acked-by: Alex Deucher Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-4-airlied@gmail.com Signed-off-by: Ross Zwisler Signed-off-by: Sasha Levin commit af48f7d79faeaa9f426b400c6ec332fe669553e0 Author: Thomas Zimmermann Date: Mon Jul 15 12:05:57 2019 -0600 drm/udl: Replace drm_dev_unref with drm_dev_put commit ac3b35f11a06964f5fe7f6ea9a190a28a7994704 upstream. This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180926120212.25359-1-tzimmermann@suse.de Signed-off-by: Ross Zwisler Signed-off-by: Sasha Levin commit cfd99eccede58edcf868240ed0e2d3ec9a2f56ee Author: Dave Airlie Date: Mon Jul 15 12:05:56 2019 -0600 drm/udl: introduce a macro to convert dev to udl. commit fd96e0dba19c53c2d66f2a398716bb74df8ca85e upstream. This just makes it easier to later embed drm into udl. Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-3-airlied@gmail.com Signed-off-by: Ross Zwisler Signed-off-by: Sasha Levin commit 8f14cf159e9ffe45fe9b66d05a13231f0ed2b43e Author: Mark Zhang Date: Mon Jan 14 17:32:58 2019 +0800 regmap-irq: do not write mask register if mask_base is zero commit 7151449fe7fa5962c6153355f9779d6be99e8e97 upstream. If client have not provided the mask base register then do not write into the mask register. Signed-off-by: Laxman Dewangan Signed-off-by: Jinyoung Park Signed-off-by: Venkat Reddy Talla Signed-off-by: Mark Zhang Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 820b010743ee55efe6cf2613e38672d8ce3e5555 Author: Haren Myneni Date: Tue Jun 18 12:09:22 2019 -0700 crypto/NX: Set receive window credits to max number of CRBs in RxFIFO commit e52d484d9869eb291140545746ccbe5ffc7c9306 upstream. System gets checkstop if RxFIFO overruns with more requests than the maximum possible number of CRBs in FIFO at the same time. The max number of requests per window is controlled by window credits. So find max CRBs from FIFO size and set it to receive window credits. Fixes: b0d6c9bab5e4 ("crypto/nx: Add P9 NX support for 842 compression engine") CC: stable@vger.kernel.org # v4.14+ Signed-off-by:Haren Myneni Signed-off-by: Greg Kroah-Hartman Signed-off-by: Herbert Xu commit b24c6403633d416b463eb90138f6a02aa9f591d0 Author: Christophe Leroy Date: Mon Jun 24 07:20:16 2019 +0000 crypto: talitos - fix hash on SEC1. commit 58cdbc6d2263beb36954408522762bbe73169306 upstream. On SEC1, hash provides wrong result when performing hashing in several steps with input data SG list has more than one element. This was detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS: [ 44.185947] alg: hash: md5-talitos test failed (wrong result) on test vector 6, cfg="random: may_sleep use_finup src_divs=[25.88%@+8063, 24.19%@+9588, 28.63%@+16333, 4.60%@+6756, 16.70%@+16281] dst_divs=[71.61%@alignmask+16361, 14.36%@+7756, 14.3%@+" [ 44.325122] alg: hash: sha1-talitos test failed (wrong result) on test vector 3, cfg="random: inplace use_final src_divs=[16.56%@+16378, 52.0%@+16329, 21.42%@alignmask+16380, 10.2%@alignmask+16380] iv_offset=39" [ 44.493500] alg: hash: sha224-talitos test failed (wrong result) on test vector 4, cfg="random: use_final nosimd src_divs=[52.27%@+7401, 17.34%@+16285, 17.71%@+26, 12.68%@+10644] iv_offset=43" [ 44.673262] alg: hash: sha256-talitos test failed (wrong result) on test vector 4, cfg="random: may_sleep use_finup src_divs=[60.6%@+12790, 17.86%@+1329, 12.64%@alignmask+16300, 8.29%@+15, 0.40%@+13506, 0.51%@+16322, 0.24%@+16339] dst_divs" This is due to two issues: - We have an overlap between the buffer used for copying the input data (SEC1 doesn't do scatter/gather) and the chained descriptor. - Data copy is wrong when the previous hash left less than one blocksize of data to hash, implying a complement of the previous block with a few bytes from the new request. Fix it by: - Moving the second descriptor after the buffer, as moving the buffer after the descriptor would make it more complex for other cipher operations (AEAD, ABLKCIPHER) - Skip the bytes taken from the new request to complete the previous one by moving the SG list forward. Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ff1ce8ef1f88fb6ea9df1d811119ee2bbf271a40 Author: Christophe Leroy Date: Mon Jun 24 07:20:15 2019 +0000 crypto: talitos - move struct talitos_edesc into talitos.h commit d44769e4ccb636e8238adbc151f25467a536711b upstream. Moves struct talitos_edesc into talitos.h so that it can be used from any place in talitos.c It will be required for next patch ("crypto: talitos - fix hash on SEC1") Signed-off-by: Christophe Leroy Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit b578b87bcab687984fe23774d0abc70889284895 Author: Julian Wiedmann Date: Tue Jun 18 13:12:20 2019 +0200 s390/qdio: don't touch the dsci in tiqdio_add_input_queues() commit ac6639cd3db607d386616487902b4cc1850a7be5 upstream. Current code sets the dsci to 0x00000080. Which doesn't make any sense, as the indicator area is located in the _left-most_ byte. Worse: if the dsci is the _shared_ indicator, this potentially clears the indication of activity for a _different_ device. tiqdio_thinint_handler() will then have no reason to call that device's IRQ handler, and the device ends up stalling. Fixes: d0c9d4a89fff ("[S390] qdio: set correct bit in dsci") Cc: Signed-off-by: Julian Wiedmann Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit b1d52630b12a0913c549c4b3b8d2e783d59efec2 Author: Julian Wiedmann Date: Tue Jun 18 11:25:59 2019 +0200 s390/qdio: (re-)initialize tiqdio list entries commit e54e4785cb5cb4896cf4285964aeef2125612fb2 upstream. When tiqdio_remove_input_queues() removes a queue from the tiq_list as part of qdio_shutdown(), it doesn't re-initialize the queue's list entry and the prev/next pointers go stale. If a subsequent qdio_establish() fails while sending the ESTABLISH cmd, it calls qdio_shutdown() again in QDIO_IRQ_STATE_ERR state and tiqdio_remove_input_queues() will attempt to remove the queue entry a second time. This dereferences the stale pointers, and bad things ensue. Fix this by re-initializing the list entry after removing it from the list. For good practice also initialize the list entry when the queue is first allocated, and remove the quirky checks that papered over this omission. Note that prior to commit e521813468f7 ("s390/qdio: fix access to uninitialized qdio_q fields"), these checks were bogus anyway. setup_queues_misc() clears the whole queue struct, and thus needs to re-init the prev/next pointers as well. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Cc: Signed-off-by: Julian Wiedmann Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 02eb533e940aaefb587ac30d4276eaa323a50dbe Author: Heiko Carstens Date: Mon Jun 17 14:02:41 2019 +0200 s390: fix stfle zero padding commit 4f18d869ffd056c7858f3d617c71345cf19be008 upstream. The stfle inline assembly returns the number of double words written (condition code 0) or the double words it would have written (condition code 3), if the memory array it got as parameter would have been large enough. The current stfle implementation assumes that the array is always large enough and clears those parts of the array that have not been written to with a subsequent memset call. If however the array is not large enough memset will get a negative length parameter, which means that memset clears memory until it gets an exception and the kernel crashes. To fix this simply limit the maximum length. Move also the inline assembly to an extra function to avoid clobbering of register 0, which might happen because of the added min_t invocation together with code instrumentation. The bug was introduced with commit 14375bc4eb8d ("[S390] cleanup facility list handling") but was rather harmless, since it would only write to a rather large array. It became a potential problem with commit 3ab121ab1866 ("[S390] kernel: Add z/VM LGR detection"). Since then it writes to an array with only four double words, while some machines already deliver three double words. As soon as machines have a facility bit within the fifth double a crash on IPL would happen. Fixes: 14375bc4eb8d ("[S390] cleanup facility list handling") Cc: # v2.6.37+ Reviewed-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 9db915738e40b6957882eef4d32a9a7f039f1bb9 Author: Arnd Bergmann Date: Wed Jul 3 15:39:25 2019 +0200 ARC: hide unused function unw_hdr_alloc commit fd5de2721ea7d16e2b16c4049ac49f229551b290 upstream. As kernelci.org reports, this function is not used in vdk_hs38_defconfig: arch/arc/kernel/unwind.c:188:14: warning: 'unw_hdr_alloc' defined but not used [-Wunused-function] Fixes: bc79c9a72165 ("ARC: dw2 unwind: Reinstante unwinding out of modules") Link: https://kernelci.org/build/id/5d1cae3f59b514300340c132/logs/ Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit fc6975ee932b38992e5932e88cb3bb6790a09740 Author: Thomas Gleixner Date: Fri Jun 28 13:11:54 2019 +0200 x86/irq: Seperate unused system vectors from spurious entry again commit f8a8fe61fec8006575699559ead88b0b833d5cad upstream Quite some time ago the interrupt entry stubs for unused vectors in the system vector range got removed and directly mapped to the spurious interrupt vector entry point. Sounds reasonable, but it's subtly broken. The spurious interrupt vector entry point pushes vector number 0xFF on the stack which makes the whole logic in __smp_spurious_interrupt() pointless. As a consequence any spurious interrupt which comes from a vector != 0xFF is treated as a real spurious interrupt (vector 0xFF) and not acknowledged. That subsequently stalls all interrupt vectors of equal and lower priority, which brings the system to a grinding halt. This can happen because even on 64-bit the system vector space is not guaranteed to be fully populated. A full compile time handling of the unused vectors is not possible because quite some of them are conditonally populated at runtime. Bring the entry stubs back, which wastes 160 bytes if all stubs are unused, but gains the proper handling back. There is no point to selectively spare some of the stubs which are known at compile time as the required code in the IDT management would be way larger and convoluted. Do not route the spurious entries through common_interrupt and do_IRQ() as the original code did. Route it to smp_spurious_interrupt() which evaluates the vector number and acts accordingly now that the real vector numbers are handed in. Fixup the pr_warn so the actual spurious vector (0xff) is clearly distiguished from the other vectors and also note for the vectored case whether it was pending in the ISR or not. "Spurious APIC interrupt (vector 0xFF) on CPU#0, should never happen." "Spurious interrupt vector 0xed on CPU#1. Acked." "Spurious interrupt vector 0xee on CPU#1. Not pending!." Fixes: 2414e021ac8d ("x86: Avoid building unused IRQ entry stubs") Reported-by: Jan Kiszka Signed-off-by: Thomas Gleixner Cc: Marc Zyngier Cc: Jan Beulich Link: https://lkml.kernel.org/r/20190628111440.550568228@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 9494cd3928859a997bf79510d061e7dac5780d0a Author: Thomas Gleixner Date: Fri Jun 28 13:11:53 2019 +0200 x86/irq: Handle spurious interrupt after shutdown gracefully commit b7107a67f0d125459fe41f86e8079afd1a5e0b15 upstream Since the rework of the vector management, warnings about spurious interrupts have been reported. Robert provided some more information and did an initial analysis. The following situation leads to these warnings: CPU 0 CPU 1 IO_APIC interrupt is raised sent to CPU1 Unable to handle immediately (interrupts off, deep idle delay) mask() ... free() shutdown() synchronize_irq() clear_vector() do_IRQ() -> vector is clear Before the rework the vector entries of legacy interrupts were statically assigned and occupied precious vector space while most of them were unused. Due to that the above situation was handled silently because the vector was handled and the core handler of the assigned interrupt descriptor noticed that it is shut down and returned. While this has been usually observed with legacy interrupts, this situation is not limited to them. Any other interrupt source, e.g. MSI, can cause the same issue. After adding proper synchronization for level triggered interrupts, this can only happen for edge triggered interrupts where the IO-APIC obviously cannot provide information about interrupts in flight. While the spurious warning is actually harmless in this case it worries users and driver developers. Handle it gracefully by marking the vector entry as VECTOR_SHUTDOWN instead of VECTOR_UNUSED when the vector is freed up. If that above late handling happens the spurious detector will not complain and switch the entry to VECTOR_UNUSED. Any subsequent spurious interrupt on that line will trigger the spurious warning as before. Fixes: 464d12309e1b ("x86/vector: Switch IOAPIC to global reservation mode") Reported-by: Robert Hodaszi Signed-off-by: Thomas Gleixner - Tested-by: Robert Hodaszi Cc: Marc Zyngier Link: https://lkml.kernel.org/r/20190628111440.459647741@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 7897f5a443fb8a1277911aa0356f78d3940c6c39 Author: Thomas Gleixner Date: Fri Jun 28 13:11:52 2019 +0200 x86/ioapic: Implement irq_get_irqchip_state() callback commit dfe0cf8b51b07e56ded571e3de0a4a9382517231 upstream When an interrupt is shut down in free_irq() there might be an inflight interrupt pending in the IO-APIC remote IRR which is not yet serviced. That means the interrupt has been sent to the target CPUs local APIC, but the target CPU is in a state which delays the servicing. So free_irq() would proceed to free resources and to clear the vector because synchronize_hardirq() does not see an interrupt handler in progress. That can trigger a spurious interrupt warning, which is harmless and just confuses users, but it also can leave the remote IRR in a stale state because once the handler is invoked the interrupt resources might be freed already and therefore acknowledgement is not possible anymore. Implement the irq_get_irqchip_state() callback for the IO-APIC irq chip. The callback is invoked from free_irq() via __synchronize_hardirq(). Check the remote IRR bit of the interrupt and return 'in flight' if it is set and the interrupt is configured in level mode. For edge mode the remote IRR has no meaning. As this is only meaningful for level triggered interrupts this won't cure the potential spurious interrupt warning for edge triggered interrupts, but the edge trigger case does not result in stale hardware state. This has to be addressed at the vector/interrupt entry level seperately. Fixes: 464d12309e1b ("x86/vector: Switch IOAPIC to global reservation mode") Reported-by: Robert Hodaszi Signed-off-by: Thomas Gleixner Cc: Marc Zyngier Link: https://lkml.kernel.org/r/20190628111440.370295517@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 6074f6043c49fceb1b22227c2db315fe0d5a331f Author: Thomas Gleixner Date: Fri Jun 28 13:11:51 2019 +0200 genirq: Add optional hardware synchronization for shutdown commit 62e0468650c30f0298822c580f382b16328119f6 upstream free_irq() ensures that no hardware interrupt handler is executing on a different CPU before actually releasing resources and deactivating the interrupt completely in a domain hierarchy. But that does not catch the case where the interrupt is on flight at the hardware level but not yet serviced by the target CPU. That creates an interesing race condition: CPU 0 CPU 1 IRQ CHIP interrupt is raised sent to CPU1 Unable to handle immediately (interrupts off, deep idle delay) mask() ... free() shutdown() synchronize_irq() release_resources() do_IRQ() -> resources are not available That might be harmless and just trigger a spurious interrupt warning, but some interrupt chips might get into a wedged state. Utilize the existing irq_get_irqchip_state() callback for the synchronization in free_irq(). synchronize_hardirq() is not using this mechanism as it might actually deadlock unter certain conditions, e.g. when called with interrupts disabled and the target CPU is the one on which the synchronization is invoked. synchronize_irq() uses it because that function cannot be called from non preemtible contexts as it might sleep. No functional change intended and according to Marc the existing GIC implementations where the driver supports the callback should be able to cope with that core change. Famous last words. Fixes: 464d12309e1b ("x86/vector: Switch IOAPIC to global reservation mode") Reported-by: Robert Hodaszi Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Tested-by: Marc Zyngier Link: https://lkml.kernel.org/r/20190628111440.279463375@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 3f10ccc29780b5ca8b1638941a47018f694ecbc7 Author: Thomas Gleixner Date: Fri Jun 28 13:11:50 2019 +0200 genirq: Fix misleading synchronize_irq() documentation commit 1d21f2af8571c6a6a44e7c1911780614847b0253 upstream The function might sleep, so it cannot be called from interrupt context. Not even with care. Signed-off-by: Thomas Gleixner Cc: Marc Zyngier Link: https://lkml.kernel.org/r/20190628111440.189241552@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 578db1aa595b421f35960765a0702e9facc13038 Author: Thomas Gleixner Date: Fri Jun 28 13:11:49 2019 +0200 genirq: Delay deactivation in free_irq() commit 4001d8e8762f57d418b66e4e668601791900a1dd upstream When interrupts are shutdown, they are immediately deactivated in the irqdomain hierarchy. While this looks obviously correct there is a subtle issue: There might be an interrupt in flight when free_irq() is invoking the shutdown. This is properly handled at the irq descriptor / primary handler level, but the deactivation might completely disable resources which are required to acknowledge the interrupt. Split the shutdown code and deactivate the interrupt after synchronization in free_irq(). Fixup all other usage sites where this is not an issue to invoke the combined shutdown_and_deactivate() function instead. This still might be an issue if the interrupt in flight servicing is delayed on a remote CPU beyond the invocation of synchronize_irq(), but that cannot be handled at that level and needs to be handled in the synchronize_irq() context. Fixes: f8264e34965a ("irqdomain: Introduce new interfaces to support hierarchy irqdomains") Reported-by: Robert Hodaszi Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Link: https://lkml.kernel.org/r/20190628111440.098196390@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 2656ee5a5ad59300bbe183d0833867a582910dcc Author: Vinod Koul Date: Fri Jun 28 12:07:21 2019 -0700 linux/kernel.h: fix overflow for DIV_ROUND_UP_ULL [ Upstream commit 8f9fab480c7a87b10bb5440b5555f370272a5d59 ] DIV_ROUND_UP_ULL adds the two arguments and then invokes DIV_ROUND_DOWN_ULL. But on a 32bit system the addition of two 32 bit values can overflow. DIV_ROUND_DOWN_ULL does it correctly and stashes the addition into a unsigned long long so cast the result to unsigned long long here to avoid the overflow condition. [akpm@linux-foundation.org: DIV_ROUND_UP_ULL must be an rval] Link: http://lkml.kernel.org/r/20190625100518.30753-1-vkoul@kernel.org Signed-off-by: Vinod Koul Reviewed-by: Andrew Morton Cc: Bjorn Andersson Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9c875e8556d4176d476ea55f1fe747a40b37bec8 Author: Nicolas Boichat Date: Wed Jun 26 11:54:45 2019 +0800 pinctrl: mediatek: Update cur_mask in mask/mask ops [ Upstream commit 9d957a959bc8c3dfe37572ac8e99affb5a885965 ] During suspend/resume, mtk_eint_mask may be called while wake_mask is active. For example, this happens if a wake-source with an active interrupt handler wakes the system: irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so that it can be handled later on in the resume flow. However, this may happen before mtk_eint_do_resume is called: in this case, wake_mask is loaded, and cur_mask is restored from an older copy, re-enabling the interrupt, and causing an interrupt storm (especially for level interrupts). Step by step, for a line that has both wake and interrupt enabled: 1. cur_mask[irq] = 1; wake_mask[irq] = 1; EINT_EN[irq] = 1 (interrupt enabled at hardware level) 2. System suspends, resumes due to that line (at this stage EINT_EN == wake_mask) 3. irq_pm_check_wakeup is called, and disables the interrupt => EINT_EN[irq] = 0, but we still have cur_mask[irq] = 1 4. mtk_eint_do_resume is called, and restores EINT_EN = cur_mask, so it reenables EINT_EN[irq] = 1 => interrupt storm as the driver is not yet ready to handle the interrupt. This patch fixes the issue in step 3, by recording all mask/unmask changes in cur_mask. This also avoids the need to read the current mask in eint_do_suspend, and we can remove mtk_eint_chip_read_mask function. The interrupt will be re-enabled properly later on, sometimes after mtk_eint_do_resume, when the driver is ready to handle it. Fixes: 58a5e1b64bb0 ("pinctrl: mediatek: Implement wake handler and suspend resume") Signed-off-by: Nicolas Boichat Acked-by: Sean Wang Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f6e01328cb0e4bc88172bc3e4c5afedb864a6b43 Author: Eiichi Tsukata Date: Thu Jun 27 11:47:32 2019 +0900 cpu/hotplug: Fix out-of-bounds read when setting fail state [ Upstream commit 33d4a5a7a5b4d02915d765064b2319e90a11cbde ] Setting invalid value to /sys/devices/system/cpu/cpuX/hotplug/fail can control `struct cpuhp_step *sp` address, results in the following global-out-of-bounds read. Reproducer: # echo -2 > /sys/devices/system/cpu/cpu0/hotplug/fail KASAN report: BUG: KASAN: global-out-of-bounds in write_cpuhp_fail+0x2cd/0x2e0 Read of size 8 at addr ffffffff89734438 by task bash/1941 CPU: 0 PID: 1941 Comm: bash Not tainted 5.2.0-rc6+ #31 Call Trace: write_cpuhp_fail+0x2cd/0x2e0 dev_attr_store+0x58/0x80 sysfs_kf_write+0x13d/0x1a0 kernfs_fop_write+0x2bc/0x460 vfs_write+0x1e1/0x560 ksys_write+0x126/0x250 do_syscall_64+0xc1/0x390 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f05e4f4c970 The buggy address belongs to the variable: cpu_hotplug_lock+0x98/0xa0 Memory state around the buggy address: ffffffff89734300: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff89734380: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff89734400: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa ^ ffffffff89734480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff89734500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Add a sanity check for the value written from user space. Fixes: 1db49484f21ed ("smp/hotplug: Hotplug state fail injection") Signed-off-by: Eiichi Tsukata Signed-off-by: Thomas Gleixner Cc: peterz@infradead.org Link: https://lkml.kernel.org/r/20190627024732.31672-1-devel@etsukata.com Signed-off-by: Sasha Levin commit fa99487a43cff7a5eca7f692c857052a0f7fb500 Author: Nicolas Boichat Date: Mon Apr 29 11:55:14 2019 +0800 pinctrl: mediatek: Ignore interrupts that are wake only during resume [ Upstream commit 35594bc7cecf3a78504b590e350570e8f4d7779e ] Before suspending, mtk-eint would set the interrupt mask to the one in wake_mask. However, some of these interrupts may not have a corresponding interrupt handler, or the interrupt may be disabled. On resume, the eint irq handler would trigger nevertheless, and irq/pm.c:irq_pm_check_wakeup would be called, which would try to call irq_disable. However, if the interrupt is not enabled (irqd_irq_disabled(&desc->irq_data) is true), the call does nothing, and the interrupt is left enabled in the eint driver. Especially for level-sensitive interrupts, this will lead to an interrupt storm on resume. If we detect that an interrupt is only in wake_mask, but not in cur_mask, we can just mask it out immediately (as mtk_eint_resume would do anyway at a later stage in the resume sequence, when restoring cur_mask). Fixes: bf22ff45bed6 ("genirq: Avoid unnecessary low level irq function calls") Signed-off-by: Nicolas Boichat Acked-by: Sean Wang Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit cd2646e57ec5a36a0c432345d6b9d5e4e0a45812 Author: Kai-Heng Feng Date: Fri Jun 14 16:56:55 2019 +0800 HID: multitouch: Add pointstick support for ALPS Touchpad [ Upstream commit 0a95fc733da375de0688d0f1fd3a2869a1c1d499 ] There's a new ALPS touchpad/pointstick combo device that requires MT_CLS_WIN_8_DUAL to make its pointsitck work as a mouse. The device can be found on HP ZBook 17 G5. Signed-off-by: Kai-Heng Feng Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9ea3b131441eb58859522c24842434ac95794ed3 Author: Oleksandr Natalenko Date: Fri Jun 21 11:17:36 2019 +0200 HID: chicony: add another quirk for PixArt mouse [ Upstream commit dcf768b0ac868630e7bdb6f2f1c9fe72788012fa ] I've spotted another Chicony PixArt mouse in the wild, which requires HID_QUIRK_ALWAYS_POLL quirk, otherwise it disconnects each minute. USB ID of this device is 0x04f2:0x0939. We've introduced quirks like this for other models before, so lets add this mouse too. Link: https://github.com/sriemer/fix-linux-mouse#usb-mouse-disconnectsreconnects-every-minute-on-linux Signed-off-by: Oleksandr Natalenko Acked-by: Sebastian Parschauer Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 94968c37b6d37ccf02d3d58e2d2e8b8f262bd300 Author: Kirill A. Shutemov Date: Thu Jun 20 14:24:22 2019 +0300 x86/boot/64: Add missing fixup_pointer() for next_early_pgt access [ Upstream commit c1887159eb48ba40e775584cfb2a443962cf1a05 ] __startup_64() uses fixup_pointer() to access global variables in a position-independent fashion. Access to next_early_pgt was wrapped into the helper, but one instance in the 5-level paging branch was missed. GCC generates a R_X86_64_PC32 PC-relative relocation for the access which doesn't trigger the issue, but Clang emmits a R_X86_64_32S which leads to an invalid memory access and system reboot. Fixes: 187e91fe5e91 ("x86/boot/64/clang: Use fixup_pointer() to access 'next_early_pgt'") Signed-off-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Alexander Potapenko Link: https://lkml.kernel.org/r/20190620112422.29264-1-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit 729d25f43b64986c1978c5235e2463d4478e1b46 Author: Kirill A. Shutemov Date: Thu Jun 20 14:23:45 2019 +0300 x86/boot/64: Fix crash if kernel image crosses page table boundary [ Upstream commit 81c7ed296dcd02bc0b4488246d040e03e633737a ] A kernel which boots in 5-level paging mode crashes in a small percentage of cases if KASLR is enabled. This issue was tracked down to the case when the kernel image unpacks in a way that it crosses an 1G boundary. The crash is caused by an overrun of the PMD page table in __startup_64() and corruption of P4D page table allocated next to it. This particular issue is not visible with 4-level paging as P4D page tables are not used. But the P4D and the PUD calculation have similar problems. The PMD index calculation is wrong due to operator precedence, which fails to confine the PMDs in the PMD array on wrap around. The P4D calculation for 5-level paging and the PUD calculation calculate the first index correctly, but then blindly increment it which causes the same issue when a kernel image is located across a 512G and for 5-level paging across a 46T boundary. This wrap around mishandling was introduced when these parts moved from assembly to C. Restore it to the correct behaviour. Fixes: c88d71508e36 ("x86/boot/64: Rewrite startup_64() in C") Signed-off-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Link: https://lkml.kernel.org/r/20190620112345.28833-1-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit 136847140cc891a875fce5cfdc4886eacfe1f767 Author: Milan Broz Date: Thu Jun 20 13:00:19 2019 +0200 dm verity: use message limit for data block corruption message [ Upstream commit 2eba4e640b2c4161e31ae20090a53ee02a518657 ] DM verity should also use DMERR_LIMIT to limit repeat data block corruption messages. Signed-off-by: Milan Broz Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 042be78692aee2649c58c41ddca04e5ae3441050 Author: Jerome Marchand Date: Wed Jun 12 18:22:26 2019 +0200 dm table: don't copy from a NULL pointer in realloc_argv() [ Upstream commit a0651926553cfe7992166432e418987760882652 ] For the first call to realloc_argv() in dm_split_args(), old_argv is NULL and size is zero. Then memcpy is called, with the NULL old_argv as the source argument and a zero size argument. AFAIK, this is undefined behavior and generates the following warning when compiled with UBSAN on ppc64le: In file included from ./arch/powerpc/include/asm/paca.h:19, from ./arch/powerpc/include/asm/current.h:16, from ./include/linux/sched.h:12, from ./include/linux/kthread.h:6, from drivers/md/dm-core.h:12, from drivers/md/dm-table.c:8: In function 'memcpy', inlined from 'realloc_argv' at drivers/md/dm-table.c:565:3, inlined from 'dm_split_args' at drivers/md/dm-table.c:588:9: ./include/linux/string.h:345:9: error: argument 2 null where non-null expected [-Werror=nonnull] return __builtin_memcpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/md/dm-table.c: In function 'dm_split_args': ./include/linux/string.h:345:9: note: in a call to built-in function '__builtin_memcpy' Signed-off-by: Jerome Marchand Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 0fc080bc9a725ab4067a65e809cd029dcffd2540 Author: Phil Reid Date: Thu Jun 13 12:10:23 2019 +0800 pinctrl: mcp23s08: Fix add_data and irqchip_add_nested call order [ Upstream commit 6dbc6e6f58556369bf999cd7d9793586f1b0e4b4 ] Currently probing of the mcp23s08 results in an error message "detected irqchip that is shared with multiple gpiochips: please fix the driver" This is due to the following: Call to mcp23s08_irqchip_setup() with call hierarchy: mcp23s08_irqchip_setup() gpiochip_irqchip_add_nested() gpiochip_irqchip_add_key() gpiochip_set_irq_hooks() Call to devm_gpiochip_add_data() with call hierarchy: devm_gpiochip_add_data() gpiochip_add_data_with_key() gpiochip_add_irqchip() gpiochip_set_irq_hooks() The gpiochip_add_irqchip() returns immediately if there isn't a irqchip but we added a irqchip due to the previous mcp23s08_irqchip_setup() call. So it calls gpiochip_set_irq_hooks() a second time. Fix this by moving the call to devm_gpiochip_add_data before the call to mcp23s08_irqchip_setup Fixes: 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order") Suggested-by: Marco Felsch Signed-off-by: Phil Reid Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 00640eb0eafa0ef8d5f2962c44e362e5225915b6 Author: Sébastien Szymanski Date: Tue Jun 18 17:58:34 2019 +0200 ARM: dts: imx6ul: fix PWM[1-4] interrupts [ Upstream commit 3cf10132ac8d536565f2c02f60a3aeb315863a52 ] According to the i.MX6UL/L RM, table 3.1 "ARM Cortex A7 domain interrupt summary", the interrupts for the PWM[1-4] go from 83 to 86. Fixes: b9901fe84f02 ("ARM: dts: imx6ul: add pwm[1-4] nodes") Signed-off-by: Sébastien Szymanski Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a8cc2a2c2841f8e86089e6fd7d39e889c240127f Author: Sergej Benilov Date: Thu Jun 20 11:02:18 2019 +0200 sis900: fix TX completion [ Upstream commit 8ac8a01092b2added0749ef937037bf1912e13e3 ] Since commit 605ad7f184b60cfaacbc038aa6c55ee68dee3c89 "tcp: refine TSO autosizing", outbound throughput is dramatically reduced for some connections, as sis900 is doing TX completion within idle states only. Make TX completion happen after every transmitted packet. Test: netperf before patch: > netperf -H remote -l -2000000 -- -s 1000000 MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 327680 327680 253.44 0.06 after patch: > netperf -H remote -l -10000000 -- -s 1000000 MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 327680 327680 5.38 14.89 Thx to Dave Miller and Eric Dumazet for helpful hints Signed-off-by: Sergej Benilov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3232bccddebab7a80e70c42c7b8d1a73e32dbe85 Author: Takashi Iwai Date: Wed Jun 19 15:34:07 2019 +0200 ppp: mppe: Add softdep to arc4 [ Upstream commit aad1dcc4f011ea409850e040363dff1e59aa4175 ] The arc4 crypto is mandatory at ppp_mppe probe time, so let's put a softdep line, so that the corresponding module gets prepared gracefully. Without this, a simple inclusion to initrd via dracut failed due to the missing dependency, for example. Signed-off-by: Takashi Iwai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ec7753c7c9e3be6a326a86d7f73a138addfe0eb Author: Petr Oros Date: Wed Jun 19 14:29:42 2019 +0200 be2net: fix link failure after ethtool offline test [ Upstream commit 2e5db6eb3c23e5dc8171eb8f6af7a97ef9fcf3a9 ] Certain cards in conjunction with certain switches need a little more time for link setup that results in ethtool link test failure after offline test. Patch adds a loop that waits for a link setup finish. Changes in v2: - added fixes header Fixes: 4276e47e2d1c ("be2net: Add link test to list of ethtool self tests.") Signed-off-by: Petr Oros Reviewed-by: Ivan Vecera Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2a6ee36917f02682e387d3e127af06bcb4a66aad Author: Colin Ian King Date: Wed Jun 19 19:14:46 2019 +0100 x86/apic: Fix integer overflow on 10 bit left shift of cpu_khz [ Upstream commit ea136a112d89bade596314a1ae49f748902f4727 ] The left shift of unsigned int cpu_khz will overflow for large values of cpu_khz, so cast it to a long long before shifting it to avoid overvlow. For example, this can happen when cpu_khz is 4194305, i.e. ~4.2 GHz. Addresses-Coverity: ("Unintentional integer overflow") Fixes: 8c3ba8d04924 ("x86, apic: ack all pending irqs when crashed/on kexec") Signed-off-by: Colin Ian King Signed-off-by: Thomas Gleixner Cc: Borislav Petkov Cc: "H . Peter Anvin" Cc: kernel-janitors@vger.kernel.org Link: https://lkml.kernel.org/r/20190619181446.13635-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit fdfff855cd3633680d26872771d10aeab0b7f340 Author: David Howells Date: Thu Jun 20 16:49:35 2019 +0100 afs: Fix uninitialised spinlock afs_volume::cb_break_lock [ Upstream commit 90fa9b64523a645a97edc0bdcf2d74759957eeee ] Fix the cb_break_lock spinlock in afs_volume struct by initialising it when the volume record is allocated. Also rename the lock to cb_v_break_lock to distinguish it from the lock of the same name in the afs_server struct. Without this, the following trace may be observed when a volume-break callback is received: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 50 Comm: kworker/2:1 Not tainted 5.2.0-rc1-fscache+ #3045 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Workqueue: afs SRXAFSCB_CallBack Call Trace: dump_stack+0x67/0x8e register_lock_class+0x23b/0x421 ? check_usage_forwards+0x13c/0x13c __lock_acquire+0x89/0xf73 lock_acquire+0x13b/0x166 ? afs_break_callbacks+0x1b2/0x3dd _raw_write_lock+0x2c/0x36 ? afs_break_callbacks+0x1b2/0x3dd afs_break_callbacks+0x1b2/0x3dd ? trace_event_raw_event_afs_server+0x61/0xac SRXAFSCB_CallBack+0x11f/0x16c process_one_work+0x2c5/0x4ee ? worker_thread+0x234/0x2ac worker_thread+0x1d8/0x2ac ? cancel_delayed_work_sync+0xf/0xf kthread+0x11f/0x127 ? kthread_park+0x76/0x76 ret_from_fork+0x24/0x30 Fixes: 68251f0a6818 ("afs: Fix whole-volume callback handling") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit d47f06ab0c0e8b95851f00723dfddbe9c4af5b9c Author: Arnd Bergmann Date: Wed Jun 19 15:04:54 2019 +0200 ARM: omap2: remove incorrect __init annotation [ Upstream commit 27e23d8975270df6999f8b5b3156fc0c04927451 ] omap3xxx_prm_enable_io_wakeup() is marked __init, but its caller is not, so we get a warning with clang-8: WARNING: vmlinux.o(.text+0x343c8): Section mismatch in reference from the function omap3xxx_prm_late_init() to the function .init.text:omap3xxx_prm_enable_io_wakeup() The function omap3xxx_prm_late_init() references the function __init omap3xxx_prm_enable_io_wakeup(). This is often because omap3xxx_prm_late_init lacks a __init annotation or the annotation of omap3xxx_prm_enable_io_wakeup is wrong. When building with gcc, omap3xxx_prm_enable_io_wakeup() is always inlined, so we never noticed in the past. Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Acked-by: Tony Lindgren Reviewed-by: Andrew Murray Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 5d3c45538151cbf89639290f3f110c937f68a4bb Author: Linus Walleij Date: Sun Jun 16 23:40:13 2019 +0200 ARM: dts: gemini Fix up DNS-313 compatible string [ Upstream commit 36558020128b1a48b7bddd5792ee70e3f64b04b0 ] It's a simple typo in the DNS file, which was pretty serious. No scripts were working properly. Fix it up. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit afda29dc5ac6b6cda0d8cd6316e10ed7dff574f4 Author: Peter Zijlstra Date: Wed May 29 14:37:24 2019 +0200 perf/core: Fix perf_sample_regs_user() mm check [ Upstream commit 085ebfe937d7a7a5df1729f35a12d6d655fea68c ] perf_sample_regs_user() uses 'current->mm' to test for the presence of userspace, but this is insufficient, consider use_mm(). A better test is: '!(current->flags & PF_KTHREAD)', exec() clears PF_KTHREAD after it sets the new ->mm but before it drops to userspace for the first time. Possibly obsoletes: bf05fc25f268 ("powerpc/perf: Fix oops when kthread execs user process") Reported-by: Ravi Bangoria Reported-by: Young Xiao <92siuyang@gmail.com> Signed-off-by: Peter Zijlstra (Intel) Acked-by: Will Deacon Cc: Arnaldo Carvalho de Melo Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Linus Torvalds Cc: Michael Ellerman Cc: Naveen N. Rao Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Fixes: 4018994f3d87 ("perf: Add ability to attach user level registers dump to sample") Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 627fdcc9b718e05d3aae886693c9388b4cb595a2 Author: Hans de Goede Date: Wed May 29 15:28:28 2019 +0200 efi/bgrt: Drop BGRT status field reserved bits check [ Upstream commit a483fcab38b43fb34a7f12ab1daadd3907f150e2 ] Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer reserved. These bits are now used to indicate if the image needs to be rotated before being displayed. The first device using these bits has now shown up (the GPD MicroPC) and the reserved bits check causes us to reject the valid BGRT table on this device. Rather then changing the reserved bits check, allowing only the 2 new bits, instead just completely remove it so that we do not end up with a similar problem when more bits are added in the future. Signed-off-by: Hans de Goede Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit cf4deb2d4de6951ca30ce34f71c19e39ec92af57 Author: Tony Lindgren Date: Wed May 29 23:55:57 2019 -0700 clk: ti: clkctrl: Fix returning uninitialized data [ Upstream commit 41b3588dba6ef4b7995735a97e47ff0aeea6c276 ] If we do a clk_get() for a clock that does not exists, we have _ti_omap4_clkctrl_xlate() return uninitialized data if no match is found. This can be seen in some cases with SLAB_DEBUG enabled: Unable to handle kernel paging request at virtual address 5a5a5a5a ... clk_hw_create_clk.part.33 sysc_notifier_call notifier_call_chain blocking_notifier_call_chain device_add Let's fix this by setting a found flag only when we find a match. Reported-by: Tomi Valkeinen Fixes: 88a172526c32 ("clk: ti: add support for clkctrl clocks") Signed-off-by: Tony Lindgren Tested-by: Peter Ujfalusi Tested-by: Tomi Valkeinen Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit ff232a47567f57852fec1cecdbdc2dc092e2f7d5 Author: Heyi Guo Date: Mon May 13 19:42:06 2019 +0800 irqchip/gic-v3-its: Fix command queue pointer comparison bug [ Upstream commit a050fa5476d418fc16b25abe168b3d38ba11e13c ] When we run several VMs with PCI passthrough and GICv4 enabled, not pinning vCPUs, we will occasionally see below warnings in dmesg: ITS queue timeout (65440 65504 480) ITS cmd its_build_vmovp_cmd failed The reason for the above issue is that in BUILD_SINGLE_CMD_FUNC: 1. Post the write command. 2. Release the lock. 3. Start to read GITS_CREADR to get the reader pointer. 4. Compare the reader pointer to the target pointer. 5. If reader pointer does not reach the target, sleep 1us and continue to try. If we have several processors running the above concurrently, other CPUs will post write commands while the 1st CPU is waiting the completion. So we may have below issue: phase 1: ---rd_idx-----from_idx-----to_idx--0--------- wait 1us: phase 2: --------------from_idx-----to_idx--0-rd_idx-- That is the rd_idx may fly ahead of to_idx, and if in case to_idx is near the wrap point, rd_idx will wrap around. So the below condition will not be met even after 1s: if (from_idx < to_idx && rd_idx >= to_idx) There is another theoretical issue. For a slow and busy ITS, the initial rd_idx may fall behind from_idx a lot, just as below: ---rd_idx---0--from_idx-----to_idx----------- This will cause the wait function exit too early. Actually, it does not make much sense to use from_idx to judge if to_idx is wrapped, but we need a initial rd_idx when lock is still acquired, and it can be used to judge whether to_idx is wrapped and the current rd_idx is wrapped. We switch to a method of calculating the delta of two adjacent reads and accumulating it to get the sum, so that we can get the real rd_idx from the wrapped value even when the queue is almost full. Cc: Thomas Gleixner Cc: Jason Cooper Signed-off-by: Heyi Guo Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 244db54441a110906d770f777d78abffa732b915 Author: Sven Van Asbroeck Date: Mon Jun 17 14:23:54 2019 -0400 firmware: improve LSM/IMA security behaviour commit 2472d64af2d3561954e2f05365a67692bb852f2a upstream. The firmware loader queries if LSM/IMA permits it to load firmware via the sysfs fallback. Unfortunately, the code does the opposite: it expressly permits sysfs fw loading if security_kernel_load_data( LOADING_FIRMWARE) returns -EACCES. This happens because a zero-on-success return value is cast to a bool that's true on success. Fix the return value handling so we get the correct behaviour. Fixes: 6e852651f28e ("firmware: add call to LSM hook before firmware sysfs fallback") Cc: Stable Cc: Mimi Zohar Cc: Kees Cook To: Luis Chamberlain Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: linux-kernel@vger.kernel.org Signed-off-by: Sven Van Asbroeck Reviewed-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 079d7f16a9738f8ea8a71671f5481f9b5049da3a Author: James Morse Date: Mon Jun 24 18:36:56 2019 +0100 drivers: base: cacheinfo: Ensure cpu hotplug work is done before Intel RDT commit 83b44fe343b5abfcb1b2261289bd0cfcfcfd60a8 upstream. The cacheinfo structures are alloced/freed by cpu online/offline callbacks. Originally these were only used by sysfs to expose the cache topology to user space. Without any in-kernel dependencies CPUHP_AP_ONLINE_DYN was an appropriate choice. resctrl has started using these structures to identify CPUs that share a cache. It updates its 'domain' structures from cpu online/offline callbacks. These depend on the cacheinfo structures (resctrl_online_cpu()->domain_add_cpu()->get_cache_id()-> get_cpu_cacheinfo()). These also run as CPUHP_AP_ONLINE_DYN. Now that there is an in-kernel dependency, move the cacheinfo work earlier so we know its done before resctrl's CPUHP_AP_ONLINE_DYN work runs. Fixes: 2264d9c74dda1 ("x86/intel_rdt: Build structures for each resource based on cache topology") Cc: Cc: Fenghua Yu Cc: Reinette Chatre Signed-off-by: James Morse Link: https://lore.kernel.org/r/20190624173656.202407-1-james.morse@arm.com Signed-off-by: Greg Kroah-Hartman commit 68048dce650eda36076793f4f894e2d019dcc4a7 Author: Masahiro Yamada Date: Thu Jul 11 20:52:18 2019 -0700 nilfs2: do not use unexported cpu_to_le32()/le32_to_cpu() in uapi header commit c32cc30c0544f13982ee0185d55f4910319b1a79 upstream. cpu_to_le32/le32_to_cpu is defined in include/linux/byteorder/generic.h, which is not exported to user-space. UAPI headers must use the ones prefixed with double-underscore. Detected by compile-testing exported headers: include/linux/nilfs2_ondisk.h: In function `nilfs_checkpoint_set_snapshot': include/linux/nilfs2_ondisk.h:536:17: error: implicit declaration of function `cpu_to_le32' [-Werror=implicit-function-declaration] cp->cp_flags = cpu_to_le32(le32_to_cpu(cp->cp_flags) | \ ^ include/linux/nilfs2_ondisk.h:552:1: note: in expansion of macro `NILFS_CHECKPOINT_FNS' NILFS_CHECKPOINT_FNS(SNAPSHOT, snapshot) ^~~~~~~~~~~~~~~~~~~~ include/linux/nilfs2_ondisk.h:536:29: error: implicit declaration of function `le32_to_cpu' [-Werror=implicit-function-declaration] cp->cp_flags = cpu_to_le32(le32_to_cpu(cp->cp_flags) | \ ^ include/linux/nilfs2_ondisk.h:552:1: note: in expansion of macro `NILFS_CHECKPOINT_FNS' NILFS_CHECKPOINT_FNS(SNAPSHOT, snapshot) ^~~~~~~~~~~~~~~~~~~~ include/linux/nilfs2_ondisk.h: In function `nilfs_segment_usage_set_clean': include/linux/nilfs2_ondisk.h:622:19: error: implicit declaration of function `cpu_to_le64' [-Werror=implicit-function-declaration] su->su_lastmod = cpu_to_le64(0); ^~~~~~~~~~~ Link: http://lkml.kernel.org/r/20190605053006.14332-1-yamada.masahiro@socionext.com Fixes: e63e88bc53ba ("nilfs2: move ioctl interface and disk layout to uapi separately") Signed-off-by: Masahiro Yamada Acked-by: Ryusuke Konishi Cc: Arnd Bergmann Cc: Greg KH Cc: Joe Perches Cc: [4.9+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 86859ef10d259f38aab80dc79f67d9f862f3e56d Author: Cole Rogers Date: Mon Jul 1 00:47:48 2019 -0700 Input: synaptics - enable SMBUS on T480 thinkpad trackpad commit abbe3acd7d72ab4633ade6bd24e8306b67e0add3 upstream. Thinkpad t480 laptops had some touchpad features disabled, resulting in the loss of pinch to activities in GNOME, on wayland, and other touch gestures being slower. This patch adds the touchpad of the t480 to the smbus_pnp_ids whitelist to enable the extra features. In my testing this does not break suspend (on fedora, with wayland, and GNOME, using the rc-6 kernel), while also fixing the feature on a T480. Signed-off-by: Cole Rogers Acked-by: Benjamin Tissoires Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 438a3dc6f2c334932b44a103e76dbc19de50902e Author: Konstantin Khlebnikov Date: Wed Apr 17 11:13:20 2019 +0300 e1000e: start network tx queue only when link is up commit d17ba0f616a08f597d9348c372d89b8c0405ccf3 upstream. Driver does not want to keep packets in Tx queue when link is lost. But present code only reset NIC to flush them, but does not prevent queuing new packets. Moreover reset sequence itself could generate new packets via netconsole and NIC falls into endless reset loop. This patch wakes Tx queue only when NIC is ready to send packets. This is proper fix for problem addressed by commit 0f9e980bf5ee ("e1000e: fix cyclic resets at link up with active tx"). Signed-off-by: Konstantin Khlebnikov Suggested-by: Alexander Duyck Tested-by: Joseph Yasi Tested-by: Aaron Brown Tested-by: Oleksandr Natalenko Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 8020568b404bdda1770125d3d00e18c489c92e57 Author: Konstantin Khlebnikov Date: Wed Apr 17 11:13:16 2019 +0300 Revert "e1000e: fix cyclic resets at link up with active tx" commit caff422ea81e144842bc44bab408d85ac449377b upstream. This reverts commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61. That change cased false-positive warning about hardware hang: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang: TDH <0> TDT <1> next_to_use <1> next_to_clean <0> buffer_info[next_to_clean]: time_stamp next_to_watch <0> jiffies next_to_watch.status <0> MAC Status <40080080> PHY Status <7949> PHY 1000BASE-T Status <0> PHY Extended Status <3000> PCI Status <10> e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Besides warning everything works fine. Original issue will be fixed property in following patch. Signed-off-by: Konstantin Khlebnikov Reported-by: Joseph Yasi Link: https://bugzilla.kernel.org/show_bug.cgi?id=203175 Tested-by: Joseph Yasi Tested-by: Aaron Brown Tested-by: Oleksandr Natalenko Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman