CVE-2019-15216

commit 274ede3e1a5fb3d0fd33acafb08993e95972c51f Author: Greg Kroah-Hartman Date: Wed May 8 07:23:00 2019 +0200 Linux 5.0.14 commit f4572f615a4f6d4e7f746176c223c9d2caa316e2 Author: Arnd Bergmann Date: Thu Apr 18 17:50:48 2019 -0700 mm/kmemleak.c: fix unused-function warning commit dce5b0bdeec61bdbee56121ceb1d014151d5cab1 upstream. The only references outside of the #ifdef have been removed, so now we get a warning in non-SMP configurations: mm/kmemleak.c:1404:13: error: unused function ‘scan_large_block’ [-Werror,-Wunused-function] Add a new #ifdef around it. Link: http://lkml.kernel.org/r/[email protected] Fixes: 298a32b13208 (“kmemleak: powerpc: skip scanning holes in the .bss section”) Signed-off-by: Arnd Bergmann Acked-by: Catalin Marinas Cc: Vincent Whitchurch Cc: Michael Ellerman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit ec031ab048703ee0602948bb2bd7820464df3e9a Author: Charles Keepax Date: Tue Apr 2 13:49:14 2019 +0100 ASoC: wm_adsp: Check for buffer in trigger stop commit 43d147be5738a9ed6cfb25c285ac50d6dd5793be upstream. Trigger stop can be called in situations where trigger start failed and as such it can’t be assumed the buffer is already attached to the compressed stream or a NULL pointer may be dereferenced. Fixes: 639e5eb3c7d6 (“ASoC: wm_adsp: Correct handling of compressed streams that restart”) Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit 387b15d5f8edd2a88739314031c040b4cba03cf5 Author: Jacopo Mondi Date: Fri Dec 29 07:22:26 2017 -0500 media: v4l2: i2c: ov7670: Fix PLL bypass register values commit 61da76beef1e4f0b6ba7be4f8d0cf0dac7ce1f55 upstream. The following commits: commit f6dd927f34d6 ("[media] media: ov7670: calculate framerate properly for ov7675") commit 04ee6d92047e ("[media] media: ov7670: add possibility to bypass pll for ov7675") introduced the ability to bypass PLL multiplier and use input clock (xvclk) as pixel clock output frequency for ov7675 sensor. PLL is bypassed using register DBLV[7:6], according to ov7670 and ov7675 sensor manuals. Macros used to set DBLV register seem wrong in the driver, as their values do not match what reported in the datasheet. Fix by changing DBLV_* macros to use bits [7:6] and set bits [3:0] to default 0x0a reserved value (according to datasheets). While at there, remove a write to DBLV register in “ov7675_set_framerate()" that over-writes the previous one to the same register that takes “info->pll_bypass” flag into account instead of setting PLL multiplier to 4x unconditionally. And, while at there, since “info->pll_bypass” is only used in set/get_framerate() functions used by ov7675 only, it is not necessary to check for the device id at probe time to make sure that when using ov7670 “info->pll_bypass” is set to false. Fixes: f6dd927f34d6 ("[media] media: ov7670: calculate framerate properly for ov7675”) Signed-off-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8259fd1be8d1e080cd0a85360f14bc9de0b2d363 Author: Nicolas Le Bayon Date: Wed Mar 6 15:12:16 2019 +0000 i2c: i2c-stm32f7: Fix SDADEL minimum formula commit c86da50cfd840edf223a242580913692acddbcf6 upstream. It conforms with Reference Manual I2C timing section. Fixes: aeb068c57214 (“i2c: i2c-stm32f7: add driver”) Signed-off-by: Nicolas Le Bayon Signed-off-by: Bich Hemon Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit b304ba5ca081051a6c015ec2acffb19d27aa979b Author: Peter Zijlstra Date: Tue Apr 16 10:03:35 2019 +0200 x86/mm/tlb: Revert “x86/mm: Align TLB invalidation info” commit 780e0106d468a2962b16b52fdf42898f2639e0a0 upstream. Revert the following commit: 515ab7c41306: (“x86/mm: Align TLB invalidation info”) I found out (the hard way) that under some .config options (notably L1_CACHE_SHIFT=7) and compiler combinations this on-stack alignment leads to a 320 byte stack usage, which then triggers a KASAN stack warning elsewhere. Using 320 bytes of stack space for a 40 byte structure is ludicrous and clearly not right. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Linus Torvalds Acked-by: Nadav Amit Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 515ab7c41306 (“x86/mm: Align TLB invalidation info”) Link: http://lkml.kernel.org/r/[email protected] [ Minor changelog edits. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 8ecf2c08aee9a076ee46277e1248052089b426c9 Author: Qian Cai Date: Tue Apr 23 12:58:11 2019 -0400 x86/mm: Fix a crash with kmemleak_scan() commit 0d02113b31b2017dd349ec9df2314e798a90fa6e upstream. The first kmemleak_scan() call after boot would trigger the crash below because this callpath: kernel_init free_initmem mem_encrypt_free_decrypted_mem free_init_pages unmaps memory inside the .bss when DEBUG_PAGEALLOC=y. kmemleak_init() will register the .data/.bss sections and then kmemleak_scan() will scan those addresses and dereference them looking for pointer references. If free_init_pages() frees and unmaps pages in those sections, kmemleak_scan() will crash if referencing one of those addresses: BUG: unable to handle kernel paging request at ffffffffbd402000 CPU: 12 PID: 325 Comm: kmemleak Not tainted 5.1.0-rc4+ #4 RIP: 0010:scan_block Call Trace: scan_gray_list kmemleak_scan kmemleak_scan_thread kthread ret_from_fork Since kmemleak_free_part() is tolerant to unknown objects (not tracked by kmemleak), it is fine to call it from free_init_pages() even if not all address ranges passed to this function are known to kmemleak. [ bp: Massage. ] Fixes: b3f0907c71e0 (“x86/mm: Add .bss…decrypted section to hold shared variables”) Signed-off-by: Qian Cai Signed-off-by: Borislav Petkov Reviewed-by: Catalin Marinas Cc: Andy Lutomirski Cc: Brijesh Singh Cc: Dave Hansen Cc: “H. Peter Anvin” Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 245a1a555e337bfd06d35786d56660fcae164e36 Author: Baoquan He Date: Thu Apr 4 10:03:13 2019 +0800 x86/mm/KASLR: Fix the size of the direct mapping section commit ec3937107ab43f3e8b2bc9dad95710043c462ff7 upstream. kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate the maximum amount of system RAM supported. The size of the direct mapping section is obtained from the smaller one of the below two values: (actual system RAM size + padding size) vs (max system RAM size supported) This calculation is wrong since commit b83ce5ee9147 (“x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52”). In it, __PHYSICAL_MASK_SHIFT was changed to be 52, regardless of whether the kernel is using 4-level or 5-level page tables. Thus, it will always use 4 PB as the maximum amount of system RAM, even in 4-level paging mode where it should actually be 64 TB. Thus, the size of the direct mapping section will always be the sum of the actual system RAM size plus the padding size. Even when the amount of system RAM is 64 TB, the following layout will still be used. Obviously KALSR will be weakened significantly. |____|_______actual RAM_______|_padding_|______the rest_______| 0 64TB ~120TB Instead, it should be like this: |____|_______actual RAM_______|_________the rest______________| 0 64TB ~120TB The size of padding region is controlled by CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, which is 10 TB by default. The above issue only exists when CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING is set to a non-zero value, which is the case when CONFIG_MEMORY_HOTPLUG is enabled. Otherwise, using __PHYSICAL_MASK_SHIFT doesn’t affect KASLR. Fix it by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS. [ bp: Massage commit message. ] Fixes: b83ce5ee9147 (“x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52”) Signed-off-by: Baoquan He Signed-off-by: Borislav Petkov Reviewed-by: Thomas Garnier Acked-by: Kirill A. Shutemov Cc: “H. Peter Anvin” Cc: Andy Lutomirski Cc: Dave Hansen Cc: Ingo Molnar Cc: Kees Cook Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: x86-ml Cc: [email protected] Link: https://lkml.kernel.org/r/20190417083536.GE7065@MiWiFi-R3L-srv Signed-off-by: Greg Kroah-Hartman commit ad5ef880a0e38162adea1b4c50597a395402814f Author: David Müller Date: Mon Apr 8 15:33:54 2019 +0200 clk: x86: Add system specific quirk to mark clocks as critical commit 7c2e07130090ae001a97a6b65597830d6815e93e upstream. Since commit 648e921888ad (“clk: x86: Stop marking clocks as CLK_IS_CRITICAL”), the pmc_plt_clocks of the Bay Trail SoC are unconditionally gated off. Unfortunately this will break systems where these clocks are used for external purposes beyond the kernel’s knowledge. Fix it by implementing a system specific quirk to mark the necessary pmc_plt_clks as critical. Fixes: 648e921888ad (“clk: x86: Stop marking clocks as CLK_IS_CRITICAL”) Signed-off-by: David Müller Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 9e5b35b444789f402b6f251dd2e51eeb16e7dfe0 Author: Tony Luck Date: Mon Feb 25 12:59:40 2019 -0800 x86/mce: Improve error message when kernel cannot recover, p2 commit 41f035a86b5b72a4f947c38e94239d20d595352a upstream. In c7d606f560e4 (“x86/mce: Improve error message when kernel cannot recover”) a case was added for a machine check caused by a DATA access to poison memory from the kernel. A case should have been added also for an uncorrectable error during an instruction fetch in the kernel. Add that extra case so the error message now reads: mce: [Hardware Error]: Machine check: Instruction fetch error in kernel Fixes: c7d606f560e4 (“x86/mce: Improve error message when kernel cannot recover”) Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Cc: “H. Peter Anvin” Cc: Ingo Molnar Cc: Pu Wen Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit aafdf8479a7f09c988f38c426530456aabf73dd7 Author: Aneesh Kumar K.V Date: Tue Feb 26 10:09:35 2019 +0530 powerpc/mm/hash: Handle mmap_min_addr correctly in get_unmapped_area topdown search commit 3b4d07d2674f6b4a9281031f99d1f7efd325b16d upstream. When doing top-down search the low_limit is not PAGE_SIZE but rather max(PAGE_SIZE, mmap_min_addr). This handle cases in which mmap_min_addr > PAGE_SIZE. Fixes: fba2369e6ceb (“mm: use vm_unmapped_area() on powerpc architecture”) Reviewed-by: Laurent Dufour Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 0f92374871e4f2c926866a680d6e79d8f8686343 Author: Alexander Wetzel Date: Sat Feb 9 15:01:38 2019 +0100 mac80211: Honor SW_CRYPTO_CONTROL for unicast keys in AP VLAN mode commit 78ad2341521d5ea96cb936244ed4c4c4ef9ec13b upstream. Restore SW_CRYPTO_CONTROL operation on AP_VLAN interfaces for unicast keys, the original override was intended to be done for group keys as those are treated specially by mac80211 and would always have been rejected. Now the situation is that AP_VLAN support must be enabled by the driver if it can support it (meaning it can support software crypto GTK TX). Thus, also simplify the code - if we get here with AP_VLAN and non- pairwise key, software crypto must be used (driver doesn’t know about the interface) and can be used (driver must’ve advertised AP_VLAN if it also uses SW_CRYPTO_CONTROL). Fixes: db3bdcb9c3ff (“mac80211: allow AP_VLAN operation on crypto controlled devices”) Signed-off-by: Alexander Wetzel [rewrite commit message] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 420e89889f62af93cc2fde1ccdaf6b767318be28 Author: Ondrej Mosnacek Date: Fri Dec 21 21:18:52 2018 +0100 selinux: never allow relabeling on context mounts commit a83d6ddaebe541570291205cb538e35ad4ff94f9 upstream. In the SECURITY_FS_USE_MNTPOINT case we never want to allow relabeling files/directories, so we should never set the SBLABEL_MNT flag. The ‘special handling’ in selinux_is_sblabel_mnt() is only intended for when the behavior is set to SECURITY_FS_USE_GENFS. While there, make the logic in selinux_is_sblabel_mnt() more explicit and add a BUILD_BUG_ON() to make sure that introducing a new SECURITY_FS_USE_* forces a review of the logic. Fixes: d5f3a5f6e7e7 (“selinux: add security in-core xattr support for pstore and debugfs”) Signed-off-by: Ondrej Mosnacek Reviewed-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit b7e8c254560a057561644b28074be697336f1ec6 Author: Stephen Smalley Date: Wed Dec 12 10:10:55 2018 -0500 selinux: avoid silent denials in permissive mode under RCU walk commit 3a28cff3bd4bf43f02be0c4e7933aebf3dc8197e upstream. commit 0dc1ba24f7fff6 (“SELINUX: Make selinux cache VFS RCU walks safe”) results in no audit messages at all if in permissive mode because the cache is updated during the rcu walk and thus no denial occurs on the subsequent ref walk. Fix this by not updating the cache when performing a non-blocking permission check. This only affects search and symlink read checks during rcu walk. Fixes: 0dc1ba24f7fff6 (“SELINUX: Make selinux cache VFS RCU walks safe”) Reported-by: BMK Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit a3769982eceeb4a0ff4970210c6cdb55252e28fb Author: Anson Huang Date: Sat Feb 23 03:18:25 2019 +0000 gpio: mxc: add check to return defer probe if clock tree NOT ready commit a329bbe707cee2cf8c660890ef2ad0d00ec7e8a3 upstream. On i.MX8MQ platform, clock driver uses platform driver model and it is probed after GPIO driver, so when GPIO driver fails to get clock, it should check the error type to decide whether to return defer probe or just ignore the clock operation. Fixes: 2808801aab8a (“gpio: mxc: add clock operation”) Signed-off-by: Anson Huang Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 92cd6ae804615d0f415191319315ca6bbf4651d6 Author: Dmitry Torokhov Date: Tue Feb 5 14:40:40 2019 -0800 Input: stmfts - acknowledge that setting brightness is a blocking call commit 937c4e552fd1174784045684740edfcea536159d upstream. We need to turn regulators on and off when switching brightness, and that may block, therefore we have to set stmfts_brightness_set() as LED’s brightness_set_blocking() method. Fixes: 78bcac7b2ae1 (“Input: add support for the STMicroelectronics FingerTip touchscreen”) Acked-by: Andi Shyti Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 290d72e8c40472121d1212500bb1ebb40e29e7e0 Author: Anson Huang Date: Wed Apr 3 15:14:44 2019 -0700 Input: snvs_pwrkey - initialize necessary driver data before enabling IRQ commit bf2a7ca39fd3ab47ef71c621a7ee69d1813b1f97 upstream. SNVS IRQ is requested before necessary driver data initialized, if there is a pending IRQ during driver probe phase, kernel NULL pointer panic will occur in IRQ handler. To avoid such scenario, just initialize necessary driver data before enabling IRQ. This patch is inspired by NXP’s internal kernel tree. Fixes: d3dc6e232215 (“input: keyboard: imx: add snvs power key driver”) Signed-off-by: Anson Huang Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a3d147d5826007736ddec61a685ed9f6bac49b59 Author: Yuval Avnery Date: Tue Jan 22 09:02:05 2019 +0200 IB/core: Destroy QP if XRC QP fails commit 535005ca8e5e71918d64074032f4b9d4fef8981e upstream. The open-coded variant missed destroy of SELinux created QP, reuse already existing ib_detroy_qp() call and use this opportunity to clean ib_create_qp() from double prints and unclear exit paths. Reported-by: Parav Pandit Fixes: d291f1a65232 (“IB/core: Enforce PKey security on QPs”) Signed-off-by: Yuval Avnery Reviewed-by: Parav Pandit Reviewed-by: Daniel Jurgens Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit ae691c80904e4ea04c1b8e64d9f1e6cddc123209 Author: Daniel Jurgens Date: Sat Feb 2 11:09:43 2019 +0200 IB/core: Fix potential memory leak while creating MAD agents commit 6e88e672b69f0e627acdae74a527b730ea224b6b upstream. If the MAD agents isn’t allowed to manage the subnet, or fails to register for the LSM notifier, the security context is leaked. Free the context in these cases. Fixes: 47a2b338fe63 (“IB/core: Enforce security on management datagrams”) Signed-off-by: Daniel Jurgens Reviewed-by: Parav Pandit Reported-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 4cbfe6e7366c0270ac7a979bea3fe514d8e9dfcc Author: Daniel Jurgens Date: Sat Feb 2 11:09:42 2019 +0200 IB/core: Unregister notifier before freeing MAD security commit d60667fc398ed34b3c7456b020481c55c760e503 upstream. If the notifier runs after the security context is freed an access of freed memory can occur. Fixes: 47a2b338fe63 (“IB/core: Enforce security on management datagrams”) Signed-off-by: Daniel Jurgens Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 2f86122bd369e11ebdc4136a56bda0f5484e9b0d Author: Rajneesh Bhardwaj Date: Fri Feb 1 13:02:25 2019 +0530 platform/x86: intel_pmc_core: Handle CFL regmap properly commit e50af8332785355de3cb40d9f5e8c45dbfc86f53 upstream. Only Coffeelake should use Cannonlake regmap other than Cannonlake platform. This allows Coffeelake special handling only when there is no matching PCI device and default reg map selected as per CPUID is for Sunrisepoint PCH. This change is needed to enable support for newer SoCs such as Icelake. Cc: “David E. Box” Cc: Srinivas Pandruvada Fixes: 661405bd817b (“platform/x86: intel_pmc_core: Special case for Coffeelake”) Acked-by: “David E. Box” Signed-off-by: Rajneesh Bhardwaj Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 7a7b0c0ee92fa305b445102e9457884c04d02e31 Author: Rajneesh Bhardwaj Date: Fri Feb 1 13:02:27 2019 +0530 platform/x86: intel_pmc_core: Fix PCH IP name commit d6827015e671cd17871c9b7a0fabe06c044f7470 upstream. For Cannonlake and Icelake, the IP name for Res_6 should be SPF i.e. South Port F. No functional change is intended other than just renaming the IP appropriately. Cc: “David E. Box” Cc: Srinivas Pandruvada Fixes: 291101f6a735 (“platform/x86: intel_pmc_core: Add CannonLake PCH support”) Signed-off-by: Rajneesh Bhardwaj Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 8f2b774cbf81603a8146fb2e2d92dc88001fafec Author: Sean Christopherson Date: Thu Apr 25 19:01:09 2019 -0700 KVM: lapic: Check for in-kernel LAPIC before deferencing apic pointer commit b904cb8dff824b79233e82c078837627ebd52717 upstream. …to avoid dereferencing a null pointer when querying the per-vCPU timer advance. Fixes: 39497d7660d98 (“KVM: lapic: Track lapic timer advance per vCPU”) Reported-by: [email protected] Signed-off-by: Sean Christopherson Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 99678e9cf282353b9b2938c7271e551b34a76ac9 Author: Yu Zhang Date: Thu Jan 31 11:26:39 2019 +0800 kvm: vmx: Fix typos in vmentry/vmexit control setting commit d92935979adba274b1099e67b7f713f6d8413121 upstream. Previously, ‘commit f99e3daf94ff (“KVM: x86: Add Intel PT virtualization work mode”)' work mode’ offered framework to support Intel PT virtualization. However, the patch has some typos in vmx_vmentry_ctrl() and vmx_vmexit_ctrl(), e.g. used wrong flags and wrong variable, which will cause the VM entry failure later. Fixes: ‘commit f99e3daf94ff (“KVM: x86: Add Intel PT virtualization work mode”)' Signed-off-by: Yu Zhang Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 774e8693399af434ab81a816bce047cb4b710e93 Author: Sean Christopherson Date: Fri Jan 25 07:40:55 2019 -0800 KVM: nVMX: Remove a rogue “rax” clobber from nested_vmx_check_vmentry_hw() commit 9ce0a07a6f49822238fd4357c02e0dba060a43cc upstream. RAX is not touched by nested_vmx_check_vmentry_hw(), directly or indirectly (e.g. vmx_vmenter()). Remove it from the clobber list. Fixes: 52017608da33 (“KVM: nVMX: add option to perform early consistency checks via H/W”) Reviewed-by: Jim Mattson Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit af0aafff4715050f7a3fbdd12708d47bd573ae64 Author: Sean Christopherson Date: Fri Jan 25 07:40:52 2019 -0800 KVM: VMX: Save RSI to an unused output in the vCPU-run asm blob commit f3689e3f17f064fd4cd5f0cb01ae2395c94f39d9 upstream. RSI is clobbered by the vCPU-run asm blob, but it’s not marked as such, probably because GCC doesn’t let you mark inputs as clobbered. “Save” RSI to a dummy output so that GCC recognizes it as being clobbered. Fixes: 773e8a0425c9 (“x86/kvm: use Enlightened VMCS when running on Hyper-V”) Reviewed-by: Jim Mattson Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 6b4045b37b3275d29e6e3e32569dfb590599e73d Author: Arnaud Pouliquen Date: Fri Apr 5 11:19:11 2019 +0200 ASoC: stm32: fix sai driver name initialisation commit 17d3069ccf06970e2db3f7cbf4335f207524279e upstream. This patch fixes the sai driver structure overwriting which results in a cpu dai name equal NULL. Fixes: 3e086ed (“ASoC: stm32: add SAI driver”) Signed-off-by: Arnaud Pouliquen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 258604e0a15f25f764901e68a5a22b645666f4d8 Author: Jerome Brunet Date: Mon Apr 1 15:03:54 2019 +0200 ASoC: dpcm: skip missing substream while applying symmetry commit 6246f283d5e02ac757bd8d9bacde8fdc54c4582d upstream. If for any reason, the backend does not have the requested substream (like capture on a playback only backend), the BE will be skipped in dpcm_be_dai_startup(). However, dpcm_apply_symmetry() does not skip those BE and will dereference the be_substream (NULL) pointer anyway. Like in dpcm_be_dai_startup(), just skip those BE. Fixes: 906c7d690c3b (“ASoC: dpcm: Apply symmetry for DPCM”) Signed-off-by: Jerome Brunet Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 934955968fa611706f3f2f06cdbda856b2813420 Author: Charles Keepax Date: Tue Mar 19 11:52:04 2019 +0000 ASoC: wm_adsp: Correct handling of compressed streams that restart commit 639e5eb3c7d67e407f2a71fccd95323751398f6f upstream. Previously support was added to allow streams to be stopped and started again without the DSP being power cycled and this was done by clearing the buffer state in trigger start. Another supported use-case is using the DSP for a trigger event then opening the compressed stream later to receive the audio, unfortunately clearing the buffer state in trigger start destroys the data received from such a trigger. Correct this issue by moving the call to wm_adsp_buffer_clear to be in trigger stop instead. Fixes: 61fc060c40e6 (“ASoC: wm_adsp: Support streams which can start/stop with DSP active”) Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2ed9e9e89a3734364c432db9a8e3e5b823f32791 Author: Chen-Yu Tsai Date: Wed Feb 13 15:04:56 2019 +0800 ASoC: sunxi: sun50i-codec-analog: Rename hpvcc regulator supply to cpvdd commit 5fd812e6f5ae0376134234ceb70e8de541ccb10d upstream. The A64 datasheet lists the supply rail for the headphone amp’s charge pump as "CPVDD". cpvdd-supply is the name of the property for this power rail specified in the device tree bindings. “HPVCC” was the name used in the A33 datasheet for the same function. Rename the supply so it matches the datasheet, bindings, and the subject from the original commit. Fixes: ca0412a05756 (“ASoC: sunxi: sun50i-codec-analog: Add support for cpvdd regulator supply”) Signed-off-by: Chen-Yu Tsai Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e8a7a853180d04b5e4390d77db67a72bdebe8742 Author: Jiada Wang Date: Mon Feb 25 12:14:20 2019 +0100 ASoC: rsnd: gen: fix SSI9 4/5/6/7 busif related register address commit 8af6c521cc236534093f9e744cfa004314bfe5ae upstream. Currently each SSI unit ‘s busif mode/adinr/dalign address is registered by: (in busif4 case) RSND_GEN_M_REG(SSI_BUSIF4_MODE, 0x500, 0x80) RSND_GEN_M_REG(SSI_BUSIF4_ADINR,0x504, 0x80) RSND_GEN_M_REG(SSI_BUSIF4_DALIGN, 0x508, 0x80) But according to user manual 41.1.4 Register Configuration ssi9 4/5/6/7 busif mode/adinr/dalign register address ( SSI9-[4/5/6/7]_BUSIF_[MODE/ADINR/DALIGN] ) are out of this rule. This patch registers ssi9 4/5/6/7 mode/adinr/dalign register as single register, and access these registers in case of SSI9 BUSIF 4/5/6/7. Fixes: commit 8c9d75033340 (“ASoC: rsnd: ssiu: Support BUSIF other than BUSIF0”) Signed-off-by: Jiada Wang Signed-off-by: Timo Wischer Acked-by: Kuninori Morimoto Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit bd567d69186fa0eadfce72fe062a74aac9ec0a17 Author: Hans de Goede Date: Sun Dec 30 00:00:22 2018 +0100 ASoC: Intel: bytcr_rt5651: Revert “Fix DMIC map headsetmic mapping” commit aee48a9ffa5a128bf4e433c57c39e015ea5b0208 upstream. Commit 37c7401e8c1f (“ASoC: Intel: bytcr_rt5651: Fix DMIC map headsetmic mapping”), changed the headsetmic mapping from IN3P to IN2P, this was based on the observation that all bytcr_rt5651 devices I have access to (7 devices) where all using IN3P for the headsetmic. This was an attempt to unifify / simplify the mapping, but it was wrong. None of those devices was actually using a digital internal mic. Now I’ve access to a Point of View TAB-P1006W-232 (v1.0) tabler, which does use a DMIC and it does have its headsetmic connected to IN2P, showing that the original mapping was correct, so this commit reverts the change changing the mapping back to IN2P. Fixes: 37c7401e8c1f (“ASoC: Intel: bytcr_rt5651: Fix DMIC map … mapping”) Acked-by: Pierre-Louis Bossart Signed-off-by: Hans de Goede Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2647c26b20fe9dde62ea27bd2eb9cdaef85cc3b7 Author: Bart Van Assche Date: Fri Jan 25 10:34:51 2019 -0800 scsi: RDMA/srpt: Fix a credit leak for aborted commands commit 40ca8757291ca7a8775498112d320205b2a2e571 upstream. Make sure that the next time a response is sent to the initiator that the credit it had allocated for the aborted request gets freed. Cc: Doug Ledford Cc: Jason Gunthorpe Cc: Nicholas Bellinger Cc: Mike Christie Cc: Hannes Reinecke Cc: Christoph Hellwig Fixes: 131e6abc674e (“target: Add TFO->abort_task for aborted task resources release”) # v3.15 Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 0d700633ead433e91707cb654b0e0c1f0951ba1e Author: John Garry Date: Fri Jan 25 22:22:38 2019 +0800 scsi: hisi_sas: Fix to only call scsi_get_prot_op() for non-NULL scsi_cmnd commit e1ba0b0b44512c5a209526c09ea3eb7d256b6951 upstream. A NULL-pointer dereference was introduced for TMF SSP commands from the upstreaming reworking. Fix this by relocating the scsi_get_prot_op() callsite. Fixes: d6a9000b81be (“scsi: hisi_sas: Add support for DIF feature for v2 hw”) Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 15e4df25a6b7d8b3f396d7dbc1885343affa2539 Author: Jeremy Fertic Date: Sat Dec 22 21:57:43 2018 -0700 staging: iio: adt7316: fix the dac write calculation commit 78accaea117c1ae878774974fab91ac4a0b0e2b0 upstream. The lsb calculation is not masking the correct bits from the user input. Subtract 1 from (1 << offset) to correctly set up the mask to be applied to user input. The lsb register stores its value starting at the bit 7 position. adt7316_store_DAC() currently assumes the value is at the other end of the register. Shift the lsb value before storing it in a new variable lsb_reg, and write this variable to the lsb register. Fixes: 35f6b6b86ede (“staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver”) Signed-off-by: Jeremy Fertic Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 85dbcda147f41cbf9be95864dae0daa25f66473c Author: Jeremy Fertic Date: Sat Dec 22 21:57:41 2018 -0700 staging: iio: adt7316: fix handling of dac high resolution option commit 76b7fe8d6c4daf4db672eb953c892c6f6572a282 upstream. The adt7316/7 and adt7516/7 have the option to output voltage proportional to temperature on dac a and/or dac b. The default dac resolution in this mode is 8 bits with the dac high resolution option enabling 10 bits. None of these settings affect dacs c and d. Remove the "1 (12 bits)" output from the show function since that is not an option for this mode. Return "1 (10 bits)" if the device is one of the above mentioned chips and the dac high resolution mode is enabled. In the store function, the driver currently allows the user to write to the ADT7316_DA_HIGH_RESOLUTION bit regardless of the device in use. Add a check to return an error in the case of an adt7318 or adt7519. Remove the else statement that clears the ADT7316_DA_HIGH_RESOLUTION bit. Instead, clear it before conditionally enabling it, depending on user input. This matches the typical pattern in the driver when an attribute is a boolean. Fixes: 35f6b6b86ede (“staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver”) Signed-off-by: Jeremy Fertic Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5502a9c8e28880924da43f6d36522742614358f6 Author: Jeremy Fertic Date: Sat Dec 22 21:57:42 2018 -0700 staging: iio: adt7316: fix the dac read calculation commit 45130fb030aec26ac28b4bb23344901df3ec3b7f upstream. The calculation of the current dac value is using the wrong bits of the dac lsb register. Create two macros to shift the lsb register value into lsb position, depending on whether the dac is 10 or 12 bit. Initialize data to 0 so, with an 8 bit dac, the msb register value can be bitwise ORed with data. Fixes: 35f6b6b86ede (“staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver”) Signed-off-by: Jeremy Fertic Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9f929fd72c8d622e2ae8e0cde1b98228a38b65b7 Author: Jeremy Fertic Date: Tue Dec 11 17:55:00 2018 -0700 staging: iio: adt7316: allow adt751x to use internal vref for all dacs commit 10bfe7cc1739c22f0aa296b39e53f61e9e3f4d99 upstream. With adt7516/7/9, internal vref is available for dacs a and b, dacs c and d, or all dacs. The driver doesn’t currently support internal vref for all dacs. Change the else if to an if so both bits are checked rather than just one or the other. Signed-off-by: Jeremy Fertic Fixes: 35f6b6b86ede (“staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver”) Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 08b450e6826c27e4c6cc7cf158ff9f930182711c Author: Thinh Nguyen Date: Tue Feb 12 19:39:27 2019 -0800 usb: dwc3: Reset num_trbs after skipping commit c7152763f02e05567da27462b2277a554e507c89 upstream. Currently req->num_trbs is not reset after the TRBs are skipped and processed from the cancelled list. The gadget driver may reuse the request with an invalid req->num_trbs, and DWC3 will incorrectly skip trbs. To fix this, simply reset req->num_trbs to 0 after skipping through all of them. Fixes: c3acd5901414 ("usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue()") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit ad93be454503e385e757d16e61b1a0f161419094 Author: Jeffrey Hugo Date: Fri Jan 4 09:49:46 2019 -0700 clk: qcom: Add missing freq for usb30_master_clk on 8998 commit 0c8ff62504e3a667387e87889a259632c3199a86 upstream. The usb30_master_clk supports a 60Mhz frequency, but that is missing from the table of supported frequencies. Add it. Fixes: b5f5f525c547 (clk: qcom: Add MSM8998 Global Clock Control (GCC) driver) Signed-off-by: Jeffrey Hugo Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit c319d45742d25ecf34bf1fb2c51f304b08b03b2d Author: Sean Wang Date: Fri Feb 15 07:19:35 2019 +0800 Bluetooth: mediatek: fix up an error path to restore bdev->tx_state commit 77f328dbc6cf42f22c691a164958a5452142a542 upstream. Restore bdev->tx_state with clearing bit BTMTKUART_TX_WAIT_VND_EVT when there is an error on waiting for the corresponding event. Fixes: 7237c4c9ec92 (“Bluetooth: mediatek: Add protocol support for MediaTek serial devices”) Signed-off-by: Sean Wang Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 4b96517d7335c2bbed60432713e6d575f3d221f1 Author: Brian Norris Date: Tue Apr 9 11:49:17 2019 -0700 Bluetooth: btusb: request wake pin with NOAUTOEN commit 771acc7e4a6e5dba779cb1a7fd851a164bc81033 upstream. Badly-designed systems might have (for example) active-high wake pins that default to high (e.g., because of external pull ups) until they have an active firmware which starts driving it low. This can cause an interrupt storm in the time between request_irq() and disable_irq(). We don’t support shared interrupts here, so let’s just pre-configure the interrupt to avoid auto-enabling it. Fixes: fd913ef7ce61 (“Bluetooth: btusb: Add out-of-band wakeup support”) Fixes: 5364a0b4f4be (“arm64: dts: rockchip: move QCA6174A wakeup pin into its USB node”) Signed-off-by: Brian Norris Reviewed-by: Matthias Kaehlcke Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 542fb915e79e6072ef2e252cf2d901ef8d432775 Author: Kim Phillips Date: Thu May 2 15:29:47 2019 +0000 perf/x86/amd: Update generic hardware cache events for Family 17h commit 0e3b74e26280f2cf8753717a950b97d424da6046 upstream. Add a new amd_hw_cache_event_ids_f17h assignment structure set for AMD families 17h and above, since a lot has changed. Specifically: L1 Data Cache The data cache access counter remains the same on Family 17h. For DC misses, PMCx041’s definition changes with Family 17h, so instead we use the L2 cache accesses from L1 data cache misses counter (PMCx060,umask=0xc8). For DC hardware prefetch events, Family 17h breaks compatibility for PMCx067 "Data Prefetcher", so instead, we use PMCx05a “Hardware Prefetch DC Fills.” L1 Instruction Cache PMCs 0x80 and 0x81 (32-byte IC fetches and misses) are backward compatible on Family 17h. For prefetches, we remove the erroneous PMCx04B assignment which counts how many software data cache prefetch load instructions were dispatched. LL - Last Level Cache Removing PMCs 7D, 7E, and 7F assignments, as they do not exist on Family 17h, where the last level cache is L3. L3 counters can be accessed using the existing AMD Uncore driver. Data TLB On Intel machines, data TLB accesses (“dTLB-loads”) are assigned to counters that count load/store instructions retired. This is inconsistent with instruction TLB accesses, where Intel implementations report iTLB misses that hit in the STLB. Ideally, dTLB-loads would count higher level dTLB misses that hit in lower level TLBs, and dTLB-load-misses would report those that also missed in those lower-level TLBs, therefore causing a page table walk. That would be consistent with instruction TLB operation, remove the redundancy between dTLB-loads and L1-dcache-loads, and prevent perf from producing artificially low percentage ratios, i.e. the “0.01%” below: 42,550,869 L1-dcache-loads 41,591,860 dTLB-loads 4,802 dTLB-load-misses # 0.01% of all dTLB cache hits 7,283,682 L1-dcache-stores 7,912,392 dTLB-stores 310 dTLB-store-misses On AMD Families prior to 17h, the “Data Cache Accesses” counter is used, which is slightly better than load/store instructions retired, but still counts in terms of individual load/store operations instead of TLB operations. So, for AMD Families 17h and higher, this patch assigns “dTLB-loads” to a counter for L1 dTLB misses that hit in the L2 dTLB, and “dTLB-load-misses” to a counter for L1 DTLB misses that caused L2 DTLB misses and therefore also caused page table walks. This results in a much more accurate view of data TLB performance: 60,961,781 L1-dcache-loads 4,601 dTLB-loads 963 dTLB-load-misses # 20.93% of all dTLB cache hits Note that for all AMD families, data loads and stores are combined in a single accesses counter, so no ‘L1-dcache-stores’ are reported separately, and stores are counted with loads in ‘L1-dcache-loads’. Also note that the “% of all dTLB cache hits” string is misleading because (a) "dTLB cache": although TLBs can be considered caches for page tables, in this context, it can be misinterpreted as data cache hits because the figures are similar (at least on Intel), and (b) not all those loads (technically accesses) technically “hit” at that hardware level. “% of all dTLB accesses” would be more clear/accurate. Instruction TLB On Intel machines, ‘iTLB-loads’ measure iTLB misses that hit in the STLB, and ‘iTLB-load-misses’ measure iTLB misses that also missed in the STLB and completed a page table walk. For AMD Family 17h and above, for ‘iTLB-loads’ we replace the erroneous instruction cache fetches counter with PMCx084 "L1 ITLB Miss, L2 ITLB Hit". For ‘iTLB-load-misses’ we still use PMCx085 "L1 ITLB Miss, L2 ITLB Miss", but set a 0xff umask because without it the event does not get counted. Branch Predictor (BPU) PMCs 0xc2 and 0xc3 continue to be valid across all AMD Families. Node Level Events Family 17h does not have a PMCx0e9 counter, and corresponding counters have not been made available publicly, so for now, we mark them as unsupported for Families 17h and above. Reference: “Open-Source Register Reference For AMD Family 17h Processors Models 00h-2Fh” Released 7/17/2018, Publication #56255, Revision 3.03: https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf [ mingo: tidied up the line breaks. ] Signed-off-by: Kim Phillips Cc: # v4.9+ Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Janakarajan Natarajan Cc: Jiri Olsa Cc: Linus Torvalds Cc: Martin Liška Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Pu Wen Cc: Stephane Eranian Cc: Suravee Suthikulpanit Cc: Thomas Gleixner Cc: Thomas Lendacky Cc: Vince Weaver Cc: [email protected] Cc: [email protected] Fixes: e40ed1542dd7 (“perf/x86: Add perf support for AMD family-17h processors”) Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 0b01d66f6d5724a40a41793f7b4d2fd963d06cee Author: Arnd Bergmann Date: Mon Mar 25 16:50:43 2019 +0100 ARM: iop: don’t use using 64-bit DMA masks [ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ] clang warns about statically defined DMA masks from the DMA_BIT_MASK macro with length 64: arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type [-Werror,-Wshift-count-overflow] static u64 iop13xx_adma_dmamask = DMA_BIT_MASK(64); ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:141:54: note: expanded from macro ‘DMA_BIT_MASK’ #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) ^ ~~~ The ones in iop shouldn’t really be 64 bit masks, so changing them to what the driver can support avoids the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin (Microsoft) commit f78b5205ea57db248fe39d224578c09cf75157e9 Author: Arnd Bergmann Date: Mon Mar 25 16:50:42 2019 +0100 ARM: orion: don’t use using 64-bit DMA masks [ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ] clang warns about statically defined DMA masks from the DMA_BIT_MASK macro with length 64: arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type [-Werror,-Wshift-count-overflow] .coherent_dma_mask = DMA_BIT_MASK(64), ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:141:54: note: expanded from macro ‘DMA_BIT_MASK’ #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) The ones in orion shouldn’t really be 64 bit masks, so changing them to what the driver can support avoids the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin (Microsoft) commit e42ae9c9b8640bc05a8ea1e223c7aae17eef3ef2 Author: Kirill Smelkov Date: Tue Mar 26 22:20:43 2019 +0000 fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock [ Upstream commit 10dce8af34226d90fa56746a934f8da5dcdba3df ] Commit 9c225f2655e3 (“vfs: atomic f_pos accesses as per POSIX”) added locking for file.f_pos access and in particular made concurrent read and write not possible - now both those functions take f_pos lock for the whole run, and so if e.g. a read is blocked waiting for data, write will deadlock waiting for that read to complete. This caused regression for stream-like files where previously read and write could run simultaneously, but after that patch could not do so anymore. See e.g. commit 581d21a2d02a (“xenbus: fix deadlock on writes to /proc/xen/xenbus”) which fixes such regression for particular case of /proc/xen/xenbus. The patch that added f_pos lock in 2014 did so to guarantee POSIX thread safety for read/write/lseek and added the locking to file descriptors of all regular files. In 2014 that thread-safety problem was not new as it was already discussed earlier in 2006. However even though 2006’th version of Linus’s patch was adding f_pos locking "only for files that are marked seekable with FMODE_LSEEK (thus avoiding the stream-like objects like pipes and sockets)", the 2014 version - the one that actually made it into the tree as 9c225f2655e3 - is doing so irregardless of whether a file is seekable or not. See https://lore.kernel.org/lkml/[email protected]/ https://lwn.net/Articles/180387 https://lwn.net/Articles/180396 for historic context. The reason that it did so is, probably, that there are many files that are marked non-seekable, but e.g. their read implementation actually depends on knowing current position to correctly handle the read. Some examples: kernel/power/user.c snapshot_read fs/debugfs/file.c u32_array_read fs/fuse/control.c fuse_conn_waiting_read + … drivers/hwmon/asus_atk0110.c atk_debugfs_ggrp_read arch/s390/hypfs/inode.c hypfs_read_iter … Despite that, many nonseekable_open users implement read and write with pure stream semantics - they don’t depend on passed ppos at all. And for those cases where read could wait for something inside, it creates a situation similar to xenbus - the write could be never made to go until read is done, and read is waiting for some, potentially external, event, for potentially unbounded time -> deadlock. Besides xenbus, there are 14 such places in the kernel that I’ve found with semantic patch (see below): drivers/xen/evtchn.c:667:8-24: ERROR: evtchn_fops: .read() can deadlock .write() drivers/isdn/capi/capi.c:963:8-24: ERROR: capi_fops: .read() can deadlock .write() drivers/input/evdev.c:527:1-17: ERROR: evdev_fops: .read() can deadlock .write() drivers/char/pcmcia/cm4000_cs.c:1685:7-23: ERROR: cm4000_fops: .read() can deadlock .write() net/rfkill/core.c:1146:8-24: ERROR: rfkill_fops: .read() can deadlock .write() drivers/s390/char/fs3270.c:488:1-17: ERROR: fs3270_fops: .read() can deadlock .write() drivers/usb/misc/ldusb.c:310:1-17: ERROR: ld_usb_fops: .read() can deadlock .write() drivers/hid/uhid.c:635:1-17: ERROR: uhid_fops: .read() can deadlock .write() net/batman-adv/icmp_socket.c:80:1-17: ERROR: batadv_fops: .read() can deadlock .write() drivers/media/rc/lirc_dev.c:198:1-17: ERROR: lirc_fops: .read() can deadlock .write() drivers/leds/uleds.c:77:1-17: ERROR: uleds_fops: .read() can deadlock .write() drivers/input/misc/uinput.c:400:1-17: ERROR: uinput_fops: .read() can deadlock .write() drivers/infiniband/core/user_mad.c:985:7-23: ERROR: umad_fops: .read() can deadlock .write() drivers/gnss/core.c:45:1-17: ERROR: gnss_fops: .read() can deadlock .write() In addition to the cases above another regression caused by f_pos locking is that now FUSE filesystems that implement open with FOPEN_NONSEEKABLE flag, can no longer implement bidirectional stream-like files - for the same reason as above e.g. read can deadlock write locking on file.f_pos in the kernel. FUSE’s FOPEN_NONSEEKABLE was added in 2008 in a7c1b990f715 (“fuse: implement nonseekable open”) to support OSSPD. OSSPD implements /dev/dsp in userspace with FOPEN_NONSEEKABLE flag, with corresponding read and write routines not depending on current position at all, and with both read and write being potentially blocking operations: See https://github.com/libfuse/osspd https://lwn.net/Articles/308445 https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1406 https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1438-L1477 https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1479-L1510 Corresponding libfuse example/test also describes FOPEN_NONSEEKABLE as “somewhat pipe-like files …” with read handler not using offset. However that test implements only read without write and cannot exercise the deadlock scenario: https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L124-L131 https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L146-L163 https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L209-L216 I’ve actually hit the read vs write deadlock for real while implementing my FUSE filesystem where there is /head/watch file, for which open creates separate bidirectional socket-like stream in between filesystem and its user with both read and write being later performed simultaneously. And there it is semantically not easy to split the stream into two separate read-only and write-only channels: https://lab.nexedi.com/kirr/wendelin.core/blob/f13aa600/wcfs/wcfs.go#L88-169 Let’s fix this regression. The plan is: 1. We can’t change nonseekable_open to include &~FMODE_ATOMIC_POS - doing so would break many in-kernel nonseekable_open users which actually use ppos in read/write handlers. 2. Add stream_open() to kernel to open stream-like non-seekable file descriptors. Read and write on such file descriptors would never use nor change ppos. And with that property on stream-like files read and write will be running without taking f_pos lock - i.e. read and write could be running simultaneously. 3. With semantic patch search and convert to stream_open all in-kernel nonseekable_open users for which read and write actually do not depend on ppos and where there is no other methods in file_operations which assume @offset access. 4. Add FOPEN_STREAM to fs/fuse/ and open in-kernel file-descriptors via steam_open if that bit is present in filesystem open reply. It was tempting to change fs/fuse/ open handler to use stream_open instead of nonseekable_open on just FOPEN_NONSEEKABLE flags, but grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE, and in particular GVFS which actually uses offset in its read and write handlers https://codesearch.debian.net/search?q=-%3Enonseekable+%3D https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1080 https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1247-1346 https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1399-1481 so if we would do such a change it will break a real user. 5. Add stream_open and FOPEN_STREAM handling to stable kernels starting from v3.14+ (the kernel where 9c225f2655 first appeared). This will allow to patch OSSPD and other FUSE filesystems that provide stream-like files to return FOPEN_STREAM | FOPEN_NONSEEKABLE in their open handler and this way avoid the deadlock on all kernel versions. This should work because fs/fuse/ ignores unknown open flags returned from a filesystem and so passing FOPEN_STREAM to a kernel that is not aware of this flag cannot hurt. In turn the kernel that is not aware of FOPEN_STREAM will be < v3.14 where just FOPEN_NONSEEKABLE is sufficient to implement streams without read vs write deadlock. This patch adds stream_open, converts /proc/xen/xenbus to it and adds semantic patch to automatically locate in-kernel places that are either required to be converted due to read vs write deadlock, or that are just safe to be converted because read and write do not use ppos and there are no other funky methods in file_operations. Regarding semantic patch I’ve verified each generated change manually - that it is correct to convert - and each other nonseekable_open instance left - that it is either not correct to convert there, or that it is not converted due to current stream_open.cocci limitations. The script also does not convert files that should be valid to convert, but that currently have .llseek = noop_llseek or generic_file_llseek for unknown reason despite file being opened with nonseekable_open (e.g. drivers/input/mousedev.c) Cc: Michael Kerrisk Cc: Yongzhi Pan Cc: Jonathan Corbet Cc: David Vrabel Cc: Juergen Gross Cc: Miklos Szeredi Cc: Tejun Heo Cc: Kirill Tkhai Cc: Arnd Bergmann Cc: Christoph Hellwig Cc: Greg Kroah-Hartman Cc: Julia Lawall Cc: Nikolaus Rath Cc: Han-Wen Nienhuys Signed-off-by: Kirill Smelkov Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin (Microsoft) commit 6f014ec022f93b64e1eb366c11706e6396e9e18a Author: Guenter Roeck Date: Tue Feb 19 08:49:56 2019 -0800 xsysace: Fix error handling in ace_setup [ Upstream commit 47b16820c490149c2923e8474048f2c6e7557cab ] If xace hardware reports a bad version number, the error handling code in ace_setup() calls put_disk(), followed by queue cleanup. However, since the disk data structure has the queue pointer set, put_disk() also cleans and releases the queue. This results in blk_cleanup_queue() accessing an already released data structure, which in turn may result in a crash such as the following. [ 10.681671] BUG: Kernel NULL pointer dereference at 0x00000040 [ 10.681826] Faulting instruction address: 0xc0431480 [ 10.682072] Oops: Kernel access of bad area, sig: 11 [#1] [ 10.682251] BE PAGE_SIZE=4K PREEMPT Xilinx Virtex440 [ 10.682387] Modules linked in: [ 10.682528] CPU: 0 PID: 1 Comm: swapper Tainted: G W 5.0.0-rc6-next-20190218+ #2 [ 10.682733] NIP: c0431480 LR: c043147c CTR: c0422ad8 [ 10.682863] REGS: cf82fbe0 TRAP: 0300 Tainted: G W (5.0.0-rc6-next-20190218+) [ 10.683065] MSR: 00029000 CR: 22000222 XER: 00000000 [ 10.683236] DEAR: 00000040 ESR: 00000000 [ 10.683236] GPR00: c043147c cf82fc90 cf82ccc0 00000000 00000000 00000000 00000002 00000000 [ 10.683236] GPR08: 00000000 00000000 c04310bc 00000000 22000222 00000000 c0002c54 00000000 [ 10.683236] GPR16: 00000000 00000001 c09aa39c c09021b0 c09021dc 00000007 c0a68c08 00000000 [ 10.683236] GPR24: 00000001 ced6d400 ced6dcf0 c0815d9c 00000000 00000000 00000000 cedf0800 [ 10.684331] NIP [c0431480] blk_mq_run_hw_queue+0x28/0x114 [ 10.684473] LR [c043147c] blk_mq_run_hw_queue+0x24/0x114 [ 10.684602] Call Trace: [ 10.684671] [cf82fc90] [c043147c] blk_mq_run_hw_queue+0x24/0x114 (unreliable) [ 10.684854] [cf82fcc0] [c04315bc] blk_mq_run_hw_queues+0x50/0x7c [ 10.685002] [cf82fce0] [c0422b24] blk_set_queue_dying+0x30/0x68 [ 10.685154] [cf82fcf0] [c0423ec0] blk_cleanup_queue+0x34/0x14c [ 10.685306] [cf82fd10] [c054d73c] ace_probe+0x3dc/0x508 [ 10.685445] [cf82fd50] [c052d740] platform_drv_probe+0x4c/0xb8 [ 10.685592] [cf82fd70] [c052abb0] really_probe+0x20c/0x32c [ 10.685728] [cf82fda0] [c052ae58] driver_probe_device+0x68/0x464 [ 10.685877] [cf82fdc0] [c052b500] device_driver_attach+0xb4/0xe4 [ 10.686024] [cf82fde0] [c052b5dc] __driver_attach+0xac/0xfc [ 10.686161] [cf82fe00] [c0528428] bus_for_each_dev+0x80/0xc0 [ 10.686314] [cf82fe30] [c0529b3c] bus_add_driver+0x144/0x234 [ 10.686457] [cf82fe50] [c052c46c] driver_register+0x88/0x15c [ 10.686610] [cf82fe60] [c09de288] ace_init+0x4c/0xac [ 10.686742] [cf82fe80] [c0002730] do_one_initcall+0xac/0x330 [ 10.686888] [cf82fee0] [c09aafd0] kernel_init_freeable+0x34c/0x478 [ 10.687043] [cf82ff30] [c0002c6c] kernel_init+0x18/0x114 [ 10.687188] [cf82ff40] [c000f2f0] ret_from_kernel_thread+0x14/0x1c [ 10.687349] Instruction dump: [ 10.687435] 3863ffd4 4bfffd70 9421ffd0 7c0802a6 93c10028 7c9e2378 93e1002c 38810008 [ 10.687637] 7c7f1b78 90010034 4bfffc25 813f008c <81290040> 75290100 4182002c 80810008 [ 10.688056] —[ end trace 13c9ff51d41b9d40 ]— Fix the problem by setting the disk queue pointer to NULL before calling put_disk(). A more comprehensive fix might be to rearrange the code to check the hardware version before initializing data structures, but I don’t know if this would have undesirable side effects, and it would increase the complexity of backporting the fix to older kernels. Fixes: 74489a91dd43a (“Add support for Xilinx SystemACE CompactFlash interface”) Acked-by: Michal Simek Signed-off-by: Guenter Roeck Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin (Microsoft) commit e91fcd8326c6c432aa428ad92b92b122469f92f5 Author: John Pittman Date: Fri Apr 5 17:42:45 2019 -0400 null_blk: prevent crash from bad home_node value [ Upstream commit 7ff684a683d777c4956fce93e60accbab2bd7696 ] At module load, if the selected home_node value is greater than the available numa nodes, the system will crash in __alloc_pages_nodemask() due to a bad paging request. Prevent this user error crash by detecting the bad value, logging an error, and setting g_home_node back to the default of NUMA_NO_NODE. Signed-off-by: John Pittman Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin (Microsoft) commit b174065805b55300d9d4e6ae6865c7b0838cc0f4 Author: Randy Dunlap Date: Fri Apr 5 18:39:30 2019 -0700 sh: fix multiple function definition build errors [ Upstream commit acaf892ecbf5be7710ae05a61fd43c668f68ad95 ] Many of the sh CPU-types have their own plat_irq_setup() and arch_init_clk_ops() functions, so these same (empty) functions in arch/sh/boards/of-generic.c are not needed and cause build errors. If there is some case where these empty functions are needed, they can be retained by marking them as “__weak” while at the same time making builds that do not need them succeed. Fixes these build errors: arch/sh/boards/of-generic.o: In function `plat_irq_setup’: (.init.text+0x134): multiple definition of `plat_irq_setup’ arch/sh/kernel/cpu/sh2/setup-sh7619.o:(.init.text+0x30): first defined here arch/sh/boards/of-generic.o: In function `arch_init_clk_ops’: (.init.text+0x118): multiple definition of `arch_init_clk_ops’ arch/sh/kernel/cpu/sh2/clock-sh7619.o:(.init.text+0x0): first defined here Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Randy Dunlap Reported-by: kbuild test robot Cc: Takashi Iwai Cc: Yoshinori Sato Cc: Rich Felker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin (Microsoft) commit 695ece893cb734885ab7e8689ec81905a1c8c7cf Author: Mike Kravetz Date: Fri Apr 5 18:39:06 2019 -0700 hugetlbfs: fix memory leak for resv_map [ Upstream commit 58b6e5e8f1addd44583d61b0a03c0f5519527e35 ] When mknod is used to create a block special file in hugetlbfs, it will allocate an inode and kmalloc a ‘struct resv_map’ via resv_map_alloc(). inode->i_mapping->private_data will point the newly allocated resv_map. However, when the device special file is opened bd_acquire() will set inode->i_mapping to bd_inode->i_mapping. Thus the pointer to the allocated resv_map is lost and the structure is leaked. Programs to reproduce: mount -t hugetlbfs nodev hugetlbfs mknod hugetlbfs/dev b 0 0 exec 30<> hugetlbfs/dev umount hugetlbfs/ resv_map structures are only needed for inodes which can have associated page allocations. To fix the leak, only allocate resv_map for those inodes which could possibly be associated with page allocations. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mike Kravetz Reviewed-by: Andrew Morton Reported-by: Yufen Yu Suggested-by: Yufen Yu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin (Microsoft) commit 37436fba416a9754e53e46236542414fbb5796dc Author: Catalin Marinas Date: Fri Apr 5 18:38:49 2019 -0700 kmemleak: powerpc: skip scanning holes in the .bss section [ Upstream commit 298a32b132087550d3fa80641ca58323c5dfd4d9 ] Commit 2d4f567103ff (“KVM: PPC: Introduce kvm_tmp framework”) adds kvm_tmp[] into the .bss section and then free the rest of unused spaces back to the page allocator. kernel_init kvm_guest_init kvm_free_tmp free_reserved_area free_unref_page free_unref_page_prepare With DEBUG_PAGEALLOC=y, it will unmap those pages from kernel. As the result, kmemleak scan will trigger a panic when it scans the .bss section with unmapped pages. This patch creates dedicated kmemleak objects for the .data, .bss and potentially .data…ro_after_init sections to allow partial freeing via the kmemleak_free_part() in the powerpc kvm_free_tmp() function. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas Reported-by: Qian Cai Acked-by: Michael Ellerman (powerpc) Tested-by: Qian Cai Cc: Paul Mackerras Cc: Benjamin Herrenschmidt Cc: Avi Kivity Cc: Paolo Bonzini Cc: Radim Krcmar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin (Microsoft) commit 271ea551cfdff55860f8628611d6538dec7dc307 Author: David Rientjes Date: Mon Mar 25 11:47:31 2019 -0700 KVM: SVM: prevent DBG_DECRYPT and DBG_ENCRYPT overflow [ Upstream commit b86bc2858b389255cd44555ce4b1e427b2b770c0 ] This ensures that the address and length provided to DBG_DECRYPT and DBG_ENCRYPT do not cause an overflow. At the same time, pass the actual number of pages pinned in memory to sev_unpin_memory() as a cleanup. Reported-by: Cfir Cohen Signed-off-by: David Rientjes Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin (Microsoft) commit 93e9dabbcdc7b8cd5f6c8e5451963fc1a1771e70 Author: Varun Prakash Date: Wed Apr 3 17:30:14 2019 +0530 libcxgb: fix incorrect ppmax calculation [ Upstream commit cc5a726c79158bd307150e8d4176ec79b52001ea ] BITS_TO_LONGS() uses DIV_ROUND_UP() because of this ppmax value can be greater than available per cpu page pods. This patch removes BITS_TO_LONGS() to fix this issue. Signed-off-by: Varun Prakash Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 3e67174547a3dbb3076cd5665d967b65434a4c6f Author: Yonglong Liu Date: Thu Apr 4 16:46:46 2019 +0800 net: hns: Fix WARNING when remove HNS driver with SMMU enabled [ Upstream commit 8601a99d7c0256b7a7fdd1ab14cf6c1f1dfcadc6 ] When enable SMMU, remove HNS driver will cause a WARNING: [ 141.924177] WARNING: CPU: 36 PID: 2708 at drivers/iommu/dma-iommu.c:443 __iommu_dma_unmap+0xc0/0xc8 [ 141.954673] Modules linked in: hns_enet_drv(-) [ 141.963615] CPU: 36 PID: 2708 Comm: rmmod Tainted: G W 5.0.0-rc1-28723-gb729c57de95c-dirty #32 [ 141.983593] Hardware name: Huawei D05/D05, BIOS Hisilicon D05 UEFI Nemo 1.8 RC0 08/31/2017 [ 142.000244] pstate: 60000005 (nZCv daif -PAN -UAO) [ 142.009886] pc : __iommu_dma_unmap+0xc0/0xc8 [ 142.018476] lr : __iommu_dma_unmap+0xc0/0xc8 [ 142.027066] sp : ffff000013533b90 [ 142.033728] x29: ffff000013533b90 x28: ffff8013e6983600 [ 142.044420] x27: 0000000000000000 x26: 0000000000000000 [ 142.055113] x25: 0000000056000000 x24: 0000000000000015 [ 142.065806] x23: 0000000000000028 x22: ffff8013e66eee68 [ 142.076499] x21: ffff8013db919800 x20: 0000ffffefbff000 [ 142.087192] x19: 0000000000001000 x18: 0000000000000007 [ 142.097885] x17: 000000000000000e x16: 0000000000000001 [ 142.108578] x15: 0000000000000019 x14: 363139343a70616d [ 142.119270] x13: 6e75656761705f67 x12: 0000000000000000 [ 142.129963] x11: 00000000ffffffff x10: 0000000000000006 [ 142.140656] x9 : 1346c1aa88093500 x8 : ffff0000114de4e0 [ 142.151349] x7 : 6662666578303d72 x6 : ffff0000105ffec8 [ 142.162042] x5 : 0000000000000000 x4 : 0000000000000000 [ 142.172734] x3 : 00000000ffffffff x2 : ffff0000114de500 [ 142.183427] x1 : 0000000000000000 x0 : 0000000000000035 [ 142.194120] Call trace: [ 142.199030] __iommu_dma_unmap+0xc0/0xc8 [ 142.206920] iommu_dma_unmap_page+0x20/0x28 [ 142.215335] __iommu_unmap_page+0x40/0x60 [ 142.223399] hnae_unmap_buffer+0x110/0x134 [ 142.231639] hnae_free_desc+0x6c/0x10c [ 142.239177] hnae_fini_ring+0x14/0x34 [ 142.246540] hnae_fini_queue+0x2c/0x40 [ 142.254080] hnae_put_handle+0x38/0xcc [ 142.261619] hns_nic_dev_remove+0x54/0xfc [hns_enet_drv] [ 142.272312] platform_drv_remove+0x24/0x64 [ 142.280552] device_release_driver_internal+0x17c/0x20c [ 142.291070] driver_detach+0x4c/0x90 [ 142.298259] bus_remove_driver+0x5c/0xd8 [ 142.306148] driver_unregister+0x2c/0x54 [ 142.314037] platform_driver_unregister+0x10/0x18 [ 142.323505] hns_nic_dev_driver_exit+0x14/0xf0c [hns_enet_drv] [ 142.335248] __arm64_sys_delete_module+0x214/0x25c [ 142.344891] el0_svc_common+0xb0/0x10c [ 142.352430] el0_svc_handler+0x24/0x80 [ 142.359968] el0_svc+0x8/0x7c0 [ 142.366104] —[ end trace 60ad1cd58e63c407 ]— The tx ring buffer map when xmit and unmap when xmit done. So in hnae_init_ring() did not map tx ring buffer, but in hnae_fini_ring() have a unmap operation for tx ring buffer, which is already unmapped when xmit done, than cause this WARNING. The hnae_alloc_buffers() is called in hnae_init_ring(), so the hnae_free_buffers() should be in hnae_fini_ring(), not in hnae_free_desc(). In hnae_fini_ring(), adds a check is_rx_ring() as in hnae_init_ring(). When the ring buffer is tx ring, adds a piece of code to ensure that the tx ring is unmap. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit c43ddd7a21323064d4afeec8336f94fe2a4d685e Author: Yonglong Liu Date: Thu Apr 4 16:46:45 2019 +0800 net: hns: fix ICMP6 neighbor solicitation messages discard problem [ Upstream commit f058e46855dcbc28edb2ed4736f38a71fd19cadb ] ICMP6 neighbor solicitation messages will be discard by the Hip06 chips, because of not setting forwarding pool. Enable promisc mode has the same problem. This patch fix the wrong forwarding table configs for the multicast vague matching when enable promisc mode, and add forwarding pool for the forwarding table. Signed-off-by: Yonglong Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 759e8256d0013ad451f7201ed3cd01ba6efa70ea Author: Yonglong Liu Date: Thu Apr 4 16:46:44 2019 +0800 net: hns: Fix probabilistic memory overwrite when HNS driver initialized [ Upstream commit c0b0984426814f3a9251873b689e67d34d8ccd84 ] When reboot the system again and again, may cause a memory overwrite. [ 15.638922] systemd[1]: Reached target Swap. [ 15.667561] tun: Universal TUN/TAP device driver, 1.6 [ 15.676756] Bridge firewalling registered [ 17.344135] Unable to handle kernel paging request at virtual address 0000000200000040 [ 17.352179] Mem abort info: [ 17.355007] ESR = 0x96000004 [ 17.358105] Exception class = DABT (current EL), IL = 32 bits [ 17.364112] SET = 0, FnV = 0 [ 17.367209] EA = 0, S1PTW = 0 [ 17.370393] Data abort info: [ 17.373315] ISV = 0, ISS = 0x00000004 [ 17.377206] CM = 0, WnR = 0 [ 17.380214] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____) [ 17.386926] [0000000200000040] pgd=0000000000000000 [ 17.391878] Internal error: Oops: 96000004 [#1] SMP [ 17.396824] CPU: 23 PID: 95 Comm: kworker/u130:0 Tainted: G E 4.19.25-1.2.78.aarch64 #1 [ 17.414175] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.54 08/16/2018 [ 17.425615] Workqueue: events_unbound async_run_entry_fn [ 17.435151] pstate: 00000005 (nzcv daif -PAN -UAO) [ 17.444139] pc : __mutex_lock.isra.1+0x74/0x540 [ 17.453002] lr : __mutex_lock.isra.1+0x3c/0x540 [ 17.461701] sp : ffff000100d9bb60 [ 17.469146] x29: ffff000100d9bb60 x28: 0000000000000000 [ 17.478547] x27: 0000000000000000 x26: ffff802fb8945000 [ 17.488063] x25: 0000000000000000 x24: ffff802fa32081a8 [ 17.497381] x23: 0000000000000002 x22: ffff801fa2b15220 [ 17.506701] x21: ffff000009809000 x20: ffff802fa23a0888 [ 17.515980] x19: ffff801fa2b15220 x18: 0000000000000000 [ 17.525272] x17: 0000000200000000 x16: 0000000200000000 [ 17.534511] x15: 0000000000000000 x14: 0000000000000000 [ 17.543652] x13: ffff000008d95db8 x12: 000000000000000d [ 17.552780] x11: ffff000008d95d90 x10: 0000000000000b00 [ 17.561819] x9 : ffff000100d9bb90 x8 : ffff802fb89d6560 [ 17.570829] x7 : 0000000000000004 x6 : 00000004a1801d05 [ 17.579839] x5 : 0000000000000000 x4 : 0000000000000000 [ 17.588852] x3 : ffff802fb89d5a00 x2 : 0000000000000000 [ 17.597734] x1 : 0000000200000000 x0 : 0000000200000000 [ 17.606631] Process kworker/u130:0 (pid: 95, stack limit = 0x(____ptrval____)) [ 17.617438] Call trace: [ 17.623349] __mutex_lock.isra.1+0x74/0x540 [ 17.630927] __mutex_lock_slowpath+0x24/0x30 [ 17.638602] mutex_lock+0x50/0x60 [ 17.645295] drain_workqueue+0x34/0x198 [ 17.652623] __sas_drain_work+0x7c/0x168 [ 17.659903] sas_drain_work+0x60/0x68 [ 17.666947] hisi_sas_scan_finished+0x30/0x40 [hisi_sas_main] [ 17.676129] do_scsi_scan_host+0x70/0xb0 [ 17.683534] do_scan_async+0x20/0x228 [ 17.690586] async_run_entry_fn+0x4c/0x1d0 [ 17.697997] process_one_work+0x1b4/0x3f8 [ 17.705296] worker_thread+0x54/0x470 Every time the call trace is not the same, but the overwrite address is always the same: Unable to handle kernel paging request at virtual address 0000000200000040 The root cause is, when write the reg XGMAC_MAC_TX_LF_RF_CONTROL_REG, didn’t use the io_base offset. Signed-off-by: Yonglong Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 2cbe0575198107fa58d31aa2e9eb95874d1dc58b Author: Yonglong Liu Date: Thu Apr 4 16:46:43 2019 +0800 net: hns: Use NAPI_POLL_WEIGHT for hns driver [ Upstream commit acb1ce15a61154aa501891d67ebf79bc9ea26818 ] When the HNS driver loaded, always have an error print: “netif_napi_add() called with weight 256” This is because the kernel checks the NAPI polling weights requested by drivers and it prints an error message if a driver requests a weight bigger than 64. So use NAPI_POLL_WEIGHT to fix it. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit f59129993a5300dce02bea7c3dc77b2ee3fb101c Author: Liubin Shu Date: Thu Apr 4 16:46:42 2019 +0800 net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw() [ Upstream commit 3a39a12ad364a9acd1038ba8da67cd8430f30de4 ] This patch is trying to fix the issue due to: [27237.844750] BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x708/0xa18[hns_enet_drv] After hnae_queue_xmit() in hns_nic_net_xmit_hw(), can be interrupted by interruptions, and than call hns_nic_tx_poll_one() to handle the new packets, and free the skb. So, when turn back to hns_nic_net_xmit_hw(), calling skb->len will cause use-after-free. This patch update tx ring statistics in hns_nic_tx_poll_one() to fix the bug. Signed-off-by: Liubin Shu Signed-off-by: Zhen Lei Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 26ac3d804822b757a6a4f73c0497bc9404f9a8e1 Author: Wei Li Date: Mon Apr 1 11:55:57 2019 +0800 arm64: fix wrong check of on_sdei_stack in nmi context [ Upstream commit 1c41860864c8ae0387ef7d44f0000e99cbb2e06d ] When doing unwind_frame() in the context of pseudo nmi (need enable CONFIG_ARM64_PSEUDO_NMI), reaching the bottom of the stack (fp == 0, pc != 0), function on_sdei_stack() will return true while the sdei acpi table is not inited in fact. This will cause a “NULL pointer dereference” oops when going on. Reviewed-by: Julien Thierry Signed-off-by: Wei Li Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin (Microsoft) commit 2c52a30e2158ef98a6ade3673e7236d2cde6e429 Author: Dongli Zhang Date: Thu Apr 4 10:57:44 2019 +0800 blk-mq: do not reset plug->rq_count before the list is sorted [ Upstream commit bcc816dfe51ab86ca94663c7b225f2d6eb0fddb9 ] We would never be able to sort the list if we first reset plug->rq_count which is used in conditional check later. Fixes: ce5b009cff19 (“block: improve logic around when to sort a plug list”) Reviewed-by: Ming Lei Signed-off-by: Dongli Zhang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin (Microsoft) commit 9bc06b41fd0d7e942ae501762266934b4743d09d Author: Peng Hao Date: Tue Apr 2 22:12:38 2019 +0800 arm/mach-at91/pm : fix possible object reference leak [ Upstream commit ba5e60c9b75dec92d4c695b928f69300b17d7686 ] of_find_device_by_node() takes a reference to the struct device when it finds a match via get_device. When returning error we should call put_device. Reviewed-by: Mukesh Ojha Signed-off-by: Peng Hao Signed-off-by: Ludovic Desroches Signed-off-by: Sasha Levin (Microsoft) commit 24d73473cc92e687f200a5590bc3afa8f3452848 Author: Michael Kelley Date: Mon Apr 1 16:10:52 2019 +0000 scsi: storvsc: Fix calculation of sub-channel count [ Upstream commit 382e06d11e075a40b4094b6ef809f8d4bcc7ab2a ] When the number of sub-channels offered by Hyper-V is >= the number of CPUs in the VM, calculate the correct number of sub-channels. The current code produces one too many. This scenario arises only when the number of CPUs is artificially restricted (for example, with maxcpus= on the kernel boot line), because Hyper-V normally offers a sub-channel count < number of CPUs. While the current code doesn’t break, the extra sub-channel is unbalanced across the CPUs (for example, a total of 5 channels on a VM with 4 CPUs). Signed-off-by: Michael Kelley Reviewed-by: Vitaly Kuznetsov Reviewed-by: Long Li Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin (Microsoft) commit ebaa9d86f25b6941e7309c9d717576c267b6717d Author: Xose Vazquez Perez Date: Sat Mar 30 15:43:31 2019 +0100 scsi: core: add new RDAC LENOVO/DE_Series device [ Upstream commit 1cb1d2c64e812928fe0a40b8f7e74523d0283dbe ] Blacklist “Universal Xport” LUN. It’s used for in-band storage array management. Also add model to the rdac dh family. Cc: Martin Wilck Cc: Hannes Reinecke Cc: NetApp RDAC team Cc: Christophe Varoqui Cc: James E.J. Bottomley Cc: Martin K. Petersen Cc: SCSI ML Cc: DM ML Signed-off-by: Xose Vazquez Perez Reviewed-by: Martin Wilck Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin (Microsoft) commit 52dd2b2d7f0a7aca9dc6f5edffe7dff87bc69014 Author: Louis Taylor Date: Wed Apr 3 12:36:20 2019 -0600 vfio/pci: use correct format characters [ Upstream commit 426b046b748d1f47e096e05bdcc6fb4172791307 ] When compiling with -Wformat, clang emits the following warnings: drivers/vfio/pci/vfio_pci.c:1601:5: warning: format specifies type ‘unsigned short’ but the argument has type ‘unsigned int’ [-Wformat] vendor, device, subvendor, subdevice, ^~~~~~ drivers/vfio/pci/vfio_pci.c:1601:13: warning: format specifies type ‘unsigned short’ but the argument has type ‘unsigned int’ [-Wformat] vendor, device, subvendor, subdevice, ^~~~~~ drivers/vfio/pci/vfio_pci.c:1601:21: warning: format specifies type ‘unsigned short’ but the argument has type ‘unsigned int’ [-Wformat] vendor, device, subvendor, subdevice, ^~~~~~~~~ drivers/vfio/pci/vfio_pci.c:1601:32: warning: format specifies type ‘unsigned short’ but the argument has type ‘unsigned int’ [-Wformat] vendor, device, subvendor, subdevice, ^~~~~~~~~ drivers/vfio/pci/vfio_pci.c:1605:5: warning: format specifies type ‘unsigned short’ but the argument has type ‘unsigned int’ [-Wformat] vendor, device, subvendor, subdevice, ^~~~~~ drivers/vfio/pci/vfio_pci.c:1605:13: warning: format specifies type ‘unsigned short’ but the argument has type ‘unsigned int’ [-Wformat] vendor, device, subvendor, subdevice, ^~~~~~ drivers/vfio/pci/vfio_pci.c:1605:21: warning: format specifies type ‘unsigned short’ but the argument has type ‘unsigned int’ [-Wformat] vendor, device, subvendor, subdevice, ^~~~~~~~~ drivers/vfio/pci/vfio_pci.c:1605:32: warning: format specifies type ‘unsigned short’ but the argument has type ‘unsigned int’ [-Wformat] vendor, device, subvendor, subdevice, ^~~~~~~~~ The types of these arguments are unconditionally defined, so this patch updates the format character to the correct ones for unsigned ints. Link: https://github.com/ClangBuiltLinux/linux/issues/378 Signed-off-by: Louis Taylor Reviewed-by: Nick Desaulniers Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin (Microsoft) commit 8a5ce8d9825abe474bd46fe031a7b1f4fa669ecc Author: Dmitry Torokhov Date: Tue Apr 2 09:57:13 2019 -0700 HID: input: add mapping for Assistant key [ Upstream commit ce856634af8cda3490947df8ac1ef5843e6356af ] According to HUTRR89 usage 0x1cb from the consumer page was assigned to allow launching desktop-aware assistant application, so let’s add the mapping. Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin (Microsoft) commit 6651fd9bead916cc6e8dc084337d26779a125185 Author: Alexandre Belloni Date: Tue Apr 2 12:26:36 2019 +0200 rtc: da9063: set uie_unsupported when relevant [ Upstream commit 882c5e552ffd06856de42261460f46e18319d259 ] The DA9063AD doesn’t support alarms on any seconds and its granularity is the minute. Set uie_unsupported in that case. Reported-by: Wolfram Sang Reported-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Acked-by: Steve Twiss Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin (Microsoft) commit b514ad765acbcd8d2784fff67b9f218b7fa4a33a Author: Shenghui Wang Date: Mon Apr 1 21:40:36 2019 +0800 block: use blk_free_flush_queue() to free hctx->fq in blk_mq_init_hctx [ Upstream commit b9a1ff504b9492ad6beb7d5606e0e3365d4d8499 ] kfree() can leak the hctx->fq->flush_rq field. Reviewed-by: Ming Lei Signed-off-by: Shenghui Wang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin (Microsoft) commit 93a122ae03805e3884fa563cf621a779d342e199 Author: Andreas Kemnade Date: Sat Feb 23 12:47:54 2019 +0100 mfd: twl-core: Disable IRQ while suspended [ Upstream commit 20bb907f7dc82ecc9e135ad7067ac7eb69c81222 ] Since commit 6e2bd956936 (“i2c: omap: Use noirq system sleep pm ops to idle device for suspend”) on gta04 we have handle_twl4030_pih() called in situations where pm_runtime_get() in i2c-omap.c returns -EACCES. [ 86.474365] Freezing remaining freezable tasks … (elapsed 0.002 seconds) done. [ 86.485473] printk: Suspending console(s) (use no_console_suspend to debug) [ 86.555572] Disabling non-boot CPUs … [ 86.555664] Successfully put all powerdomains to target state [ 86.563720] twl: Read failed (mod 1, reg 0x01 count 1) [ 86.563751] twl4030: I2C error -13 reading PIH ISR [ 86.563812] twl: Read failed (mod 1, reg 0x01 count 1) [ 86.563812] twl4030: I2C error -13 reading PIH ISR [ 86.563873] twl: Read failed (mod 1, reg 0x01 count 1) [ 86.563903] twl4030: I2C error -13 reading PIH ISR This happens when we wakeup via something behing twl4030 (powerbutton or rtc alarm). This goes on for minutes until the system is finally resumed. Disable the irq on suspend and enable it on resume to avoid having i2c access problems when the irq registers are checked. Fixes: 6e2bd956936 (“i2c: omap: Use noirq system sleep pm ops to idle device for suspend”) Signed-off-by: Andreas Kemnade Tested-by: Tony Lindgren Signed-off-by: Lee Jones Signed-off-by: Sasha Levin (Microsoft) commit 3ba95a36358796c210f0a902119a697d269ec442 Author: Al Viro Date: Tue Mar 26 01:43:37 2019 +0000 debugfs: fix use-after-free on symlink traversal [ Upstream commit 93b919da64c15b90953f96a536e5e61df896ca57 ] symlink body shouldn’t be freed without an RCU delay. Switch debugfs to ->destroy_inode() and use of call_rcu(); free both the inode and symlink body in the callback. Similar to solution for bpf, only here it’s even more obvious that ->evict_inode() can be dropped. Signed-off-by: Al Viro Signed-off-by: Sasha Levin (Microsoft) commit 66559d395933540c5ae7fd26aacec1ddbe579a29 Author: Al Viro Date: Tue Mar 26 01:39:50 2019 +0000 jffs2: fix use-after-free on symlink traversal [ Upstream commit 4fdcfab5b5537c21891e22e65996d4d0dd8ab4ca ] free the symlink body after the same RCU delay we have for freeing the struct inode itself, so that traversal during RCU pathwalk wouldn’t step into freed memory. Signed-off-by: Al Viro Signed-off-by: Sasha Levin (Microsoft) commit 02f3f9794f214555ed624252b92e36f3f892ab45 Author: Aaro Koskinen Date: Wed Mar 27 22:35:40 2019 +0200 net: stmmac: don’t log oversized frames [ Upstream commit 057a0c5642a2ff2db7c421cdcde34294a23bf37b ] This is log is harmful as it can trigger multiple times per packet. Delete it. Signed-off-by: Aaro Koskinen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit f3b6acbaff395b2d3ad5704da18552081f0d356b Author: Aaro Koskinen Date: Wed Mar 27 22:35:39 2019 +0200 net: stmmac: fix dropping of multi-descriptor RX frames [ Upstream commit 8ac0c24fe1c256af6644caf3d311029440ec2fbd ] Packets without the last descriptor set should be dropped early. If we receive a frame larger than the DMA buffer, the HW will continue using the next descriptor. Driver mistakes these as individual frames, and sometimes a truncated frame (without the LD set) may look like a valid packet. This fixes a strange issue where the system replies to 4098-byte ping although the MTU/DMA buffer size is set to 4096, and yet at the same time it’s logging an oversized packet. Signed-off-by: Aaro Koskinen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit e6b88961c8886b95e62e9f837882be6abbdc8fe1 Author: Aaro Koskinen Date: Wed Mar 27 22:35:38 2019 +0200 net: stmmac: don’t overwrite discard_frame status [ Upstream commit 1b746ce8b397e58f9e40ce5c63b7198de6930482 ] If we have error bits set, the discard_frame status will get overwritten by checksum bit checks, which might set the status back to good one. Fix by checking the COE status only if the frame is good. Signed-off-by: Aaro Koskinen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit c937eeff033df551153e322520b638e9823a4d29 Author: Aaro Koskinen Date: Wed Mar 27 22:35:37 2019 +0200 net: stmmac: don’t stop NAPI processing when dropping a packet [ Upstream commit 07b3975352374c3f5ebb4a42ef0b253fe370542d ] Currently, if we drop a packet, we exit from NAPI loop before the budget is consumed. In some situations this will make the RX processing stall e.g. when flood pinging the system with oversized packets, as the errorneous packets are not dropped efficiently. If we drop a packet, we should just continue to the next one as long as the budget allows. Signed-off-by: Aaro Koskinen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 9268b0a54bb91fb6ce22ba39cf4843ac68961de1 Author: Aaro Koskinen Date: Wed Mar 27 22:35:36 2019 +0200 net: stmmac: ratelimit RX error logs [ Upstream commit 972c9be784e077bc56472c78243e0326e525b689 ] Ratelimit RX error logs. Signed-off-by: Aaro Koskinen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 0fa0ac6c6b6219181d35da55898039447a91e5f6 Author: Aaro Koskinen Date: Wed Mar 27 22:35:35 2019 +0200 net: stmmac: use correct DMA buffer size in the RX descriptor [ Upstream commit 583e6361414903c5206258a30e5bd88cb03c0254 ] We always program the maximum DMA buffer size into the receive descriptor, although the allocated size may be less. E.g. with the default MTU size we allocate only 1536 bytes. If somebody sends us a bigger frame, then memory may get corrupted. Fix by using exact buffer sizes. Signed-off-by: Aaro Koskinen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 79e55cf86cec524d147e67fecf9e29c23512bd87 Author: Konstantin Khorenko Date: Thu Mar 28 13:29:21 2019 +0300 bonding: show full hw address in sysfs for slave entries [ Upstream commit 18bebc6dd3281955240062655a4df35eef2c46b3 ] Bond expects ethernet hwaddr for its slave, but it can be longer than 6 bytes - infiniband interface for example. # cat /sys/devices//net/ib0/address 80:00:02:08:fe:80:00:00:00:00:00:00:7c:fe:90:03:00:be:5d:e1 # cat /sys/devices//net/ib0/bonding_slave/perm_hwaddr 80:00:02:08:fe:80 So print full hwaddr in sysfs “bonding_slave/perm_hwaddr” as well. Signed-off-by: Konstantin Khorenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit 2340d1c4ede82c10cff60145d1c6c9b8add40ea6 Author: Omri Kahalon Date: Sun Feb 24 16:31:08 2019 +0200 net/mlx5: E-Switch, Fix esw manager vport indication for more vport commands [ Upstream commit eca4a928585ac08147e5cc8e2111ecbc6279ee31 ] Traditionally, the PF (Physical Function) which resides on vport 0 was the E-switch manager. Since the ECPF (Embedded CPU Physical Function), which resides on vport 0xfffe, was introduced as the E-Switch manager, the assumption that the E-switch manager is on vport 0 is incorrect. Since the eswitch code already uses the actual vport value, all we need is to always set other_vport=1. Signed-off-by: Omri Kahalon Reviewed-by: Max Gurtovoy Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin (Microsoft) commit 21b557cb27e2eadfb84b837f465556252c5376c4 Author: Roi Dayan Date: Thu Mar 21 15:51:35 2019 -0700 net/mlx5: E-Switch, Protect from invalid memory access in offload fdb table [ Upstream commit 5c1d260ed10cf08dd7a0299c103ad0a3f9a9f7a1 ] The esw offloads structures share a union with the legacy mode structs. Reset the offloads struct to zero in init to protect from null assumptions made by the legacy mode code. Signed-off-by: Roi Dayan Reviewed-by: Or Gerlitz Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin (Microsoft) commit 5c0323b32e538cd96451c405f0735be9cc42915e Author: Jesper Dangaard Brouer Date: Fri Mar 29 10:18:00 2019 +0100 xdp: fix cpumap redirect SKB creation bug [ Upstream commit 676e4a6fe703f2dae699ee9d56f14516f9ada4ea ] We want to avoid leaking pointer info from xdp_frame (that is placed in top of frame) like commit 6dfb970d3dbd (“xdp: avoid leaking info stored in frame data on page reuse”), and followup commit 97e19cce05e5 (“bpf: reserve xdp_frame size in xdp headroom”) that reserve this headroom. These changes also affected how cpumap constructed SKBs, as xdpf->headroom size changed, the skb data starting point were in-effect shifted with 32 bytes (sizeof xdp_frame). This was still okay, as the cpumap frame_size calculation also included xdpf->headroom which were reduced by same amount. A bug was introduced in commit 77ea5f4cbe20 (“bpf/cpumap: make sure frame_size for build_skb is aligned if headroom isn’t”), where the xdpf->headroom became part of the SKB_DATA_ALIGN rounding up. This round-up to find the frame_size is in principle still correct as it does not exceed the 2048 bytes frame_size (which is max for ixgbe and i40e), but the 32 bytes offset of pkt_data_start puts this over the 2048 bytes limit. This cause skb_shared_info to spill into next frame. It is a little hard to trigger, as the SKB need to use above 15 skb_shinfo->frags[] as far as I calculate. This does happen in practise for TCP streams when skb_try_coalesce() kicks in. KASAN can be used to detect these wrong memory accesses, I’ve seen: BUG: KASAN: use-after-free in skb_try_coalesce+0x3cb/0x760 BUG: KASAN: wild-memory-access in skb_release_data+0xe2/0x250 Driver veth also construct a SKB from xdp_frame in this way, but is not affected, as it doesn’t reserve/deduct the room (used by xdp_frame) from the SKB headroom. Instead is clears the pointers via xdp_scrub_frame(), and allows SKB to use this area. The fix in this patch is to do like veth and instead allow SKB to (re)use the area occupied by xdp_frame, by clearing via xdp_scrub_frame(). (This does kill the idea of the SKB being able to access (mem) info from this area, but I guess it was a bad idea anyhow, and it was already killed by the veth changes.) Fixes: 77ea5f4cbe20 (“bpf/cpumap: make sure frame_size for build_skb is aligned if headroom isn’t”) Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin (Microsoft) commit eab19d67ad688e58aa50400e69c523c3882eda9f Author: Xi Wang Date: Tue Mar 26 14:53:49 2019 +0800 net: hns3: fix compile error [ Upstream commit 669efc76b317b3aa550ffbf0b79d064cb00a5f96 ] Currently, the rules for configuring search paths in Kbuild have changed, this will lead some erros when compiling hns3 with the following command: make O=DIR M=drivers/net/ethernet/hisilicon/hns3 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c:11:10: fatal error: hnae3.h: No such file or directory This patch fix it by adding $(srctree)/ prefix to the serach paths. Signed-off-by: Xi Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) commit fcaef6ae7fa389747aa9a84a349ef24cbe06176c Author: Jeffrey Hugo Date: Tue Mar 26 09:55:54 2019 -0700 HID: quirks: Fix keyboard + touchpad on Lenovo Miix 630 [ Upstream commit 2bafa1e9625400bec4c840a168d70ba52607a58d ] Similar to commit edfc3722cfef (“HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working”), the Lenovo Miix 630 has a combo keyboard/touchpad device with vid:pid of 04F3:0400, which is shared with Elan touchpads. The combo on the Miix 630 has an ACPI id of QTEC0001, which is not claimed by the elan_i2c driver, so key on that similar to what was done for the Toshiba Click Mini. Signed-off-by: Jeffrey Hugo Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin (Microsoft) commit 603ae6024626ae227fcac0ec75b9a2f907827765 Author: Alan Kao Date: Fri Mar 22 14:37:04 2019 +0800 riscv: fix accessing 8-byte variable from RV32 [ Upstream commit dbee9c9c45846f003ec2f819710c2f4835630a6a ] A memory save operation to 8-byte variable in RV32 is divided into two sw instructions in the put_user macro. The current fixup returns execution flow to the second sw instead of the one after it. This patch fixes this fixup code according to the load access part. Signed-off-by: Alan Kao Cc: Greentime Hu Cc: Vincent Chen Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin (Microsoft) commit 56e41e46e860b672bd35022b28e2e6fb5977888b Author: Stefan Assmann Date: Thu Mar 21 13:45:35 2019 +0100 i40e: fix WoL support check [ Upstream commit f669d24f3dd00beab452c0fc9257f6a942ffca9b ] The current check for WoL on i40e is broken. Code comment says only magic packet is supported, so only check for that. Fixes: 540a152da762 (i40e/ixgbe/igb: fail on new WoL flag setting WAKE_MAGICSECURE) Signed-off-by: Stefan Assmann Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin (Microsoft) commit ee5088ba4b2366cd78cd8155be0452f1f71be465 Author: Ivan Vecera Date: Fri Mar 15 09:45:15 2019 +0100 ixgbe: fix mdio bus registration [ Upstream commit 7ec52b9df7d7472240fa96223185894b1897aeb0 ] The ixgbe ignores errors returned from mdiobus_register() and leaves adapter->mii_bus non-NULL and MDIO bus state as MDIOBUS_ALLOCATED. This triggers a BUG from mdiobus_unregister() during ixgbe_remove() call. Fixes: 8fa10ef01260 (“ixgbe: register a mdiobus”) Signed-off-by: Ivan Vecera Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin (Microsoft) commit 29cdcf7c4d5942b65611e74ae3366de847d52c9e Author: Arvind Sankar Date: Sat Mar 2 11:01:17 2019 -0500 igb: Fix WARN_ONCE on runtime suspend [ Upstream commit dabb8338be533c18f50255cf39ff4f66d4dabdbe ] The runtime_suspend device callbacks are not supposed to save configuration state or change the power state. Commit fb29f76cc566 (“igb: Fix an issue that PME is not enabled during runtime suspend”) changed the driver to not save configuration state during runtime suspend, however the driver callback still put the device into a low-power state. This causes a warning in the pci pm core and results in pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend. Fix this by not changing the power state either, leaving that to pci pm core, and make the same change for suspend callback as well. Also move a couple of defines into the appropriate header file instead of inline in the .c file. Fixes: fb29f76cc566 (“igb: Fix an issue that PME is not enabled during runtime suspend”) Signed-off-by: Arvind Sankar Reviewed-by: Kai-Heng Feng Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin (Microsoft) commit b95b96893c86e1f478875fe65b076753a69e1ddc Author: Jacob Keller Date: Mon Feb 25 11:20:05 2019 -0800 i40e: fix i40e_ptp_adjtime when given a negative delta [ Upstream commit b3ccbbce1e455b8454d3935eb9ae0a5f18939e24 ] Commit 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26) claims to be cleaning up references to 32-bit timespecs. The actual contents of the commit make no sense, as it converts a call to timespec64_add into timespec64_add_ns. This would seem ok, if (a) the change was documented in the commit message, and (b) timespec64_add_ns supported negative numbers. timespec64_add_ns doesn’t work with signed deltas, because the implementation is based around iter_div_u64_rem. This change resulted in a regression where i40e_ptp_adjtime would interpret small negative adjustments as large positive additions, resulting in incorrect behavior. This commit doesn’t appear to fix anything, is not well explained, and introduces a bug, so lets just revert it. Reverts: 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26) Signed-off-by: Jacob Keller Reviewed-by: Arnd Bergmann Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin (Microsoft) commit f600213a3930fef4b0af33d1bc2f116138ce305b Author: Tony Lindgren Date: Tue Mar 26 10:32:23 2019 -0700 ARM: dts: Fix dcan clkctrl clock for am3 [ Upstream commit 7d56bedb2730dc2ea8abf0fd7240ee99ecfee3c9 ] We must not use legacy clock defines for dts clckctrl clocks as the offsets will be wrong. Fixes: 87fc89ced3a7 (“ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc”) Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin (Microsoft) commit 4b6d04ef0102cde5681c436d3bde84ed1a220017 Author: Axel Lin Date: Mon Mar 18 22:03:52 2019 +0800 reset: meson-audio-arb: Fix missing .owner setting of reset_controller_dev [ Upstream commit 13e8a05b922457761ddef39cfff6231bd4ed9eef ] Set .owner to prevent module unloading while being used. Signed-off-by: Axel Lin Fixes: d903779b58be (“reset: meson: add meson audio arb driver”) Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin (Microsoft) commit 18d841b848c2856553c04693b6dc7656affec971 Author: Douglas Anderson Date: Wed Mar 20 13:14:00 2019 -0700 ARM: dts: rockchip: Fix gpu opp node names for rk3288 [ Upstream commit d040e4e8deeaa8257d6aa260e29ad69832b5d630 ] The device tree compiler yells like this: Warning (unit_address_vs_reg): /gpu-opp-table/opp@100000000: node has a unit name, but no reg property Let’s match the cpu opp node names and use a dash. Signed-off-by: Douglas Anderson Reviewed-by: Matthias Kaehlcke Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin (Microsoft) commit 10db6b5653f16e3c833f3127c9792a09cd7829c7 Author: Anders Roxell Date: Fri Feb 22 16:25:54 2019 +0100 batman-adv: fix warning in function batadv_v_elp_get_throughput [ Upstream commit ca8c3b922e7032aff6cc3fd05548f4df1f3df90e ] When CONFIG_CFG80211 isn’t enabled the compiler correcly warns about ‘sinfo.pertid’ may be unused. It can also happen for other error conditions that it not warn about. net/batman-adv/bat_v_elp.c: In function ‘batadv_v_elp_get_throughput.isra.0’: include/net/cfg80211.h:6370:13: warning: ‘sinfo.pertid’ may be used uninitialized in this function [-Wmaybe-uninitialized] kfree(sinfo->pertid); ~~~~~^~~~~~~~ Rework so that we only release ‘&sinfo’ if cfg80211_get_station returns zero. Fixes: 7d652669b61d (“batman-adv: release station info tidstats”) Signed-off-by: Anders Roxell Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin (Microsoft) commit 2ea41a71b191ce59a99aa6ddc108b063911aaaf4 Author: Sven Eckelmann Date: Sat Feb 23 14:27:10 2019 +0100 batman-adv: Reduce tt_global hash refcnt only for removed entry [ Upstream commit f131a56880d10932931e74773fb8702894a94a75 ] The batadv_hash_remove is a function which searches the hashtable for an entry using a needle, a hashtable bucket selection function and a compare function. It will lock the bucket list and delete an entry when the compare function matches it with the needle. It returns the pointer to the hlist_node which matches or NULL when no entry matches the needle. The batadv_tt_global_free is not itself protected in anyway to avoid that any other function is modifying the hashtable between the search for the entry and the call to batadv_hash_remove. It can therefore happen that the entry either doesn’t exist anymore or an entry was deleted which is not the same object as the needle. In such an situation, the reference counter (for the reference stored in the hashtable) must not be reduced for the needle. Instead the reference counter of the actually removed entry has to be reduced. Otherwise the reference counter will underflow and the object might be freed before all its references were dropped. The kref helpers reported this problem as: refcount_t: underflow; use-after-free. Fixes: 7683fdc1e886 (“batman-adv: protect the local and the global trans-tables with rcu”) Reported-by: Martin Weinelt Signed-off-by: Sven Eckelmann Acked-by: Antonio Quartulli Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin (Microsoft) commit 0536ffa505bc63a5d18ec5e324177c284297b057 Author: Sven Eckelmann Date: Sat Feb 23 14:27:10 2019 +0100 batman-adv: Reduce tt_local hash refcnt only for removed entry [ Upstream commit 3d65b9accab4a7ed5038f6df403fbd5e298398c7 ] The batadv_hash_remove is a function which searches the hashtable for an entry using a needle, a hashtable bucket selection function and a compare function. It will lock the bucket list and delete an entry when the compare function matches it with the needle. It returns the pointer to the hlist_node which matches or NULL when no entry matches the needle. The batadv_tt_local_remove is not itself protected in anyway to avoid that any other function is modifying the hashtable between the search for the entry and the call to batadv_hash_remove. It can therefore happen that the entry either doesn’t exist anymore or an entry was deleted which is not the same object as the needle. In such an situation, the reference counter (for the reference stored in the hashtable) must not be reduced for the needle. Instead the reference counter of the actually removed entry has to be reduced. Otherwise the reference counter will underflow and the object might be freed before all its references were dropped. The kref helpers reported this problem as: refcount_t: underflow; use-after-free. Fixes: ef72706a0543 (“batman-adv: protect tt_local_entry from concurrent delete events”) Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin (Microsoft) commit 810cfcc0f2a47ca0ab1ec8970177b33fef2a1a70 Author: Sven Eckelmann Date: Sat Feb 23 14:27:10 2019 +0100 batman-adv: Reduce claim hash refcnt only for removed entry [ Upstream commit 4ba104f468bbfc27362c393815d03aa18fb7a20f ] The batadv_hash_remove is a function which searches the hashtable for an entry using a needle, a hashtable bucket selection function and a compare function. It will lock the bucket list and delete an entry when the compare function matches it with the needle. It returns the pointer to the hlist_node which matches or NULL when no entry matches the needle. The batadv_bla_del_claim is not itself protected in anyway to avoid that any other function is modifying the hashtable between the search for the entry and the call to batadv_hash_remove. It can therefore happen that the entry either doesn’t exist anymore or an entry was deleted which is not the same object as the needle. In such an situation, the reference counter (for the reference stored in the hashtable) must not be reduced for the needle. Instead the reference counter of the actually removed entry has to be reduced. Otherwise the reference counter will underflow and the object might be freed before all its references were dropped. The kref helpers reported this problem as: refcount_t: underflow; use-after-free. Fixes: 23721387c409 (“batman-adv: add basic bridge loop avoidance code”) Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin (Microsoft) commit 13d47cf66df77b0a48aff523d132cb13a28f28ca Author: Julia Lawall Date: Sat Feb 23 14:20:42 2019 +0100 ARM: OMAP2+: add missing of_node_put after of_device_is_available [ Upstream commit 30645307e5d2c8a4caf978558c66121ac91ad17e ] Add an of_node_put when a tested device node is not available. The semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // @@ identifier f; local idexpression e; expression x; @@ e = f(…); … when != of_node_put(e) when != x = e when != e = x when any if (<+…of_device_is_available(e)…+>) { … when != of_node_put(e) ( return e; | + of_node_put(e); return …; ) } // Fixes: e0c827aca0730 (“drm/omap: Populate DSS children in omapdss driver”) Signed-off-by: Julia Lawall Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin (Microsoft) commit c832bbc4fff052593dbfc6e8c4304d10b481d502 Author: Geert Uytterhoeven Date: Wed Mar 20 11:32:14 2019 +0100 rtc: sh: Fix invalid alarm warning for non-enabled alarm [ Upstream commit 15d82d22498784966df8e4696174a16b02cc1052 ] When no alarm has been programmed on RSK-RZA1, an error message is printed during boot: rtc rtc0: invalid alarm value: 2019-03-14T255:255:255 sh_rtc_read_alarm_value() returns 0xff when querying a hardware alarm field that is not enabled. __rtc_read_alarm() validates the received alarm values, and fills in missing fields when needed. While 0xff is handled fine for the year, month, and day fields, and corrected as considered being out-of-range, this is not the case for the hour, minute, and second fields, where -1 is expected for missing fields. Fix this by returning -1 instead, as this value is handled fine for all fields. Signed-off-by: Geert Uytterhoeven Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin (Microsoft) commit 9be94b95acb66b5f5fb8123664e2d8a033484242 Author: Stephen Boyd Date: Fri Mar 15 11:51:12 2019 -0700 rtc: cros-ec: Fail suspend/resume if wake IRQ can’t be configured [ Upstream commit d6752e185c3168771787a02dc6a55f32260943cc ] If we encounter a failure during suspend where this RTC was programmed to wakeup the system from suspend, but that wakeup couldn’t be configured because the system didn’t support wakeup interrupts, we’ll run into the following warning: Unbalanced IRQ 166 wake disable WARNING: CPU: 7 PID: 3071 at kernel/irq/manage.c:669 irq_set_irq_wake+0x108/0x278 This happens because the suspend process isn’t aborted when the RTC fails to configure the wakeup IRQ. Instead, we continue suspending the system and then another suspend callback fails the suspend process and “unwinds” the previously suspended drivers by calling their resume callbacks. When we get back to resuming this RTC driver, we’ll call disable_irq_wake() on an IRQ that hasn’t been configured for wake. Let’s just fail suspend/resume here if we can’t configure the system to wake and the user has chosen to wakeup with this device. This fixes this warning and makes the code more robust in case there are systems out there that can’t wakeup from suspend on this line but the user has chosen to do so. Cc: Enric Balletbo i Serra Cc: Evan Green Cc: Benson Leung Cc: Guenter Roeck Signed-off-by: Stephen Boyd Acked-By: Benson Leung Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin (Microsoft) commit 458c92229d70524f9854cdce0f43c3774a542254 Author: He, Bo Date: Thu Mar 14 02:28:21 2019 +0000 HID: debug: fix race condition with between rdesc_show() and device removal [ Upstream commit cef0d4948cb0a02db37ebfdc320e127c77ab1637 ] There is a race condition that could happen if hid_debug_rdesc_show() is running while hdev is in the process of going away (device removal, system suspend, etc) which could result in NULL pointer dereference: BUG: unable to handle kernel paging request at 0000000783316040 CPU: 1 PID: 1512 Comm: getevent Tainted: G U O 4.19.20-quilt-2e5dc0ac-00029-gc455a447dd55 #1 RIP: 0010:hid_dump_device+0x9b/0x160 Call Trace: hid_debug_rdesc_show+0x72/0x1d0 seq_read+0xe0/0x410 full_proxy_read+0x5f/0x90 __vfs_read+0x3a/0x170 vfs_read+0xa0/0x150 ksys_read+0x58/0xc0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x55/0x110 entry_SYSCALL_64_after_hwframe+0x49/0xbe Grab driver_input_lock to make sure the input device exists throughout the whole process of dumping the rdesc. [[email protected]: update changelog a bit] Signed-off-by: he, bo Signed-off-by: “Zhang, Jun” Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin (Microsoft) commit d6cba891f1f891d39c6dbfd12eef83b1a17e5101 Author: Kangjie Lu Date: Thu Mar 14 00:24:02 2019 -0500 HID: logitech: check the return value of create_singlethread_workqueue [ Upstream commit 6c44b15e1c9076d925d5236ddadf1318b0a25ce2 ] create_singlethread_workqueue may fail and return NULL. The fix checks if it is NULL to avoid NULL pointer dereference. Also, the fix moves the call of create_singlethread_workqueue earlier to avoid resource-release issues. Signed-off-by: Kangjie Lu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin (Microsoft) commit 8c284dd4a8522160b95a4500cb871637a7ed169f Author: Kai-Heng Feng Date: Fri Mar 8 13:11:17 2019 +0800 HID: Increase maximum report size allowed by hid_field_extract() [ Upstream commit 94a9992f7dbdfb28976b565af220e0c4a117144a ] Commit 71f6fa90a353 (“HID: increase maximum global item tag report size to 256”) increases the max report size from 128 to 256. We also need to update the report size in hid_field_extract() otherwise it complains and truncates now valid report size: [ 406.165461] hid-sensor-hub 001F:8086:22D8.0002: hid_field_extract() called with n (192) > 32! (kworker/5:1) BugLink: https://bugs.launchpad.net/bugs/1818547 Fixes: 71f6fa90a353 (“HID: increase maximum global item tag report size to 256”) Signed-off-by: Kai-Heng Feng Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin (Microsoft) commit 4c01ab81fa27e84502737785716931be76007541 Author: Leonidas P. Papadakos Date: Fri Mar 1 00:29:23 2019 +0200 arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay [ Upstream commit 924726888f660b2a86382a5dd051ec9ca1b18190 ] The rk3328-roc-cc board exhibits tx stability issues with large packets, as does the rock64 board, which was fixed with this patch https://patchwork.kernel.org/patch/10178969/ A similar patch was merged for the rk3328-roc-cc here https://patchwork.kernel.org/patch/10804863/ but it doesn’t include the tx/rx_delay tweaks, and I find that they help with an issue where large transfers would bring the ethernet link down, causing a link reset regularly. Signed-off-by: Leonidas P. Papadakos Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin (Microsoft) commit b2e3c7d43f71989189fe34d72f7158fb0ad3fb89 Author: Sean Christopherson Date: Wed Apr 17 10:15:34 2019 -0700 KVM: lapic: Convert guest TSC to host time domain if necessary commit b6aa57c69cb26ea0160c51f7cf45f1af23542686 upstream. To minimize the latency of timer interrupts as observed by the guest, KVM adjusts the values it programs into the host timers to account for the host’s overhead of programming and handling the timer event. In the event that the adjustments are too aggressive, i.e. the timer fires earlier than the guest expects, KVM busy waits immediately prior to entering the guest. Currently, KVM manually converts the delay from nanoseconds to clock cycles. But, the conversion is done in the guest’s time domain, while the delay occurs in the host’s time domain. This is perfectly ok when the guest and host are using the same TSC ratio, but if the guest is using a different ratio then the delay may not be accurate and could wait too little or too long. When the guest is not using the host’s ratio, convert the delay from guest clock cycles to host nanoseconds and use ndelay() instead of __delay() to provide more accurate timing. Because converting to nanoseconds is relatively expensive, e.g. requires division and more multiplication ops, continue using __delay() directly when guest and host TSCs are running at the same ratio. Cc: Liran Alon Cc: Wanpeng Li Cc: [email protected] Fixes: 3b8a5df6c4dc6 (“KVM: LAPIC: Tune lapic_timer_advance_ns automatically”) Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 63be90093cf54523dd158ca555319c413fc151b7 Author: Sean Christopherson Date: Wed Apr 17 10:15:33 2019 -0700 KVM: lapic: Allow user to disable adaptive tuning of timer advancement commit c3941d9e0ccd48920e4811f133235b3597e5310b upstream. The introduction of adaptive tuning of lapic timer advancement did not allow for the scenario where userspace would want to disable adaptive tuning but still employ timer advancement, e.g. for testing purposes or to handle a use case where adaptive tuning is unable to settle on a suitable time. This is epecially pertinent now that KVM places a hard threshold on the maximum advancment time. Rework the timer semantics to accept signed values, with a value of '-1’ being interpreted as "use adaptive tuning with KVM’s internal default", and any other value being used as an explicit advancement time, e.g. a time of ‘0’ effectively disables advancement. Note, this does not completely restore the original behavior of lapic_timer_advance_ns. Prior to tracking the advancement per vCPU, which is necessary to support autotuning, userspace could adjust lapic_timer_advance_ns for *running* vCPU. With per-vCPU tracking, the module params are snapshotted at vCPU creation, i.e. applying a new advancement effectively requires restarting a VM. Dynamically updating a running vCPU is possible, e.g. a helper could be added to retrieve the desired delay, choosing between the global module param and the per-VCPU value depending on whether or not auto-tuning is (globally) enabled, but introduces a great deal of complexity. The wrapper itself is not complex, but understanding and documenting the effects of dynamically toggling auto-tuning and/or adjusting the timer advancement is nigh impossible since the behavior would be dependent on KVM’s implementation as well as compiler optimizations. In other words, providing stable behavior would require extremely careful consideration now and in the future. Given that the expected use of a manually-tuned timer advancement is to "tune once, run many", use the vastly simpler approach of recognizing changes to the module params only when creating a new vCPU. Cc: Liran Alon Cc: Wanpeng Li Reviewed-by: Liran Alon Cc: [email protected] Fixes: 3b8a5df6c4dc6 (“KVM: LAPIC: Tune lapic_timer_advance_ns automatically”) Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a3ca780612e5ec67cb716c47d31404b5f313afb9 Author: Sean Christopherson Date: Wed Apr 17 10:15:32 2019 -0700 KVM: lapic: Track lapic timer advance per vCPU commit 39497d7660d9866a47a2dc9055672358da57ad3d upstream. Automatically adjusting the globally-shared timer advancement could corrupt the timer, e.g. if multiple vCPUs are concurrently adjusting the advancement value. That could be partially fixed by using a local variable for the arithmetic, but it would still be susceptible to a race when setting timer_advance_adjust_done. And because virtual_tsc_khz and tsc_scaling_ratio are per-vCPU, the correct calibration for a given vCPU may not apply to all vCPUs. Furthermore, lapic_timer_advance_ns is marked __read_mostly, which is effectively violated when finding a stable advancement takes an extended amount of timer. Opportunistically change the definition of lapic_timer_advance_ns to a u32 so that it matches the style of struct kvm_timer. Explicitly pass the param to kvm_create_lapic() so that it doesn’t have to be exposed to lapic.c, thus reducing the probability of unintentionally using the global value instead of the per-vCPU value. Cc: Liran Alon Cc: Wanpeng Li Reviewed-by: Liran Alon Cc: [email protected] Fixes: 3b8a5df6c4dc6 (“KVM: LAPIC: Tune lapic_timer_advance_ns automatically”) Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a72f524964fb0310156804ba121249f1eebd8c13 Author: Liran Alon Date: Tue Apr 16 20:36:34 2019 +0300 KVM: x86: Consider LAPIC TSC-Deadline timer expired if deadline too short commit c09d65d9eab69985c75f98ed64541229f6fa9aa6 upstream. If guest sets MSR_IA32_TSCDEADLINE to value such that in host time-domain it’s shorter than lapic_timer_advance_ns, we can reach a case that we call hrtimer_start() with expiration time set at the past. Because lapic_timer.timer is init with HRTIMER_MODE_ABS_PINNED, it is not allowed to run in softirq and therefore will never expire. To avoid such a scenario, verify that deadline expiration time is set on host time-domain further than (now + lapic_timer_advance_ns). A future patch can also consider adding a min_timer_deadline_ns module parameter, similar to min_timer_period_us to avoid races that amount of ns it takes to run logic could still call hrtimer_start() with expiration timer set at the past. Reviewed-by: Joao Martins Signed-off-by: Liran Alon Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 042b6d11e00fd3614760454744ce492825201c2d Author: Sean Christopherson Date: Wed Apr 17 10:15:31 2019 -0700 KVM: lapic: Disable timer advancement if adaptive tuning goes haywire commit 57bf67e73ce9bcce2258890f5abf2adf5f619f1a upstream. To minimize the latency of timer interrupts as observed by the guest, KVM adjusts the values it programs into the host timers to account for the host’s overhead of programming and handling the timer event. Now that the timer advancement is automatically tuned during runtime, it’s effectively unbounded by default, e.g. if KVM is running as L1 the advancement can measure in hundreds of milliseconds. Disable timer advancement if adaptive tuning yields an advancement of more than 5000ns, as large advancements can break reasonable assumptions of the guest, e.g. that a timer configured to fire after 1ms won’t arrive on the next instruction. Although KVM busy waits to mitigate the case of a timer event arriving too early, complications can arise when shifting the interrupt too far, e.g. kvm-unit-test’s vmx.interrupt test will fail when its “host” exits on interrupts as KVM may inject the INTR before the guest executes STI+HLT. Arguably the unit test is “broken” in the sense that delaying a timer interrupt by 1ms doesn’t technically guarantee the interrupt will arrive after STI+HLT, but it’s a reasonable assumption that KVM should support. Furthermore, an unbounded advancement also effectively unbounds the time spent busy waiting, e.g. if the guest programs a timer with a very large delay. 5000ns is a somewhat arbitrary threshold. When running on bare metal, which is the intended use case, timer advancement is expected to be in the general vicinity of 1000ns. 5000ns is high enough that false positives are unlikely, while not being so high as to negatively affect the host’s performance/stability. Note, a future patch will enable userspace to disable KVM’s adaptive tuning, which will allow priveleged userspace will to specifying an advancement value in excess of this arbitrary threshold in order to satisfy an abnormal use case. Cc: Liran Alon Cc: Wanpeng Li Cc: [email protected] Fixes: 3b8a5df6c4dc6 (“KVM: LAPIC: Tune lapic_timer_advance_ns automatically”) Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3be814567ee619e6bfaca7a1a93903e5d553e040 Author: Alan Stern Date: Fri Apr 19 13:52:38 2019 -0400 USB: core: Fix bug caused by duplicate interface PM usage counter commit c2b71462d294cf517a0bc6e4fd6424d7cee5596f upstream. The syzkaller fuzzer reported a bug in the USB hub driver which turned out to be caused by a negative runtime-PM usage counter. This allowed a hub to be runtime suspended at a time when the driver did not expect it. The symptom is a WARNING issued because the hub’s status URB is submitted while it is already active: URB 0000000031fb463e submitted while active WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363 The negative runtime-PM usage count was caused by an unfortunate design decision made when runtime PM was first implemented for USB. At that time, USB class drivers were allowed to unbind from their interfaces without balancing the usage counter (i.e., leaving it with a positive count). The core code would take care of setting the counter back to 0 before allowing another driver to bind to the interface. Later on when runtime PM was implemented for the entire kernel, the opposite decision was made: Drivers were required to balance their runtime-PM get and put calls. In order to maintain backward compatibility, however, the USB subsystem adapted to the new implementation by keeping an independent usage counter for each interface and using it to automatically adjust the normal usage counter back to 0 whenever a driver was unbound. This approach involves duplicating information, but what is worse, it doesn’t work properly in cases where a USB class driver delays decrementing the usage counter until after the driver’s disconnect() routine has returned and the counter has been adjusted back to 0. Doing so would cause the usage counter to become negative. There’s even a warning about this in the USB power management documentation! As it happens, this is exactly what the hub driver does. The kick_hub_wq() routine increments the runtime-PM usage counter, and the corresponding decrement is carried out by hub_event() in the context of the hub_wq work-queue thread. This work routine may sometimes run after the driver has been unbound from its interface, and when it does it causes the usage counter to go negative. It is not possible for hub_disconnect() to wait for a pending hub_event() call to finish, because hub_disconnect() is called with the device lock held and hub_event() acquires that lock. The only feasible fix is to reverse the original design decision: remove the duplicate interface-specific usage counter and require USB drivers to balance their runtime PM gets and puts. As far as I know, all existing drivers currently do this. Signed-off-by: Alan Stern Reported-and-tested-by: [email protected] CC: Signed-off-by: Greg Kroah-Hartman commit 0bc45b6b63c3ea91be81425b13e45b8bc582c733 Author: Alan Stern Date: Mon Apr 15 11:51:38 2019 -0400 USB: core: Fix unterminated string returned by usb_string() commit c01c348ecdc66085e44912c97368809612231520 upstream. Some drivers (such as the vub300 MMC driver) expect usb_string() to return a properly NUL-terminated string, even when an error occurs. (In fact, vub300’s probe routine doesn’t bother to check the return code from usb_string().) When the driver goes on to use an unterminated string, it leads to kernel errors such as stack-out-of-bounds, as found by the syzkaller USB fuzzer. An out-of-range string index argument is not at all unlikely, given that some devices don’t provide string descriptors and therefore list 0 as the value for their string indexes. This patch makes usb_string() return a properly terminated empty string along with the -EINVAL error code when an out-of-range index is encountered. And since a USB string index is a single-byte value, indexes >= 256 are just as invalid as values of 0 or below. Signed-off-by: Alan Stern Reported-by: [email protected] CC: Signed-off-by: Greg Kroah-Hartman commit ecc9d5c32adda175417e5bda3254b641fa420b44 Author: Malte Leip Date: Sun Apr 14 12:00:12 2019 +0200 usb: usbip: fix isoc packet num validation in get_pipe commit c409ca3be3c6ff3a1eeb303b191184e80d412862 upstream. Change the validation of number_of_packets in get_pipe to compare the number of packets to a fixed maximum number of packets allowed, set to be 1024. This number was chosen due to it being used by other drivers as well, for example drivers/usb/host/uhci-q.c Background/reason: The get_pipe function in stub_rx.c validates the number of packets in isochronous mode and aborts with an error if that number is too large, in order to prevent malicious input from possibly triggering large memory allocations. This was previously done by checking whether pdu->u.cmd_submit.number_of_packets is bigger than the number of packets that would be needed for pdu->u.cmd_submit.transfer_buffer_length bytes if all except possibly the last packet had maximum length, given by usb_endpoint_maxp(epd) * usb_endpoint_maxp_mult(epd). This leads to an error if URBs with packets shorter than the maximum possible length are submitted, which is allowed according to Documentation/driver-api/usb/URB.rst and occurs for example with the snd-usb-audio driver. Fixes: c6688ef9f297 (“usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input”) Signed-off-by: Malte Leip Cc: stable Acked-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit c0b68c8de3700b37fd7e1884d61ecfe559f11dc3 Author: Alan Stern Date: Thu Apr 18 13:12:07 2019 -0400 USB: dummy-hcd: Fix failure to give back unlinked URBs commit fc834e607ae3d18e1a20bca3f9a2d7f52ea7a2be upstream. The syzkaller USB fuzzer identified a failure mode in which dummy-hcd would never give back an unlinked URB. This causes usb_kill_urb() to hang, leading to WARNINGs and unkillable threads. In dummy-hcd, all URBs are given back by the dummy_timer() routine as it scans through the list of pending URBS. Failure to give back URBs can be caused by failure to start or early exit from the scanning loop. The code currently has two such pathways: One is triggered when an unsupported bus transfer speed is encountered, and the other by exhausting the simulated bandwidth for USB transfers during a frame. This patch removes those two paths, thereby allowing all unlinked URBs to be given back in a timely manner. It adds a check for the bus speed when the gadget first starts running, so that dummy_timer() will never thereafter encounter an unsupported speed. And it prevents the loop from exiting as soon as the total bandwidth has been used up (the scanning loop continues, giving back unlinked URBs as they are found, but not transferring any more data). Thanks to Andrey Konovalov for manually running the syzkaller fuzzer to help track down the source of the bug. Signed-off-by: Alan Stern Reported-and-tested-by: [email protected] CC: Signed-off-by: Greg Kroah-Hartman commit a3c42a175c5c2419c4616c7239cf234388404732 Author: Alan Stern Date: Mon Apr 22 11:16:04 2019 -0400 USB: w1 ds2490: Fix bug caused by improper use of altsetting array commit c114944d7d67f24e71562fcfc18d550ab787e4d4 upstream. The syzkaller USB fuzzer spotted a slab-out-of-bounds bug in the ds2490 driver. This bug is caused by improper use of the altsetting array in the usb_interface structure (the array’s entries are not always stored in numerical order), combined with a naive assumption that all interfaces probed by the driver will have the expected number of altsettings. The bug can be fixed by replacing references to the possibly non-existent intf->altsetting[alt] entry with the guaranteed-to-exist intf->cur_altsetting entry. Signed-off-by: Alan Stern Reported-and-tested-by: [email protected] CC: Signed-off-by: Greg Kroah-Hartman commit 03040fd71d5d05902643acde75a3c213dfa580b2 Author: Alan Stern Date: Tue Apr 23 14:48:29 2019 -0400 USB: yurex: Fix protection fault after device removal commit ef61eb43ada6c1d6b94668f0f514e4c268093ff3 upstream. The syzkaller USB fuzzer found a general-protection-fault bug in the yurex driver. The fault occurs when a device has been unplugged; the driver’s interrupt-URB handler logs an error message referring to the device by name, after the device has been unregistered and its name deallocated. This problem is caused by the fact that the interrupt URB isn’t cancelled until the driver’s private data structure is released, which can happen long after the device is gone. The cure is to make sure that the interrupt URB is killed before yurex_disconnect() returns; this is exactly the sort of thing that usb_poison_urb() was meant for. Signed-off-by: Alan Stern Reported-and-tested-by: [email protected] CC: Signed-off-by: Greg Kroah-Hartman commit 0ee051c78e8277041c4e60ca6fe492bacab0b789 Author: Takashi Iwai Date: Tue Apr 30 15:10:01 2019 +0200 ALSA: hda/realtek - Apply the fixup for ASUS Q325UAR commit 3887c26c0e24d50a4d0ce20cf4726737cee1a2fd upstream. Some ASUS models like Q325UAR with ALC295 codec requires the same fixup that has been applied to ALC294 codec. Just copy the entry with the pin matching to cover ALC295 too. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784485 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e11f632ca8e9e5e21a30ee2e4dfb43a6518d1923 Author: Kailang Yang Date: Fri Apr 26 16:13:54 2019 +0800 ALSA: hda/realtek - Fixed Dell AIO speaker noise commit 0700d3d117a7f110ddddbd83873e13652f69c54b upstream. Fixed Dell AIO speaker noise. spec->gen.auto_mute_via_amp = 1, this option was solved speaker white noise at boot. codec->power_save_node = 0, this option was solved speaker noise at resume back. Fixes: 9226665159f0 (“ALSA: hda/realtek - Fix Dell AIO LineOut issue”) Signed-off-by: Kailang Yang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b5fb5b38639ac569c0902ef5e49b31b240d6bf58 Author: Kailang Yang Date: Wed Apr 24 16:34:25 2019 +0800 ALSA: hda/realtek - Add new Dell platform for headset mode commit 0a29c57b76624723b6b00c027e0e992d130ace49 upstream. Add two Dell platform for headset mode. [ Note: this is a further correction / addition of the previous pin-based quirks for Dell machines; another entry for ALC236 with the d-mic pin 0x12 and an entry for ALC295 – tiwai ] Fixes: b26e36b7ef36 (“ALSA: hda/realtek - add two more pin configuration sets to quirk table”) Signed-off-by: Kailang Yang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e4f53dc963f9fa86932796424a921b0a6a8538e5 Author: Jarkko Nikula Date: Tue Apr 30 17:23:22 2019 +0300 i2c: Prevent runtime suspend of adapter when Host Notify is required commit 72bfcee11cf89509795c56b0e40a3785ab00bbdd upstream. Multiple users have reported their Synaptics touchpad has stopped working between v4.20.1 and v4.20.2 when using SMBus interface. The culprit for this appeared to be commit c5eb1190074c (“PCI / PM: Allow runtime PM without callback functions”) that fixed the runtime PM for i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801 for SMBus communication and testing showed they are able to get back working by preventing the runtime suspend of adapter. Normally when i2c-i801 SMBus adapter transmits with the client it resumes before operation and autosuspends after. However, if client requires SMBus Host Notify protocol, what those Synaptics touchpads do, then the host adapter must not go to runtime suspend since then it cannot process incoming SMBus Host Notify commands the client may send. Fix this by keeping I2C/SMBus adapter active in case client requires Host Notify. Reported-by: Keijo Vaara Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297 Fixes: c5eb1190074c (“PCI / PM: Allow runtime PM without callback functions”) Cc: [email protected] # v4.20+ Signed-off-by: Jarkko Nikula Acked-by: Rafael J. Wysocki Tested-by: Keijo Vaara Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit c4e6b01c07a01c1db6cf76b157b9e8358785daad Author: Anson Huang Date: Wed Apr 17 01:59:34 2019 +0000 i2c: imx: correct the method of getting private data in notifier_call commit d386bb9042f4629bf62cdc5952ea8aab225f24a7 upstream. The way of getting private imx_i2c_struct in i2c_imx_clk_notifier_call() is incorrect, should use clk_change_nb element to get correct address and avoid below kernel dump during POST_RATE_CHANGE notify by clk framework: Unable to handle kernel paging request at virtual address 03ef1488 pgd = (ptrval) [03ef1488] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: events reduce_bus_freq_handler PC is at i2c_imx_set_clk+0x10/0xb8 LR is at i2c_imx_clk_notifier_call+0x20/0x28 pc : [<806a893c>] lr : [<806a8a04>] psr: a0080013 sp : bf399dd8 ip : bf3432ac fp : bf7c1dc0 r10: 00000002 r9 : 00000000 r8 : 00000000 r7 : 03ef1480 r6 : bf399e50 r5 : ffffffff r4 : 00000000 r3 : bf025300 r2 : bf399e50 r1 : 00b71b00 r0 : bf399be8 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4e03004a DAC: 00000051 Process kworker/2:1 (pid: 38, stack limit = 0x(ptrval)) Stack: (0xbf399dd8 to 0xbf39a000) 9dc0: 806a89e4 00000000 9de0: ffffffff bf399e50 00000002 806a8a04 806a89e4 80142900 ffffffff 00000000 9e00: bf34ef18 bf34ef04 00000000 ffffffff bf399e50 80142d84 00000000 bf399e6c 9e20: bf34ef00 80f214c4 bf025300 00000002 80f08d08 bf017480 00000000 80142df0 9e40: 00000000 80166ed8 80c27638 8045de58 bf352340 03ef1480 00b71b00 0f82e242 9e60: bf025300 00000002 03ef1480 80f60e5c 00000001 8045edf0 00000002 8045eb08 9e80: bf025300 00000002 03ef1480 8045ee10 03ef1480 8045eb08 bf01be40 00000002 9ea0: 03ef1480 8045ee10 07de2900 8045eb08 bf01b780 00000002 07de2900 8045ee10 9ec0: 80c27898 bf399ee4 bf020a80 00000002 1f78a400 8045ee10 80f60e5c 80460514 9ee0: 80f60e5c bf01b600 bf01b480 80460460 0f82e242 bf383a80 bf383a00 80f60e5c 9f00: 00000000 bf7c1dc0 80f60e70 80460564 80f60df0 80f60d24 80f60df0 8011e72c 9f20: 00000000 80f60df0 80f60e6c bf7c4f00 00000000 8011e7ac bf274000 8013bd84 9f40: bf7c1dd8 80f03d00 bf274000 bf7c1dc0 bf274014 bf7c1dd8 80f03d00 bf398000 9f60: 00000008 8013bfb4 00000000 bf25d100 bf25d0c0 00000000 bf274000 8013bf88 9f80: bf25d11c bf0cfebc 00000000 8014140c bf25d0c0 801412ec 00000000 00000000 9fa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<806a893c>] (i2c_imx_set_clk) from [<806a8a04>] (i2c_imx_clk_notifier_call+0x20/0x28) [<806a8a04>] (i2c_imx_clk_notifier_call) from [<80142900>] (notifier_call_chain+0x44/0x84) [<80142900>] (notifier_call_chain) from [<80142d84>] (__srcu_notifier_call_chain+0x44/0x98) [<80142d84>] (__srcu_notifier_call_chain) from [<80142df0>] (srcu_notifier_call_chain+0x18/0x20) [<80142df0>] (srcu_notifier_call_chain) from [<8045de58>] (__clk_notify+0x78/0xa4) [<8045de58>] (__clk_notify) from [<8045edf0>] (__clk_recalc_rates+0x60/0xb4) [<8045edf0>] (__clk_recalc_rates) from [<8045ee10>] (__clk_recalc_rates+0x80/0xb4) Code: e92d40f8 e5903298 e59072a0 e1530001 (e5975008) —[ end trace fc7f5514b97b6cbb ]— Fixes: 90ad2cbe88c2 (“i2c: imx: use clk notifier for rate changes”) Signed-off-by: Anson Huang Reviewed-by: Dong Aisheng Signed-off-by: Wolfram Sang Cc: [email protected] Signed-off-by: Greg Kroah-Hartman commit 8f5a04152e26d1803f1bde5b2f722e7a4db96935 Author: Ard Biesheuvel Date: Tue Apr 30 11:47:34 2019 +0200 i2c: synquacer: fix enumeration of slave devices commit 95e0cf3caeb11e1b0398c747b5cfa12828263824 upstream. The I2C host driver for SynQuacer fails to populate the of_node and ACPI companion fields of the struct i2c_adapter it instantiates, resulting in enumeration of the subordinate I2C bus to fail. Fixes: 0d676a6c4390 (“i2c: add support for Socionext SynQuacer I2C controller”) Cc: # v4.19+ Signed-off-by: Ard Biesheuvel Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 5074530caf7c96f0e0083fccfaff3a868aef3460 Author: Johannes Berg Date: Mon Apr 15 11:39:33 2019 +0200 mac80211: don’t attempt to rename ERR_PTR() debugfs dirs commit 517879147493a5e1df6b89a50f708f1133fcaddb upstream. We need to dereference the directory to get its parent to be able to rename it, so it’s clearly not safe to try to do this with ERR_PTR() pointers. Skip in this case. It seems that this is most likely what was causing the report by syzbot, but I’m not entirely sure as it didn’t come with a reproducer this time. Cc: [email protected] Reported-by: [email protected] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3ca91b5353a208c9c32548bd74ecb5f2486d7ced Author: Miquel Raynal Date: Mon Apr 8 10:31:45 2019 +0200 mtd: rawnand: marvell: Clean the controller state before each operation commit 9a8f612ca0d6a436e6471c9bed516d34a2cc626f upstream. Since the migration of the driver to stop using the legacy ->select_chip() hook, there is nothing deselecting the target anymore, thus the selection is not forced at the next access. Ensure the ND_RUN bit and the interrupts are always in a clean state. Cc: Daniel Mack Cc: [email protected] Fixes: b25251414f6e00 ("mtd: rawnand: marvell: Stop implementing ->select_chip()") Suggested-by: Boris Brezillon Signed-off-by: Miquel Raynal Tested-by: Daniel Mack Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 761360f3302196680f683799ae5311623e012c1f Author: Douglas Anderson Date: Wed Apr 3 21:01:06 2019 -0700 mwifiex: Make resume actually do something useful again on SDIO cards commit b82d6c1f8f8288f744a9dcc16cd3085d535decca upstream. The commit fc3a2fcaa1ba (“mwifiex: use atomic bitops to represent adapter status variables”) had a fairly straightforward bug in it. It contained this bit of diff: - if (!adapter->is_suspended) { + if (test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) { As you can see the patch missed the “!” when converting to the atomic bitops. This meant that the resume hasn’t done anything at all since that commit landed and suspend/resume for mwifiex SDIO cards has been totally broken. After fixing this mwifiex suspend/resume appears to work again, at least with the simple testing I’ve done. Fixes: fc3a2fcaa1ba (“mwifiex: use atomic bitops to represent adapter status variables”) Cc: Signed-off-by: Douglas Anderson Reviewed-by: Brian Norris Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 7e4e59c961263bb26b637be911f7d55bb8742676 Author: Emmanuel Grumbach Date: Sun Apr 21 17:58:11 2019 +0300 iwlwifi: fix driver operation for 5350 commit 5c9adef9789148d382d7d1307c3d6bfaf51d143d upstream. We introduced a bug that prevented this old device from working. The driver would simply not be able to complete the INIT flow while spewing this warning: CSR addresses aren’t configured WARNING: CPU: 0 PID: 819 at drivers/net/wireless/intel/iwlwifi/pcie/drv.c:917 iwl_pci_probe+0x160/0x1e0 [iwlwifi] Cc: [email protected] # v4.18+ Fixes: a8cbb46f831d (“iwlwifi: allow different csr flags for different device families”) Signed-off-by: Emmanuel Grumbach Fixes: c8f1b51e506d (“iwlwifi: allow different csr flags for different device families”) Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit fb1f2cb221f56f6c4509ddf189e6f2d906839bab Author: Eugeniy Paltsev Date: Mon Apr 8 16:04:38 2019 +0300 ARC: memset: fix build with L1_CACHE_SHIFT != 6 commit 55c0c4c793b538fb438bcc72481b9dc2f79fe5a9 upstream. In case of ‘L1_CACHE_SHIFT != 6’ we define dummy assembly macroses PREALLOC_INSTR and PREFETCHW_INSTR without arguments. However we pass arguments to them in code which cause build errors. Fix that. Signed-off-by: Eugeniy Paltsev Cc: [5.0] Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 00ddbaed26634eaa8841f692e238f6994b4f261f Author: Tycho Andersen Date: Wed Mar 6 13:14:13 2019 -0700 seccomp: Make NEW_LISTENER and TSYNC flags exclusive commit 7a0df7fbc14505e2e2be19ed08654a09e1ed5bf6 upstream. As the comment notes, the return codes for TSYNC and NEW_LISTENER conflict, because they both return positive values, one in the case of success and one in the case of error. So, let’s disallow both of these flags together. While this is technically a userspace break, all the users I know of are still waiting on me to land this feature in libseccomp, so I think it’ll be safe. Also, at present my use case doesn’t require TSYNC at all, so this isn’t a big deal to disallow. If someone wanted to support this, a path forward would be to add a new flag like TSYNC_AND_LISTENER_YES_I_UNDERSTAND_THAT_TSYNC_WILL_JUST_RETURN_EAGAIN, but the use cases are so different I don’t see it really happening. Finally, it’s worth noting that this does actually fix a UAF issue: at the end of seccomp_set_mode_filter(), we have: if (flags & SECCOMP_FILTER_FLAG_NEW_LISTENER) { if (ret < 0) { listener_f->private_data = NULL; fput(listener_f); put_unused_fd(listener); } else { fd_install(listener, listener_f); ret = listener; } } out_free: seccomp_filter_free(prepared); But if ret > 0 because TSYNC raced, we’ll install the listener fd and then free the filter out from underneath it, causing a UAF when the task closes it or dies. This patch also switches the condition to be simply if (ret), so that if someone does add the flag mentioned above, they won’t have to remember to fix this too. Reported-by: [email protected] Fixes: 6a21cc50f0c7 (“seccomp: add a return code to trap to userspace”) CC: [email protected] # v5.0+ Signed-off-by: Tycho Andersen Signed-off-by: Kees Cook Acked-by: James Morris Signed-off-by: Greg Kroah-Hartman commit d956e63340308f817a50a6e69f3510980c859b09 Author: Kees Cook Date: Wed Apr 24 09:32:55 2019 -0700 selftests/seccomp: Prepare for exclusive seccomp flags commit 4ee0776760af03f181e6b80baf5fb1cc1a980f50 upstream. Some seccomp flags will become exclusive, so the selftest needs to be adjusted to mask those out and test them individually for the “all flags” tests. Cc: [email protected] # v5.0+ Signed-off-by: Kees Cook Reviewed-by: Tycho Andersen Acked-by: James Morris Signed-off-by: Greg Kroah-Hartman