commit 996e23d2f34b31f2b8702b7dbfee69b86803729e Author: Alexandre Frade Date: Wed Apr 17 10:40:20 2019 -0300 4.19.35-xanmod18 Signed-off-by: Alexandre Frade commit 672180d6896b0c9b096833bab02b9a0bf81d442f Author: Alexandre Frade Date: Wed Apr 17 10:31:51 2019 -0300 pds: fix merge linux v4.19.34 [2/2] commit 2b51ac1547954ab0bc559c14b0aaf1b3facf2eed Merge: 7f1535a6a47b 4b0e041c9dad Author: Alexandre Frade Date: Wed Apr 17 10:29:41 2019 -0300 Merge tag 'v4.19.35' into 4.19 This is the 4.19.35 stable release commit 7f1535a6a47b46e744d92b02ef1ee21d756d6b48 Author: Alexandre Frade Date: Wed Apr 17 10:29:32 2019 -0300 pds: fix merge linux v4.19.34 [1/2] commit 4b0e041c9dada60197efc1697928cd32c2c70cd2 Author: Greg Kroah-Hartman Date: Wed Apr 17 08:38:55 2019 +0200 Linux 4.19.35 commit 59bf185ae6b7d1a7ec2d7ff312b94df787ebcb11 Author: Marc Orr Date: Mon Apr 1 23:56:00 2019 -0700 KVM: x86: nVMX: fix x2APIC VTPR read intercept commit c73f4c998e1fd4249b9edfa39e23f4fda2b9b041 upstream. Referring to the "VIRTUALIZING MSR-BASED APIC ACCESSES" chapter of the SDM, when "virtualize x2APIC mode" is 1 and "APIC-register virtualization" is 0, a RDMSR of 808H should return the VTPR from the virtual APIC page. However, for nested, KVM currently fails to disable the read intercept for this MSR. This means that a RDMSR exit takes precedence over "virtualize x2APIC mode", and KVM passes through L1's TPR to L2, instead of sourcing the value from L2's virtual APIC page. This patch fixes the issue by disabling the read intercept, in VMCS02, for the VTPR when "APIC-register virtualization" is 0. The issue described above and fix prescribed here, were verified with a related patch in kvm-unit-tests titled "Test VMX's virtualize x2APIC mode w/ nested". Signed-off-by: Marc Orr Reviewed-by: Jim Mattson Fixes: c992384bde84f ("KVM: vmx: speed up MSR bitmap merge") Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 119031be7b0a2ce4ff4cd5525bec6d42817ff53d Author: Marc Orr Date: Mon Apr 1 23:55:59 2019 -0700 KVM: x86: nVMX: close leak of L0's x2APIC MSRs (CVE-2019-3887) commit acff78477b9b4f26ecdf65733a4ed77fe837e9dc upstream. The nested_vmx_prepare_msr_bitmap() function doesn't directly guard the x2APIC MSR intercepts with the "virtualize x2APIC mode" MSR. As a result, we discovered the potential for a buggy or malicious L1 to get access to L0's x2APIC MSRs, via an L2, as follows. 1. L1 executes WRMSR(IA32_SPEC_CTRL, 1). This causes the spec_ctrl variable, in nested_vmx_prepare_msr_bitmap() to become true. 2. L1 disables "virtualize x2APIC mode" in VMCS12. 3. L1 enables "APIC-register virtualization" in VMCS12. Now, KVM will set VMCS02's x2APIC MSR intercepts from VMCS12, and then set "virtualize x2APIC mode" to 0 in VMCS02. Oops. This patch closes the leak by explicitly guarding VMCS02's x2APIC MSR intercepts with VMCS12's "virtualize x2APIC mode" control. The scenario outlined above and fix prescribed here, were verified with a related patch in kvm-unit-tests titled "Add leak scenario to virt_x2apic_mode_test". Note, it looks like this issue may have been introduced inadvertently during a merge---see 15303ba5d1cd. Signed-off-by: Marc Orr Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f8053df634d40c733f26ca49c2c3835002e61b77 Author: Erik Schmauss Date: Wed Oct 17 14:09:35 2018 -0700 ACPICA: AML interpreter: add region addresses in global list during initialization commit 4abb951b73ff0a8a979113ef185651aa3c8da19b upstream. The table load process omitted adding the operation region address range to the global list. This omission is problematic because the OS queries the global list to check for address range conflicts before deciding which drivers to load. This commit may result in warning messages that look like the following: [ 7.871761] ACPI Warning: system_IO range 0x00000428-0x0000042F conflicts with op_region 0x00000400-0x0000047F (\PMIO) (20180531/utaddress-213) [ 7.871769] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver However, these messages do not signify regressions. It is a result of properly adding address ranges within the global address list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011 Tested-by: Jean-Marc Lenoir Signed-off-by: Erik Schmauss Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit fad502a9439ec284278c501ee7e69c391d024f8a Author: Tomohiro Mayama Date: Sun Mar 10 01:10:12 2019 +0900 arm64: dts: rockchip: Fix vcc_host1_5v GPIO polarity on rk3328-rock64 commit a8772e5d826d0f61f8aa9c284b3ab49035d5273d upstream. This patch makes USB ports functioning again. Fixes: 955bebde057e ("arm64: dts: rockchip: add rk3328-rock64 board") Cc: stable@vger.kernel.org Suggested-by: Robin Murphy Signed-off-by: Tomohiro Mayama Tested-by: Katsuhiro Suzuki Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit c963475972f67e610ad19d6f1d3fb15a2fd2ca69 Author: Katsuhiro Suzuki Date: Fri Sep 7 00:39:47 2018 +0900 arm64: dts: rockchip: fix vcc_host1_5v pin assign on rk3328-rock64 commit ef05bcb60c1a8841e38c91923ba998181117a87c upstream. This patch fixes pin assign of vcc_host1_5v. This regulator is controlled by USB20_HOST_DRV signal. ROCK64 schematic says that GPIO0_A2 pin is used as USB20_HOST_DRV. GPIO0_D3 pin is for SPDIF_TX_M0. Signed-off-by: Katsuhiro Suzuki Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit aa9ee4b1ed46b504097da723c9b700a328956d28 Author: Mikulas Patocka Date: Fri Apr 5 15:26:39 2019 -0400 dm integrity: fix deadlock with overlapping I/O commit 4ed319c6ac08e9a28fca7ac188181ac122f4de84 upstream. dm-integrity will deadlock if overlapping I/O is issued to it, the bug was introduced by commit 724376a04d1a ("dm integrity: implement fair range locks"). Users rarely use overlapping I/O so this bug went undetected until now. Fix this bug by correcting, likely cut-n-paste, typos in ranges_overlap() and also remove a flawed ranges_overlap() check in remove_range_unlocked(). This condition could leave unprocessed bios hanging on wait_list forever. Cc: stable@vger.kernel.org # v4.19+ Fixes: 724376a04d1a ("dm integrity: implement fair range locks") Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 469b40a429c54b21eb499287daaea08559793854 Author: Ilya Dryomov Date: Tue Mar 26 20:20:58 2019 +0100 dm table: propagate BDI_CAP_STABLE_WRITES to fix sporadic checksum errors commit eb40c0acdc342b815d4d03ae6abb09e80c0f2988 upstream. Some devices don't use blk_integrity but still want stable pages because they do their own checksumming. Examples include rbd and iSCSI when data digests are negotiated. Stacking DM (and thus LVM) on top of these devices results in sporadic checksum errors. Set BDI_CAP_STABLE_WRITES if any underlying device has it set. Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4f5c99e0421cfd4b3a6cc5827b49f4fd5e150da5 Author: Mikulas Patocka Date: Thu Mar 21 16:46:12 2019 -0400 dm: revert 8f50e358153d ("dm: limit the max bio size as BIO_MAX_PAGES * PAGE_SIZE") commit 75ae193626de3238ca5fb895868ec91c94e63b1b upstream. The limit was already incorporated to dm-crypt with commit 4e870e948fba ("dm crypt: fix error with too large bios"), so we don't need to apply it globally to all targets. The quantity BIO_MAX_PAGES * PAGE_SIZE is wrong anyway because the variable ti->max_io_len it is supposed to be in the units of 512-byte sectors not in bytes. Reduction of the limit to 1048576 sectors could even cause data corruption in rare cases - suppose that we have a dm-striped device with stripe size 768MiB. The target will call dm_set_target_max_io_len with the value 1572864. The buggy code would reduce it to 1048576. Now, the dm-core will errorneously split the bios on 1048576-sector boundary insetad of 1572864-sector boundary and pass these stripe-crossing bios to the striped target. Cc: stable@vger.kernel.org # v4.16+ Fixes: 8f50e358153d ("dm: limit the max bio size as BIO_MAX_PAGES * PAGE_SIZE") Signed-off-by: Mikulas Patocka Acked-by: Ming Lei Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 30dc4d7b299dfc0d773f20b09835445c90adb05d Author: Mikulas Patocka Date: Wed Mar 13 07:56:02 2019 -0400 dm integrity: change memcmp to strncmp in dm_integrity_ctr commit 0d74e6a3b6421d98eeafbed26f29156d469bc0b5 upstream. If the string opt_string is small, the function memcmp can access bytes that are beyond the terminating nul character. In theory, it could cause segfault, if opt_string were located just below some unmapped memory. Change from memcmp to strncmp so that we don't read bytes beyond the end of the string. Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 5be6e02cfbdf62a48522fd8b743002b9d084e0bb Author: Sergey Miroshnichenko Date: Tue Mar 12 15:05:48 2019 +0300 PCI: pciehp: Ignore Link State Changes after powering off a slot commit 3943af9d01e94330d0cfac6fccdbc829aad50c92 upstream. During a safe hot remove, the OS powers off the slot, which may cause a Data Link Layer State Changed event. The slot has already been set to OFF_STATE, so that event results in re-enabling the device, making it impossible to safely remove it. Clear out the Presence Detect Changed and Data Link Layer State Changed events when the disabled slot has settled down. It is still possible to re-enable the device if it remains in the slot after pressing the Attention Button by pressing it again. Fixes the problem that Micah reported below: an NVMe drive power button may not actually turn off the drive. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203237 Reported-by: Micah Parrish Tested-by: Micah Parrish Signed-off-by: Sergey Miroshnichenko [bhelgaas: changelog, add bugzilla URL] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman commit 250fef8de77cc08f3fc49418d3348368aee0c5e6 Author: Andre Przywara Date: Fri Apr 5 16:20:47 2019 +0100 PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller commit 9cde402a59770a0669d895399c13407f63d7d209 upstream. There is a Marvell 88SE9170 PCIe SATA controller I found on a board here. Some quick testing with the ARM SMMU enabled reveals that it suffers from the same requester ID mixup problems as the other Marvell chips listed already. Add the PCI vendor/device ID to the list of chips which need the workaround. Signed-off-by: Andre Przywara Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 056264656a67aca1129342febef29fe60280a4f2 Author: Lendacky, Thomas Date: Tue Apr 2 15:21:18 2019 +0000 x86/perf/amd: Remove need to check "running" bit in NMI handler commit 3966c3feca3fd10b2935caa0b4a08c7dd59469e5 upstream. Spurious interrupt support was added to perf in the following commit, almost a decade ago: 63e6be6d98e1 ("perf, x86: Catch spurious interrupts after disabling counters") The two previous patches (resolving the race condition when disabling a PMC and NMI latency mitigation) allow for the removal of this older spurious interrupt support. Currently in x86_pmu_stop(), the bit for the PMC in the active_mask bitmap is cleared before disabling the PMC, which sets up a race condition. This race condition was mitigated by introducing the running bitmap. That race condition can be eliminated by first disabling the PMC, waiting for PMC reset on overflow and then clearing the bit for the PMC in the active_mask bitmap. The NMI handler will not re-enable a disabled counter. If x86_pmu_stop() is called from the perf NMI handler, the NMI latency mitigation support will guard against any unhandled NMI messages. Signed-off-by: Tom Lendacky Signed-off-by: Peter Zijlstra (Intel) Cc: # 4.14.x- Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Jiri Olsa Cc: Linus Torvalds Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Link: https://lkml.kernel.org/r/Message-ID: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 23d39b0af08e533feb697302b454586249ea793d Author: Lendacky, Thomas Date: Tue Apr 2 15:21:16 2019 +0000 x86/perf/amd: Resolve NMI latency issues for active PMCs commit 6d3edaae16c6c7d238360f2841212c2b26774d5e upstream. On AMD processors, the detection of an overflowed PMC counter in the NMI handler relies on the current value of the PMC. So, for example, to check for overflow on a 48-bit counter, bit 47 is checked to see if it is 1 (not overflowed) or 0 (overflowed). When the perf NMI handler executes it does not know in advance which PMC counters have overflowed. As such, the NMI handler will process all active PMC counters that have overflowed. NMI latency in newer AMD processors can result in multiple overflowed PMC counters being processed in one NMI and then a subsequent NMI, that does not appear to be a back-to-back NMI, not finding any PMC counters that have overflowed. This may appear to be an unhandled NMI resulting in either a panic or a series of messages, depending on how the kernel was configured. To mitigate this issue, add an AMD handle_irq callback function, amd_pmu_handle_irq(), that will invoke the common x86_pmu_handle_irq() function and upon return perform some additional processing that will indicate if the NMI has been handled or would have been handled had an earlier NMI not handled the overflowed PMC. Using a per-CPU variable, a minimum value of the number of active PMCs or 2 will be set whenever a PMC is active. This is used to indicate the possible number of NMIs that can still occur. The value of 2 is used for when an NMI does not arrive at the LAPIC in time to be collapsed into an already pending NMI. Each time the function is called without having handled an overflowed counter, the per-CPU value is checked. If the value is non-zero, it is decremented and the NMI indicates that it handled the NMI. If the value is zero, then the NMI indicates that it did not handle the NMI. Signed-off-by: Tom Lendacky Signed-off-by: Peter Zijlstra (Intel) Cc: # 4.14.x- Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Jiri Olsa Cc: Linus Torvalds Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Link: https://lkml.kernel.org/r/Message-ID: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e5a791b4ab5669285c1844389b99b0c27a4fcbf7 Author: Lendacky, Thomas Date: Tue Apr 2 15:21:14 2019 +0000 x86/perf/amd: Resolve race condition when disabling PMC commit 914123fa39042e651d79eaf86bbf63a1b938dddf upstream. On AMD processors, the detection of an overflowed counter in the NMI handler relies on the current value of the counter. So, for example, to check for overflow on a 48 bit counter, bit 47 is checked to see if it is 1 (not overflowed) or 0 (overflowed). There is currently a race condition present when disabling and then updating the PMC. Increased NMI latency in newer AMD processors makes this race condition more pronounced. If the counter value has overflowed, it is possible to update the PMC value before the NMI handler can run. The updated PMC value is not an overflowed value, so when the perf NMI handler does run, it will not find an overflowed counter. This may appear as an unknown NMI resulting in either a panic or a series of messages, depending on how the kernel is configured. To eliminate this race condition, the PMC value must be checked after disabling the counter. Add an AMD function, amd_pmu_disable_all(), that will wait for the NMI handler to reset any active and overflowed counter after calling x86_pmu_disable_all(). Signed-off-by: Tom Lendacky Signed-off-by: Peter Zijlstra (Intel) Cc: # 4.14.x- Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Jiri Olsa Cc: Linus Torvalds Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Link: https://lkml.kernel.org/r/Message-ID: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4b004504bfcc66a0e5767abe030122469e7617f3 Author: Alexander Potapenko Date: Tue Apr 2 13:28:13 2019 +0200 x86/asm: Use stricter assembly constraints in bitops commit 5b77e95dd7790ff6c8fbf1cd8d0104ebed818a03 upstream. There's a number of problems with how arch/x86/include/asm/bitops.h is currently using assembly constraints for the memory region bitops are modifying: 1) Use memory clobber in bitops that touch arbitrary memory Certain bit operations that read/write bits take a base pointer and an arbitrarily large offset to address the bit relative to that base. Inline assembly constraints aren't expressive enough to tell the compiler that the assembly directive is going to touch a specific memory location of unknown size, therefore we have to use the "memory" clobber to indicate that the assembly is going to access memory locations other than those listed in the inputs/outputs. To indicate that BTR/BTS instructions don't necessarily touch the first sizeof(long) bytes of the argument, we also move the address to assembly inputs. This particular change leads to size increase of 124 kernel functions in a defconfig build. For some of them the diff is in NOP operations, other end up re-reading values from memory and may potentially slow down the execution. But without these clobbers the compiler is free to cache the contents of the bitmaps and use them as if they weren't changed by the inline assembly. 2) Use byte-sized arguments for operations touching single bytes. Passing a long value to ANDB/ORB/XORB instructions makes the compiler treat sizeof(long) bytes as being clobbered, which isn't the case. This may theoretically lead to worse code in the case of heavy optimization. Practical impact: I've built a defconfig kernel and looked through some of the functions generated by GCC 7.3.0 with and without this clobber, and didn't spot any miscompilations. However there is a (trivial) theoretical case where this code leads to miscompilation: https://lkml.org/lkml/2019/3/28/393 using just GCC 8.3.0 with -O2. It isn't hard to imagine someone writes such a function in the kernel someday. So the primary motivation is to fix an existing misuse of the asm directive, which happens to work in certain configurations now, but isn't guaranteed to work under different circumstances. [ --mingo: Added -stable tag because defconfig only builds a fraction of the kernel and the trivial testcase looks normal enough to be used in existing or in-development code. ] Signed-off-by: Alexander Potapenko Cc: Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Dmitry Vyukov Cc: H. Peter Anvin Cc: James Y Knight Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20190402112813.193378-1-glider@google.com [ Edited the changelog, tidied up one of the defines. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 356ae4deab4b0c537c219600a3754e5ed54c40aa Author: Rasmus Villemoes Date: Fri Jan 11 09:49:30 2019 +0100 x86/asm: Remove dead __GNUC__ conditionals commit 88ca66d8540ca26119b1428cddb96b37925bdf01 upstream. The minimum supported gcc version is >= 4.6, so these can be removed. Signed-off-by: Rasmus Villemoes Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Dan Williams Cc: Geert Uytterhoeven Cc: Ingo Molnar Cc: Matthew Wilcox Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190111084931.24601-1-linux@rasmusvillemoes.dk Signed-off-by: Greg Kroah-Hartman commit f7b778b9007e2f1e5e8992489567904f9258f389 Author: Max Filippov Date: Thu Apr 4 11:08:40 2019 -0700 xtensa: fix return_address commit ada770b1e74a77fff2d5f539bf6c42c25f4784db upstream. return_address returns the address that is one level higher in the call stack than requested in its argument, because level 0 corresponds to its caller's return address. Use requested level as the number of stack frames to skip. This fixes the address reported by might_sleep and friends. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit cb75a0c5d3816531af8b768975f25e320e988f62 Author: Mel Gorman Date: Tue Mar 19 12:36:10 2019 +0000 sched/fair: Do not re-read ->h_load_next during hierarchical load calculation commit 0e9f02450da07fc7b1346c8c32c771555173e397 upstream. A NULL pointer dereference bug was reported on a distribution kernel but the same issue should be present on mainline kernel. It occured on s390 but should not be arch-specific. A partial oops looks like: Unable to handle kernel pointer dereference in virtual kernel address space ... Call Trace: ... try_to_wake_up+0xfc/0x450 vhost_poll_wakeup+0x3a/0x50 [vhost] __wake_up_common+0xbc/0x178 __wake_up_common_lock+0x9e/0x160 __wake_up_sync_key+0x4e/0x60 sock_def_readable+0x5e/0x98 The bug hits any time between 1 hour to 3 days. The dereference occurs in update_cfs_rq_h_load when accumulating h_load. The problem is that cfq_rq->h_load_next is not protected by any locking and can be updated by parallel calls to task_h_load. Depending on the compiler, code may be generated that re-reads cfq_rq->h_load_next after the check for NULL and then oops when reading se->avg.load_avg. The dissassembly showed that it was possible to reread h_load_next after the check for NULL. While this does not appear to be an issue for later compilers, it's still an accident if the correct code is generated. Full locking in this path would have high overhead so this patch uses READ_ONCE to read h_load_next only once and check for NULL before dereferencing. It was confirmed that there were no further oops after 10 days of testing. As Peter pointed out, it is also necessary to use WRITE_ONCE() to avoid any potential problems with store tearing. Signed-off-by: Mel Gorman Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Fixes: 685207963be9 ("sched: Move h_load calculation to task_h_load()") Link: https://lkml.kernel.org/r/20190319123610.nsivgf3mjbjjesxb@techsingularity.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ed3adb562fc8ee9dac558bc7048e73abec943c62 Author: Dan Carpenter Date: Thu Apr 4 18:12:17 2019 +0300 xen: Prevent buffer overflow in privcmd ioctl commit 42d8644bd77dd2d747e004e367cb0c895a606f39 upstream. The "call" variable comes from the user in privcmd_ioctl_hypercall(). It's an offset into the hypercall_page[] which has (PAGE_SIZE / 32) elements. We need to put an upper bound on it to prevent an out of bounds access. Cc: stable@vger.kernel.org Fixes: 1246ae0bb992 ("xen: add variable hypercall caller") Signed-off-by: Dan Carpenter Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 84c6c2af4c532dc3ce26d5c3f5e8b0824ac6b441 Author: Will Deacon Date: Mon Apr 8 17:56:34 2019 +0100 arm64: backtrace: Don't bother trying to unwind the userspace stack commit 1e6f5440a6814d28c32d347f338bfef68bc3e69d upstream. Calling dump_backtrace() with a pt_regs argument corresponding to userspace doesn't make any sense and our unwinder will simply print "Call trace:" before unwinding the stack looking for user frames. Rather than go through this song and dance, just return early if we're passed a user register state. Cc: Fixes: 1149aad10b1e ("arm64: Add dump_backtrace() in show_regs") Reported-by: Kefeng Wang Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 1ec54cee633369730ba46df65410b70d295491ca Author: Peter Geis Date: Wed Mar 13 18:45:36 2019 +0000 arm64: dts: rockchip: fix rk3328 rgmii high tx error rate commit 6fd8b9780ec1a49ac46e0aaf8775247205e66231 upstream. Several rk3328 based boards experience high rgmii tx error rates. This is due to several pins in the rk3328.dtsi rgmii pinmux that are missing a defined pull strength setting. This causes the pinmux driver to default to 2ma (bit mask 00). These pins are only defined in the rk3328.dtsi, and are not listed in the rk3328 specification. The TRM only lists them as "Reserved" (RK3328 TRM V1.1, 3.3.3 Detail Register Description, GRF_GPIO0B_IOMUX, GRF_GPIO0C_IOMUX, GRF_GPIO0D_IOMUX). However, removal of these pins from the rgmii pinmux definition causes the interface to fail to transmit. Also, the rgmii tx and rx pins defined in the dtsi are not consistent with the rk3328 specification, with tx pins currently set to 12ma and rx pins set to 2ma. Fix this by setting tx pins to 8ma and the rx pins to 4ma, consistent with the specification. Defining the drive strength for the undefined pins eliminated the high tx packet error rate observed under heavy data transfers. Aligning the drive strength to the TRM values eliminated the occasional packet retry errors under iperf3 testing. This allows much higher data rates with no recorded tx errors. Tested on the rk3328-roc-cc board. Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs") Cc: stable@vger.kernel.org Signed-off-by: Peter Geis Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 82a30a5d60e30e66ea4965c119029683fa94950e Author: Will Deacon Date: Mon Apr 8 12:45:09 2019 +0100 arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value commit 045afc24124d80c6998d9c770844c67912083506 upstream. Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't explicitly set the return value on the non-faulting path and instead leaves it holding the result of the underlying atomic operation. This means that any FUTEX_WAKE_OP atomic operation which computes a non-zero value will be reported as having failed. Regrettably, I wrote the buggy code back in 2011 and it was upstreamed as part of the initial arm64 support in 2012. The reasons we appear to get away with this are: 1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get exercised by futex() test applications 2. If the result of the atomic operation is zero, the system call behaves correctly 3. Prior to version 2.25, the only operation used by GLIBC set the futex to zero, and therefore worked as expected. From 2.25 onwards, FUTEX_WAKE_OP is not used by GLIBC at all. Fix the implementation by ensuring that the return value is either 0 to indicate that the atomic operation completed successfully, or -EFAULT if we encountered a fault when accessing the user mapping. Cc: Fixes: 6170a97460db ("arm64: Atomic operations") Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 4362ff977bc63f85e4a4f23845d67a7a8559eaad Author: David Engraf Date: Mon Mar 11 08:57:42 2019 +0100 ARM: dts: at91: Fix typo in ISC_D0 on PC9 commit e7dfb6d04e4715be1f3eb2c60d97b753fd2e4516 upstream. The function argument for the ISC_D0 on PC9 was incorrect. According to the documentation it should be 'C' aka 3. Signed-off-by: David Engraf Reviewed-by: Nicolas Ferre Signed-off-by: Ludovic Desroches Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux") Cc: # v4.4+ Signed-off-by: Greg Kroah-Hartman commit 627a7d5a4422e9f1d3ce5c2fd4dd64d3125357a4 Author: Peter Ujfalusi Date: Fri Mar 15 12:59:09 2019 +0200 ARM: dts: am335x-evm: Correct the regulators for the audio codec commit 4f96dc0a3e79ec257a2b082dab3ee694ff88c317 upstream. Correctly map the regulators used by tlv320aic3106. Both 1.8V and 3.3V for the codec is derived from VBAT via fixed regulators. Cc: # v4.14+ Signed-off-by: Peter Ujfalusi Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 57a9c1f40f5be2e9061d21d8a21a1b977abb9251 Author: Peter Ujfalusi Date: Fri Mar 15 12:59:17 2019 +0200 ARM: dts: am335x-evmsk: Correct the regulators for the audio codec commit 6691370646e844be98bb6558c024269791d20bd7 upstream. Correctly map the regulators used by tlv320aic3106. Both 1.8V and 3.3V for the codec is derived from VBAT via fixed regulators. Cc: # v4.14+ Signed-off-by: Peter Ujfalusi Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 3ba48b3cf850db83536b4b0625e66f0472888f30 Author: Jonas Karlman Date: Sun Feb 24 21:51:22 2019 +0000 ARM: dts: rockchip: fix rk3288 cpu opp node reference commit 6b2fde3dbfab6ebc45b0cd605e17ca5057ff9a3b upstream. The following error can be seen during boot: of: /cpus/cpu@501: Couldn't find opp node Change cpu nodes to use operating-points-v2 in order to fix this. Fixes: ce76de984649 ("ARM: dts: rockchip: convert rk3288 to operating-points-v2") Cc: stable@vger.kernel.org Signed-off-by: Jonas Karlman Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 32fdac09765db00c91b32334be9dae7250792518 Author: Cornelia Huck Date: Mon Apr 8 14:33:22 2019 +0200 virtio: Honour 'may_reduce_num' in vring_create_virtqueue commit cf94db21905333e610e479688add629397a4b384 upstream. vring_create_virtqueue() allows the caller to specify via the may_reduce_num parameter whether the vring code is allowed to allocate a smaller ring than specified. However, the split ring allocation code tries to allocate a smaller ring on allocation failure regardless of what the caller specified. This may cause trouble for e.g. virtio-pci in legacy mode, which does not support ring resizing. (The packed ring code does not resize in any case.) Let's fix this by bailing out immediately in the split ring code if the requested size cannot be allocated and may_reduce_num has not been specified. While at it, fix a typo in the usage instructions. Fixes: 2a2d1382fe9d ("virtio: Add improved queue allocation API") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Cornelia Huck Signed-off-by: Michael S. Tsirkin Reviewed-by: Halil Pasic Reviewed-by: Jens Freimann Signed-off-by: Greg Kroah-Hartman commit 8b4f68b474488f93f405ba681515bee49cbe99f3 Author: Kefeng Wang Date: Thu Apr 4 15:45:12 2019 +0800 genirq: Initialize request_mutex if CONFIG_SPARSE_IRQ=n commit e8458e7afa855317b14915d7b86ab3caceea7eb6 upstream. When CONFIG_SPARSE_IRQ is disable, the request_mutex in struct irq_desc is not initialized which causes malfunction. Fixes: 9114014cf4e6 ("genirq: Add mutex to irq desc to serialize request/free_irq()") Signed-off-by: Kefeng Wang Signed-off-by: Thomas Gleixner Reviewed-by: Mukesh Ojha Cc: Marc Zyngier Cc: Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190404074512.145533-1-wangkefeng.wang@huawei.com Signed-off-by: Greg Kroah-Hartman commit cd5b06a939970c46ee74f2fee84b296134397e2b Author: Stephen Boyd Date: Mon Mar 25 11:10:26 2019 -0700 genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent() commit 325aa19598e410672175ed50982f902d4e3f31c5 upstream. If a child irqchip calls irq_chip_set_wake_parent() but its parent irqchip has the IRQCHIP_SKIP_SET_WAKE flag set an error is returned. This is inconsistent behaviour vs. set_irq_wake_real() which returns 0 when the irqchip has the IRQCHIP_SKIP_SET_WAKE flag set. It doesn't attempt to walk the chain of parents and set irq wake on any chips that don't have the flag set either. If the intent is to call the .irq_set_wake() callback of the parent irqchip, then we expect irqchip implementations to omit the IRQCHIP_SKIP_SET_WAKE flag and implement an .irq_set_wake() function that calls irq_chip_set_wake_parent(). The problem has been observed on a Qualcomm sdm845 device where set wake fails on any GPIO interrupts after applying work in progress wakeup irq patches to the GPIO driver. The chain of chips looks like this: QCOM GPIO -> QCOM PDC (SKIP) -> ARM GIC (SKIP) The GPIO controllers parent is the QCOM PDC irqchip which in turn has ARM GIC as parent. The QCOM PDC irqchip has the IRQCHIP_SKIP_SET_WAKE flag set, and so does the grandparent ARM GIC. The GPIO driver doesn't know if the parent needs to set wake or not, so it unconditionally calls irq_chip_set_wake_parent() causing this function to return a failure because the parent irqchip (PDC) doesn't have the .irq_set_wake() callback set. Returning 0 instead makes everything work and irqs from the GPIO controller can be configured for wakeup. Make it consistent by returning 0 (success) from irq_chip_set_wake_parent() when a parent chip has IRQCHIP_SKIP_SET_WAKE set. [ tglx: Massaged changelog ] Fixes: 08b55e2a9208e ("genirq: Add irqchip_set_wake_parent") Signed-off-by: Stephen Boyd Signed-off-by: Thomas Gleixner Acked-by: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org Cc: linux-gpio@vger.kernel.org Cc: Lina Iyer Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190325181026.247796-1-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman commit 543bb48dc48b4b65a51d91c9680afbdb573a9fa7 Author: Jason Yan Date: Fri Apr 12 10:09:16 2019 +0800 block: fix the return errno for direct IO commit a89afe58f1a74aac768a5eb77af95ef4ee15beaa upstream. If the last bio returned is not dio->bio, the status of the bio will not assigned to dio->bio if it is error. This will cause the whole IO status wrong. ksoftirqd/21-117 [021] ..s. 4017.966090: 8,0 C N 4883648 [0] -0 [018] ..s. 4017.970888: 8,0 C WS 4924800 + 1024 [0] -0 [018] ..s. 4017.970909: 8,0 D WS 4935424 + 1024 [] -0 [018] ..s. 4017.970924: 8,0 D WS 4936448 + 321 [] ksoftirqd/21-117 [021] ..s. 4017.995033: 8,0 C R 4883648 + 336 [65475] ksoftirqd/21-117 [021] d.s. 4018.001988: myprobe1: (blkdev_bio_end_io+0x0/0x168) bi_status=7 ksoftirqd/21-117 [021] d.s. 4018.001992: myprobe: (aio_complete_rw+0x0/0x148) x0=0xffff802f2595ad80 res=0x12a000 res2=0x0 We always have to assign bio->bi_status to dio->bio.bi_status because we will only check dio->bio.bi_status when we return the whole IO to the upper layer. Fixes: 542ff7bf18c6 ("block: new direct I/O implementation") Cc: stable@vger.kernel.org Cc: Christoph Hellwig Cc: Jens Axboe Reviewed-by: Ming Lei Signed-off-by: Jason Yan Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2591bfc682822ad35d78aa547797efad575d3bb4 Author: Jérôme Glisse Date: Wed Apr 10 16:27:51 2019 -0400 block: do not leak memory in bio_copy_user_iov() commit a3761c3c91209b58b6f33bf69dd8bb8ec0c9d925 upstream. When bio_add_pc_page() fails in bio_copy_user_iov() we should free the page we just allocated otherwise we are leaking it. Cc: linux-block@vger.kernel.org Cc: Linus Torvalds Cc: stable@vger.kernel.org Reviewed-by: Chaitanya Kulkarni Signed-off-by: Jérôme Glisse Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7af20b60f6dba0df784c19d5669a86fdc43eae1f Author: Dmitry V. Levin Date: Fri Mar 29 20:12:21 2019 +0300 riscv: Fix syscall_get_arguments() and syscall_set_arguments() commit 10a16997db3d99fc02c026cf2c6e6c670acafab0 upstream. RISC-V syscall arguments are located in orig_a0,a1..a5 fields of struct pt_regs. Due to an off-by-one bug and a bug in pointer arithmetic syscall_get_arguments() was reading s3..s7 fields instead of a1..a5. Likewise, syscall_set_arguments() was writing s3..s7 fields instead of a1..a5. Link: http://lkml.kernel.org/r/20190329171221.GA32456@altlinux.org Fixes: e2c0cdfba7f69 ("RISC-V: User-facing API") Cc: Ingo Molnar Cc: Kees Cook Cc: Andy Lutomirski Cc: Will Drewry Cc: Albert Ou Cc: linux-riscv@lists.infradead.org Cc: stable@vger.kernel.org # v4.15+ Acked-by: Palmer Dabbelt Signed-off-by: Dmitry V. Levin Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 54fb5c9da6cd665ddee9bcc5645b5f428dbfae2c Author: Anand Jain Date: Tue Apr 2 18:07:40 2019 +0800 btrfs: prop: fix vanished compression property after failed set commit 272e5326c7837697882ce3162029ba893059b616 upstream. The compression property resets to NULL, instead of the old value if we fail to set the new compression parameter. $ btrfs prop get /btrfs compression compression=lzo $ btrfs prop set /btrfs compression zli ERROR: failed to set compression for /btrfs: Invalid argument $ btrfs prop get /btrfs compression This is because the compression property ->validate() is successful for 'zli' as the strncmp() used the length passed from the userspace. Fix it by using the expected string length in strncmp(). Fixes: 63541927c8d1 ("Btrfs: add support for inode properties") Fixes: 5c1aab1dd544 ("btrfs: Add zstd support") CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Nikolay Borisov Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit fbfbb996d58ebf5ddd0c2ae36efcb7015dc50e95 Author: Anand Jain Date: Tue Apr 2 18:07:38 2019 +0800 btrfs: prop: fix zstd compression parameter validation commit 50398fde997f6be8faebdb5f38e9c9c467370f51 upstream. We let pass zstd compression parameter even if it is not fully valid. For example: $ btrfs prop set /btrfs compression zst $ btrfs prop get /btrfs compression compression=zst zlib and lzo are fine. Fix it by checking the correct prefix length. Fixes: 5c1aab1dd544 ("btrfs: Add zstd support") CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Nikolay Borisov Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 16515acd5bc33e86985fa93ee1b894815e52cdc5 Author: Filipe Manana Date: Tue Mar 26 10:49:56 2019 +0000 Btrfs: do not allow trimming when a fs is mounted with the nologreplay option commit f35f06c35560a86e841631f0243b83a984dc11a9 upstream. Whan a filesystem is mounted with the nologreplay mount option, which requires it to be mounted in RO mode as well, we can not allow discard on free space inside block groups, because log trees refer to extents that are not pinned in a block group's free space cache (pinning the extents is precisely the first phase of replaying a log tree). So do not allow the fitrim ioctl to do anything when the filesystem is mounted with the nologreplay option, because later it can be mounted RW without that option, which causes log replay to happen and result in either a failure to replay the log trees (leading to a mount failure), a crash or some silent corruption. Reported-by: Darrick J. Wong Fixes: 96da09192cda ("btrfs: Introduce new mount option to disable tree log replay") CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Nikolay Borisov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit e6265e3680224bd473a9a796469920605ee1b049 Author: S.j. Wang Date: Wed Feb 27 06:31:12 2019 +0000 ASoC: fsl_esai: fix channel swap issue when stream starts commit 0ff4e8c61b794a4bf6c854ab071a1abaaa80f358 upstream. There is very low possibility ( < 0.1% ) that channel swap happened in beginning when multi output/input pin is enabled. The issue is that hardware can't send data to correct pin in the beginning with the normal enable flow. This is hardware issue, but there is no errata, the workaround flow is that: Each time playback/recording, firstly clear the xSMA/xSMB, then enable TE/RE, then enable xSMB and xSMA (xSMB must be enabled before xSMA). Which is to use the xSMA as the trigger start register, previously the xCR_TE or xCR_RE is the bit for starting. Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Cc: Reviewed-by: Fabio Estevam Acked-by: Nicolin Chen Signed-off-by: Shengjiu Wang Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 19b0a7f5a0835b86a0aff57fc51ba1fffbe704c1 Author: Guenter Roeck Date: Fri Mar 22 15:39:48 2019 -0700 ASoC: intel: Fix crash at suspend/resume after failed codec registration commit 8f71370f4b02730e8c27faf460af7a3586e24e1f upstream. If codec registration fails after the ASoC Intel SST driver has been probed, the kernel will Oops and crash at suspend/resume. general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 2811 Comm: cat Tainted: G W 4.19.30 #15 Hardware name: GOOGLE Clapper, BIOS Google_Clapper.5216.199.7 08/22/2014 RIP: 0010:snd_soc_suspend+0x5a/0xd21 Code: 03 80 3c 10 00 49 89 d7 74 0b 48 89 df e8 71 72 c4 fe 4c 89 fa 48 8b 03 48 89 45 d0 48 8d 98 a0 01 00 00 48 89 d8 48 c1 e8 03 <8a> 04 10 84 c0 0f 85 85 0c 00 00 80 3b 00 0f 84 6b 0c 00 00 48 8b RSP: 0018:ffff888035407750 EFLAGS: 00010202 RAX: 0000000000000034 RBX: 00000000000001a0 RCX: 0000000000000000 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88805c417098 RBP: ffff8880354077b0 R08: dffffc0000000000 R09: ffffed100b975718 R10: 0000000000000001 R11: ffffffff949ea4a3 R12: 1ffff1100b975746 R13: dffffc0000000000 R14: ffff88805cba4588 R15: dffffc0000000000 FS: 0000794a78e91b80(0000) GS:ffff888068d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007bd5283ccf58 CR3: 000000004b7aa000 CR4: 00000000001006e0 Call Trace: ? dpm_complete+0x67b/0x67b ? i915_gem_suspend+0x14d/0x1ad sst_soc_prepare+0x91/0x1dd ? sst_be_hw_params+0x7e/0x7e dpm_prepare+0x39a/0x88b dpm_suspend_start+0x13/0x9d suspend_devices_and_enter+0x18f/0xbd7 ? arch_suspend_enable_irqs+0x11/0x11 ? printk+0xd9/0x12d ? lock_release+0x95f/0x95f ? log_buf_vmcoreinfo_setup+0x131/0x131 ? rcu_read_lock_sched_held+0x140/0x22a ? __bpf_trace_rcu_utilization+0xa/0xa ? __pm_pr_dbg+0x186/0x190 ? pm_notifier_call_chain+0x39/0x39 ? suspend_test+0x9d/0x9d pm_suspend+0x2f4/0x728 ? trace_suspend_resume+0x3da/0x3da ? lock_release+0x95f/0x95f ? kernfs_fop_write+0x19f/0x32d state_store+0xd8/0x147 ? sysfs_kf_read+0x155/0x155 kernfs_fop_write+0x23e/0x32d __vfs_write+0x108/0x608 ? vfs_read+0x2e9/0x2e9 ? rcu_read_lock_sched_held+0x140/0x22a ? __bpf_trace_rcu_utilization+0xa/0xa ? debug_smp_processor_id+0x10/0x10 ? selinux_file_permission+0x1c5/0x3c8 ? rcu_sync_lockdep_assert+0x6a/0xad ? __sb_start_write+0x129/0x2ac vfs_write+0x1aa/0x434 ksys_write+0xfe/0x1be ? __ia32_sys_read+0x82/0x82 do_syscall_64+0xcd/0x120 entry_SYSCALL_64_after_hwframe+0x49/0xbe In the observed situation, the problem is seen because the codec driver failed to probe due to a hardware problem. max98090 i2c-193C9890:00: Failed to read device revision: -1 max98090 i2c-193C9890:00: ASoC: failed to probe component -1 cht-bsw-max98090 cht-bsw-max98090: ASoC: failed to instantiate card -1 cht-bsw-max98090 cht-bsw-max98090: snd_soc_register_card failed -1 cht-bsw-max98090: probe of cht-bsw-max98090 failed with error -1 The problem is similar to the problem solved with commit 2fc995a87f2e ("ASoC: intel: Fix crash at suspend/resume without card registration"), but codec registration fails at a later point. At that time, the pointer checked with the above mentioned commit is already set, but it is not cleared if the device is subsequently removed. Adding a remove function to clear the pointer fixes the problem. Cc: stable@vger.kernel.org Cc: Jarkko Nikula Cc: Curtis Malainey Signed-off-by: Guenter Roeck Acked-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 43f47331a4ce7c335582d9300f62ad583e07d707 Author: Greg Thelen Date: Fri Apr 5 18:39:18 2019 -0700 mm: writeback: use exact memcg dirty counts commit 0b3d6e6f2dd0a7b697b1aa8c167265908940624b upstream. Since commit a983b5ebee57 ("mm: memcontrol: fix excessive complexity in memory.stat reporting") memcg dirty and writeback counters are managed as: 1) per-memcg per-cpu values in range of [-32..32] 2) per-memcg atomic counter When a per-cpu counter cannot fit in [-32..32] it's flushed to the atomic. Stat readers only check the atomic. Thus readers such as balance_dirty_pages() may see a nontrivial error margin: 32 pages per cpu. Assuming 100 cpus: 4k x86 page_size: 13 MiB error per memcg 64k ppc page_size: 200 MiB error per memcg Considering that dirty+writeback are used together for some decisions the errors double. This inaccuracy can lead to undeserved oom kills. One nasty case is when all per-cpu counters hold positive values offsetting an atomic negative value (i.e. per_cpu[*]=32, atomic=n_cpu*-32). balance_dirty_pages() only consults the atomic and does not consider throttling the next n_cpu*32 dirty pages. If the file_lru is in the 13..200 MiB range then there's absolutely no dirty throttling, which burdens vmscan with only dirty+writeback pages thus resorting to oom kill. It could be argued that tiny containers are not supported, but it's more subtle. It's the amount the space available for file lru that matters. If a container has memory.max-200MiB of non reclaimable memory, then it will also suffer such oom kills on a 100 cpu machine. The following test reliably ooms without this patch. This patch avoids oom kills. $ cat test mount -t cgroup2 none /dev/cgroup cd /dev/cgroup echo +io +memory > cgroup.subtree_control mkdir test cd test echo 10M > memory.max (echo $BASHPID > cgroup.procs && exec /memcg-writeback-stress /foo) (echo $BASHPID > cgroup.procs && exec dd if=/dev/zero of=/foo bs=2M count=100) $ cat memcg-writeback-stress.c /* * Dirty pages from all but one cpu. * Clean pages from the non dirtying cpu. * This is to stress per cpu counter imbalance. * On a 100 cpu machine: * - per memcg per cpu dirty count is 32 pages for each of 99 cpus * - per memcg atomic is -99*32 pages * - thus the complete dirty limit: sum of all counters 0 * - balance_dirty_pages() only sees atomic count -99*32 pages, which * it max()s to 0. * - So a workload can dirty -99*32 pages before balance_dirty_pages() * cares. */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include static char *buf; static int bufSize; static void set_affinity(int cpu) { cpu_set_t affinity; CPU_ZERO(&affinity); CPU_SET(cpu, &affinity); if (sched_setaffinity(0, sizeof(affinity), &affinity)) err(1, "sched_setaffinity"); } static void dirty_on(int output_fd, int cpu) { int i, wrote; set_affinity(cpu); for (i = 0; i < 32; i++) { for (wrote = 0; wrote < bufSize; ) { int ret = write(output_fd, buf+wrote, bufSize-wrote); if (ret == -1) err(1, "write"); wrote += ret; } } } int main(int argc, char **argv) { int cpu, flush_cpu = 1, output_fd; const char *output; if (argc != 2) errx(1, "usage: output_file"); output = argv[1]; bufSize = getpagesize(); buf = malloc(getpagesize()); if (buf == NULL) errx(1, "malloc failed"); output_fd = open(output, O_CREAT|O_RDWR); if (output_fd == -1) err(1, "open(%s)", output); for (cpu = 0; cpu < get_nprocs(); cpu++) { if (cpu != flush_cpu) dirty_on(output_fd, cpu); } set_affinity(flush_cpu); if (fsync(output_fd)) err(1, "fsync(%s)", output); if (close(output_fd)) err(1, "close(%s)", output); free(buf); } Make balance_dirty_pages() and wb_over_bg_thresh() work harder to collect exact per memcg counters. This avoids the aforementioned oom kills. This does not affect the overhead of memory.stat, which still reads the single atomic counter. Why not use percpu_counter? memcg already handles cpus going offline, so no need for that overhead from percpu_counter. And the percpu_counter spinlocks are more heavyweight than is required. It probably also makes sense to use exact dirty and writeback counters in memcg oom reports. But that is saved for later. Link: http://lkml.kernel.org/r/20190329174609.164344-1-gthelen@google.com Signed-off-by: Greg Thelen Reviewed-by: Roman Gushchin Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Tejun Heo Cc: [4.16+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 576f22ac47ba3d5cd8474bfee51cb821aeeb3b92 Author: Arnd Bergmann Date: Fri Apr 5 18:38:53 2019 -0700 include/linux/bitrev.h: fix constant bitrev commit 6147e136ff5071609b54f18982dea87706288e21 upstream. clang points out with hundreds of warnings that the bitrev macros have a problem with constant input: drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized when used within its own initialization [-Werror,-Wuninitialized] u8 crc = bitrev8(data->val_status & 0x0F); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8' __constant_bitrev8(__x) : \ ~~~~~~~~~~~~~~~~~~~^~~~ include/linux/bitrev.h:67:11: note: expanded from macro '__constant_bitrev8' u8 __x = x; \ ~~~ ^ Both the bitrev and the __constant_bitrev macros use an internal variable named __x, which goes horribly wrong when passing one to the other. The obvious fix is to rename one of the variables, so this adds an extra '_'. It seems we got away with this because - there are only a few drivers using bitrev macros - usually there are no constant arguments to those - when they are constant, they tend to be either 0 or (unsigned)-1 (drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and give the correct result by pure chance. In fact, the only driver that I could find that gets different results with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver for fairly rare hardware (adding the maintainer to Cc for testing). Link: http://lkml.kernel.org/r/20190322140503.123580-1-arnd@arndb.de Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction") Signed-off-by: Arnd Bergmann Reviewed-by: Nick Desaulniers Cc: Zhao Qiang Cc: Yalin Wang Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c4f103f6ac3a0ede5ec8da465db767604e647968 Author: David Rientjes Date: Tue Mar 19 15:19:56 2019 -0700 kvm: svm: fix potential get_num_contig_pages overflow commit ede885ecb2cdf8a8dd5367702e3d964ec846a2d5 upstream. get_num_contig_pages() could potentially overflow int so make its type consistent with its usage. Reported-by: Cfir Cohen Cc: stable@vger.kernel.org Signed-off-by: David Rientjes Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 93d60348edcbaa3ea039ba1a5913914077c175ab Author: Dave Airlie Date: Fri Apr 5 13:17:13 2019 +1000 drm/udl: add a release method and delay modeset teardown commit 9b39b013037fbfa8d4b999345d9e904d8a336fc2 upstream. If we unplug a udl device, the usb callback with deinit the mode_config struct, however userspace will still have an open file descriptor and a framebuffer on that device. When userspace closes the fd, we'll oops because it'll try and look stuff up in the object idr which we've destroyed. This punts destroying the mode objects until release time instead. Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-2-airlied@gmail.com Signed-off-by: Greg Kroah-Hartman commit df4106f23d0b2eecd13fb89784f7cbba070d2b1c Author: Yan Zhao Date: Wed Mar 27 00:54:51 2019 -0400 drm/i915/gvt: do not deliver a workload if its creation fails commit dade58ed5af6365ac50ff4259c2a0bf31219e285 upstream. in workload creation routine, if any failure occurs, do not queue this workload for delivery. if this failure is fatal, enter into failsafe mode. Fixes: 6d76303553ba ("drm/i915/gvt: Move common vGPU workload creation into scheduler.c") Cc: stable@vger.kernel.org #4.19+ Cc: zhenyuw@linux.intel.com Signed-off-by: Yan Zhao Signed-off-by: Zhenyu Wang Signed-off-by: Greg Kroah-Hartman commit a5277bcc1b7d2d06da310503fc6afc9189ae4875 Author: Andrei Vagin Date: Sun Apr 7 21:15:42 2019 -0700 alarmtimer: Return correct remaining time commit 07d7e12091f4ab869cc6a4bb276399057e73b0b3 upstream. To calculate a remaining time, it's required to subtract the current time from the expiration time. In alarm_timer_remaining() the arguments of ktime_sub are swapped. Fixes: d653d8457c76 ("alarmtimer: Implement remaining callback") Signed-off-by: Andrei Vagin Signed-off-by: Thomas Gleixner Reviewed-by: Mukesh Ojha Cc: Stephen Boyd Cc: John Stultz Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190408041542.26338-1-avagin@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5db86e2a9b364b06e8a7b7f4f73f1339cf2436f6 Author: Sven Schnelle Date: Thu Apr 4 18:16:04 2019 +0200 parisc: also set iaoq_b in instruction_pointer_set() commit f324fa58327791b2696628b31480e7e21c745706 upstream. When setting the instruction pointer on PA-RISC we also need to set the back of the instruction queue to the new offset, otherwise we will execute on instruction from the new location, and jumping back to the old location stored in iaoq_b. Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller Fixes: 75ebedf1d263 ("parisc: Add HAVE_REGS_AND_STACK_ACCESS_API feature") Cc: stable@vger.kernel.org # 4.19+ Signed-off-by: Greg Kroah-Hartman commit 53bb8444eab276a9405cefaed4d8351cb6cc4fba Author: Sven Schnelle Date: Thu Apr 4 18:16:03 2019 +0200 parisc: regs_return_value() should return gpr28 commit 45efd871bf0a47648f119d1b41467f70484de5bc upstream. While working on kretprobes for PA-RISC I was wondering while the kprobes sanity test always fails on kretprobes. This is caused by returning gpr20 instead of gpr28. Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller Cc: stable@vger.kernel.org # 4.14+ Signed-off-by: Greg Kroah-Hartman commit 41cf8111f3cbbc2be3a9f6e2b2e004b76a5784f0 Author: Helge Deller Date: Tue Apr 2 12:13:27 2019 +0200 parisc: Detect QEMU earlier in boot process commit d006e95b5561f708d0385e9677ffe2c46f2ae345 upstream. While adding LASI support to QEMU, I noticed that the QEMU detection in the kernel happens much too late. For example, when a LASI chip is found by the kernel, it registers the LASI LED driver as well. But when we run on QEMU it makes sense to avoid spending unnecessary CPU cycles, so we need to access the running_on_QEMU flag earlier than before. This patch now makes the QEMU detection the fist task of the Linux kernel by moving it to where the kernel enters the C-coding. Fixes: 310d82784fb4 ("parisc: qemu idle sleep support") Signed-off-by: Helge Deller Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Greg Kroah-Hartman commit ba5765a243ed004172dd1cd8174888c8eefec04c Author: Peter Geis Date: Wed Mar 13 19:02:30 2019 +0000 arm64: dts: rockchip: fix rk3328 sdmmc0 write errors commit 09f91381fa5de1d44bc323d8bf345f5d57b3d9b5 upstream. Various rk3328 based boards experience occasional sdmmc0 write errors. This is due to the rk3328.dtsi tx drive levels being set to 4ma, vs 8ma per the rk3328 datasheet default settings. Fix this by setting the tx signal pins to 8ma. Inspiration from tonymac32's patch, https://github.com/ayufan-rock64/linux-kernel/commit/dc1212b347e0da17c5460bcc0a56b07d02bac3f8 Fixes issues on the rk3328-roc-cc and the rk3328-rock64 (as per the above commit message). Tested on the rk3328-roc-cc board. Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs") Cc: stable@vger.kernel.org Signed-off-by: Peter Geis Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 9a62d69114d73e706fc03420314d8e9622cd580a Author: Aneesh Kumar K.V Date: Fri Apr 5 18:39:10 2019 -0700 mm/huge_memory.c: fix modifying of page protection by insert_pfn_pmd() commit c6f3c5ee40c10bb65725047a220570f718507001 upstream. With some architectures like ppc64, set_pmd_at() cannot cope with a situation where there is already some (different) valid entry present. Use pmdp_set_access_flags() instead to modify the pfn which is built to deal with modifying existing PMD entries. This is similar to commit cae85cb8add3 ("mm/memory.c: fix modifying of page protection by insert_pfn()") We also do similar update w.r.t insert_pfn_pud eventhough ppc64 don't support pud pfn entries now. Without this patch we also see the below message in kernel log "BUG: non-zero pgtables_bytes on freeing mm:" Link: http://lkml.kernel.org/r/20190402115125.18803-1-aneesh.kumar@linux.ibm.com Signed-off-by: Aneesh Kumar K.V Reported-by: Chandan Rajendra Reviewed-by: Jan Kara Cc: Dan Williams Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b3a8a3728d7e88c11aec68322223a26636afc86f Author: Hui Wang Date: Mon Apr 8 15:58:11 2019 +0800 ALSA: hda - Add two more machines to the power_save_blacklist commit cae30527901d9590db0e12ace994c1d58bea87fd upstream. Recently we set CONFIG_SND_HDA_POWER_SAVE_DEFAULT to 1 when configuring the kernel, then two machines were reported to have noise after installing the new kernel. Put them in the blacklist, the noise disappears. https://bugs.launchpad.net/bugs/1821663 Cc: Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bfea74941d6d32b94913d946bdf27d2c27d0bf5d Author: Richard Sailer Date: Tue Apr 2 15:52:04 2019 +0200 ALSA: hda/realtek - Add quirk for Tuxedo XC 1509 commit 80690a276f444a68a332136d98bfea1c338bc263 upstream. This adds a SND_PCI_QUIRK(...) line for the Tuxedo XC 1509. The Tuxedo XC 1509 and the System76 oryp5 are the same barebone notebooks manufactured by Clevo. To name the fixups both use after the actual underlying hardware, this patch also changes System76_orpy5 to clevo_pb51ed in 2 enum symbols and one function name, matching the other pci_quirk entries which are also named after the device ODM. Fixes: 7f665b1c3283 ("ALSA: hda/realtek - Headset microphone and internal speaker support for System76 oryp5") Signed-off-by: Richard Sailer Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c6d25f0b3653814c4c0e341336d97fb52a0a8cd6 Author: Jian-Hong Pan Date: Mon Apr 1 11:25:05 2019 +0800 ALSA: hda/realtek: Enable headset MIC of Acer TravelMate B114-21 with ALC233 commit ea5c7eba216e832906e594799b8670f1954a588c upstream. The Acer TravelMate B114-21 laptop cannot detect and record sound from headset MIC. This patch adds the ALC233_FIXUP_ACER_HEADSET_MIC HDA verb quirk chained with ALC233_FIXUP_ASUS_MIC_NO_PRESENCE pin quirk to fix this issue. [ fixed the missing brace and reordered the entry -- tiwai ] Signed-off-by: Jian-Hong Pan Signed-off-by: Daniel Drake Reviewed-by: Kailang Yang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 73b50a56e51edcd78ef7602afe75083d640548e8 Author: Zubin Mithra Date: Thu Apr 4 14:33:55 2019 -0700 ALSA: seq: Fix OOB-reads from strlcpy commit 212ac181c158c09038c474ba68068be49caecebb upstream. When ioctl calls are made with non-null-terminated userspace strings, strlcpy causes an OOB-read from within strlen. Fix by changing to use strscpy instead. Signed-off-by: Zubin Mithra Reviewed-by: Guenter Roeck Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d4b4aeea5506349a68adc9d2c372c8fa2416d790 Author: Erik Schmauss Date: Mon Apr 8 13:42:26 2019 -0700 ACPICA: Namespace: remove address node from global list after method termination commit c5781ffbbd4f742a58263458145fe7f0ac01d9e0 upstream. ACPICA commit b233720031a480abd438f2e9c643080929d144c3 ASL operation_regions declare a range of addresses that it uses. In a perfect world, the range of addresses should be used exclusively by the AML interpreter. The OS can use this information to decide which drivers to load so that the AML interpreter and device drivers use different regions of memory. During table load, the address information is added to a global address range list. Each node in this list contains an address range as well as a namespace node of the operation_region. This list is deleted at ACPI shutdown. Unfortunately, ASL operation_regions can be declared inside of control methods. Although this is not recommended, modern firmware contains such code. New module level code changes unintentionally removed the functionality of adding and removing nodes to the global address range list. A few months ago, support for adding addresses has been re- implemented. However, the removal of the address range list was missed and resulted in some systems to crash due to the address list containing bogus namespace nodes from operation_regions declared in control methods. In order to fix the crash, this change removes dynamic operation_regions after control method termination. Link: https://github.com/acpica/acpica/commit/b2337200 Link: https://bugzilla.kernel.org/show_bug.cgi?id=202475 Fixes: 4abb951b73ff ("ACPICA: AML interpreter: add region addresses in global list during initialization") Reported-by: Michael J Gruber Signed-off-by: Erik Schmauss Signed-off-by: Bob Moore Cc: 4.20+ # 4.20+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ed52b07bd698513edb66704aa09caa4d737348c1 Author: Furquan Shaikh Date: Wed Mar 20 15:28:44 2019 -0700 ACPICA: Clear status of GPEs before enabling them commit c8b1917c8987a6fa3695d479b4d60fbbbc3e537b upstream. Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume") was added to stop clearing event status bits unconditionally in the system-wide suspend and resume paths. This was done because of an issue with a laptop lid appaering to be closed even when it was used to wake up the system from suspend (see https://bugzilla.kernel.org/show_bug.cgi?id=196249), which happened because event status bits were cleared unconditionally on system resume. Though this change fixed the issue in the resume path, it introduced regressions in a few suspend paths. First regression was reported and fixed in the S5 entry path by commit fa85015c0d95 ("ACPICA: Clear status of all events when entering S5"). Next regression was reported and fixed for all legacy sleep paths by commit f317c7dc12b7 ("ACPICA: Clear status of all events when entering sleep states"). However, there still is a suspend-to-idle regression, since suspend-to-idle does not follow the legacy sleep paths. In the suspend-to-idle case, wakeup is enabled as part of device suspend. If the status bits of wakeup GPEs are set when they are enabled, it causes a premature system wakeup to occur. To address that problem, partially revert commit 18996f2db918 to restore GPE status bits clearing before the GPE is enabled in acpi_ev_enable_gpe(). Fixes: 18996f2db918 ("ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume") Signed-off-by: Furquan Shaikh Cc: 4.17+ # 4.17+ [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 370004024aec354bcab509bb506b939cf43b4265 Author: Axel Lin Date: Mon Mar 11 17:57:30 2019 +0800 hwmon: (w83773g) Select REGMAP_I2C to fix build error commit a165dcc923ada2ffdee1d4f41f12f81b66d04c55 upstream. Select REGMAP_I2C to avoid below build error: ERROR: "__devm_regmap_init_i2c" [drivers/hwmon/w83773g.ko] undefined! Fixes: ee249f271524 ("hwmon: Add W83773G driver") Cc: stable@vger.kernel.org Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4ebab60d6561f992949bdab2a213c1cac8472a6b Author: Greg Kroah-Hartman Date: Mon Jan 21 17:26:42 2019 +0100 tty: ldisc: add sysctl to prevent autoloading of ldiscs commit 7c0cca7c847e6e019d67b7d793efbbe3b947d004 upstream. By default, the kernel will automatically load the module of any line dicipline that is asked for. As this sometimes isn't the safest thing to do, provide a sysctl to disable this feature. By default, we set this to 'y' as that is the historical way that Linux has worked, and we do not want to break working systems. But in the future, perhaps this can default to 'n' to prevent this functionality. Signed-off-by: Greg Kroah-Hartman Reviewed-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 894dc8495898cf6075eadf99fd496374decd3986 Author: Greg Kroah-Hartman Date: Fri Apr 5 15:39:26 2019 +0200 tty: mark Siemens R3964 line discipline as BROKEN commit c7084edc3f6d67750f50d4183134c4fb5712a5c8 upstream. The n_r3964 line discipline driver was written in a different time, when SMP machines were rare, and users were trusted to do the right thing. Since then, the world has moved on but not this code, it has stayed rooted in the past with its lovely hand-crafted list structures and loads of "interesting" race conditions all over the place. After attempting to clean up most of the issues, I just gave up and am now marking the driver as BROKEN so that hopefully someone who has this hardware will show up out of the woodwork (I know you are out there!) and will help with debugging a raft of changes that I had laying around for the code, but was too afraid to commit as odds are they would break things. Many thanks to Jann and Linus for pointing out the initial problems in this codebase, as well as many reviews of my attempts to fix the issues. It was a case of whack-a-mole, and as you can see, the mole won. Reported-by: Jann Horn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds commit 902eaef7781cef521dba7e0299b24e5f4b78b688 Author: Yueyi Li Date: Mon Dec 24 07:40:07 2018 +0000 arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region [ Upstream commit c8a43c18a97845e7f94ed7d181c11f41964976a2 ] When KASLR is enabled (CONFIG_RANDOMIZE_BASE=y), the top 4K of kernel virtual address space may be mapped to physical addresses despite being reserved for ERR_PTR values. Fix the randomization of the linear region so that we avoid mapping the last page of the virtual address space. Cc: Ard Biesheuvel Signed-off-by: liyueyi [will: rewrote commit message; merged in suggestion from Ard] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin (Microsoft) commit 40177a7931e0043f9f5016e370c0695e4bae6b19 Author: Florian Westphal Date: Fri Apr 12 10:55:03 2019 -0700 netfilter: nfnetlink_cttimeout: fetch timeouts for udplite and gre, too commit 89259088c1b7fecb43e8e245dc931909132a4e03 upstream syzbot was able to trigger the WARN in cttimeout_default_get() by passing UDPLITE as l4protocol. Alias UDPLITE to UDP, both use same timeout values. Furthermore, also fetch GRE timeouts. GRE is a bit more complicated, as it still can be a module and its netns_proto_gre struct layout isn't visible outside of the gre module. Can't move timeouts around, it appears conntrack sysctl unregister assumes net_generic() returns nf_proto_net, so we get crash. Expose layout of netns_proto_gre instead. A followup nf-next patch could make gre tracker be built-in as well if needed, its not that large. Last, make the WARN() mention the missing protocol value in case anything else is missing. Reported-by: syzbot+2fae8fa157dd92618cae@syzkaller.appspotmail.com Fixes: 8866df9264a3 ("netfilter: nfnetlink_cttimeout: pass default timeout policy to obj_to_nlattr") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Zubin Mithra Signed-off-by: Sasha Levin (Microsoft) commit c2d27b330a983d176311c1368037baa315fa0fd6 Author: Pablo Neira Ayuso Date: Fri Apr 12 10:55:02 2019 -0700 netfilter: nfnetlink_cttimeout: pass default timeout policy to obj_to_nlattr commit 8866df9264a34e675b4ee8a151db819b87cce2d3 upstream Otherwise, we hit a NULL pointer deference since handlers always assume default timeout policy is passed. netlink: 24 bytes leftover after parsing attributes in process `syz-executor2'. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 9575 Comm: syz-executor1 Not tainted 4.19.0+ #312 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:icmp_timeout_obj_to_nlattr+0x77/0x170 net/netfilter/nf_conntrack_proto_icmp.c:297 Fixes: c779e849608a ("netfilter: conntrack: remove get_timeout() indirection") Reported-by: Eric Dumazet Signed-off-by: Pablo Neira Ayuso Signed-off-by: Zubin Mithra Signed-off-by: Sasha Levin (Microsoft) commit 564f0391b7834528a6b96d0ad0b6c70683e9b37f Author: Neil Armstrong Date: Thu Apr 11 12:11:22 2019 +0200 Revert "clk: meson: clean-up clock registration" This reverts commit c8e4f8406842332fb55cd792016e5dac266f6354. This patch was not initially a fix and is dependent on other changes which are not fixes eithers. With this change, multiple Amlogic based boards fails to boot, as reported by kernelci. Cc: stable@vger.kernel.org # 4.19.34 Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 3412671a781bf47b7b38c9f08b0bc7d2b8dec923 Author: Nick Desaulniers Date: Fri Apr 5 18:38:45 2019 -0700 lib/string.c: implement a basic bcmp [ Upstream commit 5f074f3e192f10c9fade898b9b3b8812e3d83342 ] A recent optimization in Clang (r355672) lowers comparisons of the return value of memcmp against zero to comparisons of the return value of bcmp against zero. This helps some platforms that implement bcmp more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but an optimized implementation is in the works. This results in linkage failures for all targets with Clang due to the undefined symbol. For now, just implement bcmp as a tailcail to memcmp to unbreak the build. This routine can be further optimized in the future. Other ideas discussed: * A weak alias was discussed, but breaks for architectures that define their own implementations of memcmp since aliases to declarations are not permitted (only definitions). Arch-specific memcmp implementations typically declare memcmp in C headers, but implement them in assembly. * -ffreestanding also is used sporadically throughout the kernel. * -fno-builtin-bcmp doesn't work when doing LTO. Link: https://bugs.llvm.org/show_bug.cgi?id=41035 Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp Link: https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13 Link: https://github.com/ClangBuiltLinux/linux/issues/416 Link: http://lkml.kernel.org/r/20190313211335.165605-1-ndesaulniers@google.com Signed-off-by: Nick Desaulniers Reported-by: Nathan Chancellor Reported-by: Adhemerval Zanella Suggested-by: Arnd Bergmann Suggested-by: James Y Knight Suggested-by: Masahiro Yamada Suggested-by: Nathan Chancellor Suggested-by: Rasmus Villemoes Acked-by: Steven Rostedt (VMware) Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Reviewed-by: Masahiro Yamada Reviewed-by: Andy Shevchenko Cc: David Laight Cc: Rasmus Villemoes Cc: Namhyung Kim Cc: Greg Kroah-Hartman Cc: Alexander Shishkin Cc: Dan Williams Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c7415f2a3ad65d78c13b203364c843347a443254 Author: Nick Desaulniers Date: Thu Dec 6 11:12:31 2018 -0800 x86/vdso: Drop implicit common-page-size linker flag commit ac3e233d29f7f77f28243af0132057d378d3ea58 upstream. GNU linker's -z common-page-size's default value is based on the target architecture. arch/x86/entry/vdso/Makefile sets it to the architecture default, which is implicit and redundant. Drop it. Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu") Reported-by: Dmitry Golovin Reported-by: Bill Wendling Suggested-by: Dmitry Golovin Suggested-by: Rui Ueyama Signed-off-by: Nick Desaulniers Signed-off-by: Borislav Petkov Acked-by: Andy Lutomirski Cc: Andi Kleen Cc: Fangrui Song Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulniers@google.com Link: https://bugs.llvm.org/show_bug.cgi?id=38774 Link: https://github.com/ClangBuiltLinux/linux/issues/31 Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit f66a52d991de7ca6c6dc7db768b50e6a28916d1f Author: Nick Desaulniers Date: Mon Feb 11 11:30:04 2019 -0800 kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD commit ad15006cc78459d059af56729c4d9bed7c7fd860 upstream. This causes an issue when trying to build with `make LD=ld.lld` if ld.lld and the rest of your cross tools aren't in the same directory (ex. /usr/local/bin) (as is the case for Android's build system), as the GCC_TOOLCHAIN_DIR then gets set based on `which $(LD)` which will point where LLVM tools are, not GCC/binutils tools are located. Instead, select the GCC_TOOLCHAIN_DIR based on another tool provided by binutils for which LLVM does not provide a substitute for, such as elfedit. Fixes: 785f11aa595b ("kbuild: Add better clang cross build support") Link: https://github.com/ClangBuiltLinux/linux/issues/341 Suggested-by: Nathan Chancellor Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 23605a4664ae8658ddbbbac4f75c404eb7e4715d Author: Masahiro Yamada Date: Mon Nov 5 16:52:34 2018 +0900 kbuild: deb-pkg: fix bindeb-pkg breakage when O= is used [ Upstream commit 02826a6ba301b72461c3706e1cc66d5571cd327e ] Ard Biesheuvel reports bindeb-pkg with O= option is broken in the following way: ... LD [M] sound/soc/rockchip/snd-soc-rk3399-gru-sound.ko LD [M] sound/soc/rockchip/snd-soc-rockchip-pcm.ko LD [M] sound/soc/rockchip/snd-soc-rockchip-rt5645.ko LD [M] sound/soc/rockchip/snd-soc-rockchip-spdif.ko LD [M] sound/soc/sh/rcar/snd-soc-rcar.ko fakeroot -u debian/rules binary make KERNELRELEASE=4.19.0-12677-g19beffaf7a99-dirty ARCH=arm64 KBUILD_SRC= intdeb-pkg /bin/bash /home/ard/linux/scripts/package/builddeb Makefile:600: include/config/auto.conf: No such file or directory *** *** Configuration file ".config" not found! *** *** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig"). *** make[12]: *** [syncconfig] Error 1 make[11]: *** [syncconfig] Error 2 make[10]: *** [include/config/auto.conf] Error 2 make[9]: *** [__sub-make] Error 2 ... Prior to commit 80463f1b7bf9 ("kbuild: add --include-dir flag only for out-of-tree build"), both srctree and objtree were added to --include-dir redundantly, and the wrong code '$MAKE image_name' was working by relying on that. Now, the potential issue that had previously been hidden just showed up. '$MAKE image_name' recurses to the generated $(objtree)/Makefile and ends up with running in srctree, which is incorrect. It should be invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed in objtree. Fixes: 80463f1b7bf9 ("kbuild: add --include-dir flag only for out-of-tree build") Reported-by: Ard Biesheuvel Signed-off-by: Masahiro Yamada Tested-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit da9b353c78b8cb18de6f9f38948e6ffc1ec460c7 Author: Huy Nguyen Date: Thu Mar 7 14:07:32 2019 -0600 net/mlx5e: Update xon formula [ Upstream commit e28408e98bced123038857b6e3c81fa12a2e3e68 ] Set xon = xoff - netdev's max_mtu. netdev's max_mtu will give enough time for the pause frame to arrive at the sender. Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration") Signed-off-by: Huy Nguyen Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit e2d92a74a353b055e12414583d06da441a7262a1 Author: Huy Nguyen Date: Thu Mar 7 14:49:50 2019 -0600 net/mlx5e: Update xoff formula [ Upstream commit 5ec983e924c7978aaec3cf8679ece9436508bb20 ] Set minimum speed in xoff threshold formula to 40Gbps Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration") Signed-off-by: Huy Nguyen Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit eab86503fec0e8a5767fa574ed73b3212bf90b1b Author: Aditya Pakki Date: Tue Mar 19 16:42:40 2019 -0500 net: mlx5: Add a missing check on idr_find, free buf [ Upstream commit 8e949363f017e2011464812a714fb29710fb95b4 ] idr_find() can return a NULL value to 'flow' which is used without a check. The patch adds a check to avoid potential NULL pointer dereference. In case of mlx5_fpga_sbu_conn_sendmsg() failure, free buf allocated using kzalloc. Fixes: ab412e1dd7db ("net/mlx5: Accel, add TLS rx offload routines") Signed-off-by: Aditya Pakki Reviewed-by: Yuval Shaia Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit b787544dc5e707fec86161b881391eb9342806e6 Author: Heiner Kallweit Date: Sat Mar 30 17:13:24 2019 +0100 r8169: disable default rx interrupt coalescing on RTL8168 [ Upstream commit 288ac524cf70a8e7ed851a61ed2a9744039dae8d ] It was reported that re-introducing ASPM, in combination with RX interrupt coalescing, results in significantly increased packet latency, see [0]. Disabling ASPM or RX interrupt coalescing fixes the issue. Therefore change the driver's default to disable RX interrupt coalescing. Users still have the option to enable RX coalescing via ethtool. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925496 Fixes: a99790bf5c7f ("r8169: Reinstate ASPM Support") Reported-by: Mike Crowe Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 55a7f7b20c409d89bfc0af83de50737fd126f7a4 Author: Alexander Lobakin Date: Thu Mar 28 18:23:04 2019 +0300 net: core: netif_receive_skb_list: unlist skb before passing to pt->func [ Upstream commit 9a5a90d167b0e5fe3d47af16b68fd09ce64085cd ] __netif_receive_skb_list_ptype() leaves skb->next poisoned before passing it to pt_prev->func handler, what may produce (in certain cases, e.g. DSA setup) crashes like: [ 88.606777] CPU 0 Unable to handle kernel paging request at virtual address 0000000e, epc == 80687078, ra == 8052cc7c [ 88.618666] Oops[#1]: [ 88.621196] CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.0-rc2-dlink-00206-g4192a172-dirty #1473 [ 88.630885] $ 0 : 00000000 10000400 00000002 864d7850 [ 88.636709] $ 4 : 87c0ddf0 864d7800 87c0ddf0 00000000 [ 88.642526] $ 8 : 00000000 49600000 00000001 00000001 [ 88.648342] $12 : 00000000 c288617b dadbee27 25d17c41 [ 88.654159] $16 : 87c0ddf0 85cff080 80790000 fffffffd [ 88.659975] $20 : 80797b20 ffffffff 00000001 864d7800 [ 88.665793] $24 : 00000000 8011e658 [ 88.671609] $28 : 80790000 87c0dbc0 87cabf00 8052cc7c [ 88.677427] Hi : 00000003 [ 88.680622] Lo : 7b5b4220 [ 88.683840] epc : 80687078 vlan_dev_hard_start_xmit+0x1c/0x1a0 [ 88.690532] ra : 8052cc7c dev_hard_start_xmit+0xac/0x188 [ 88.696734] Status: 10000404 IEp [ 88.700422] Cause : 50000008 (ExcCode 02) [ 88.704874] BadVA : 0000000e [ 88.708069] PrId : 0001a120 (MIPS interAptiv (multi)) [ 88.713005] Modules linked in: [ 88.716407] Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=00000000) [ 88.725219] Stack : 85f61c28 00000000 0000000e 80780000 87c0ddf0 85cff080 80790000 8052cc7c [ 88.734529] 87cabf00 00000000 00000001 85f5fb40 807b0000 864d7850 87cabf00 807d0000 [ 88.743839] 864d7800 8655f600 00000000 85cff080 87c1c000 0000006a 00000000 8052d96c [ 88.753149] 807a0000 8057adb8 87c0dcc8 87c0dc50 85cfff08 00000558 87cabf00 85f58c50 [ 88.762460] 00000002 85f58c00 864d7800 80543308 fffffff4 00000001 85f58c00 864d7800 [ 88.771770] ... [ 88.774483] Call Trace: [ 88.777199] [<80687078>] vlan_dev_hard_start_xmit+0x1c/0x1a0 [ 88.783504] [<8052cc7c>] dev_hard_start_xmit+0xac/0x188 [ 88.789326] [<8052d96c>] __dev_queue_xmit+0x6e8/0x7d4 [ 88.794955] [<805a8640>] ip_finish_output2+0x238/0x4d0 [ 88.800677] [<805ab6a0>] ip_output+0xc8/0x140 [ 88.805526] [<805a68f4>] ip_forward+0x364/0x560 [ 88.810567] [<805a4ff8>] ip_rcv+0x48/0xe4 [ 88.815030] [<80528d44>] __netif_receive_skb_one_core+0x44/0x58 [ 88.821635] [<8067f220>] dsa_switch_rcv+0x108/0x1ac [ 88.827067] [<80528f80>] __netif_receive_skb_list_core+0x228/0x26c [ 88.833951] [<8052ed84>] netif_receive_skb_list+0x1d4/0x394 [ 88.840160] [<80355a88>] lunar_rx_poll+0x38c/0x828 [ 88.845496] [<8052fa78>] net_rx_action+0x14c/0x3cc [ 88.850835] [<806ad300>] __do_softirq+0x178/0x338 [ 88.856077] [<8012a2d4>] irq_exit+0xbc/0x100 [ 88.860846] [<802f8b70>] plat_irq_dispatch+0xc0/0x144 [ 88.866477] [<80105974>] handle_int+0x14c/0x158 [ 88.871516] [<806acfb0>] r4k_wait+0x30/0x40 [ 88.876462] Code: afb10014 8c8200a0 00803025 <9443000c> 94a20468 00000000 10620042 00a08025 9605046a [ 88.887332] [ 88.888982] ---[ end trace eb863d007da11cf1 ]--- [ 88.894122] Kernel panic - not syncing: Fatal exception in interrupt [ 88.901202] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Fix this by pulling skb off the sublist and zeroing skb->next pointer before calling ptype callback. Fixes: 88eb1944e18c ("net: core: propagate SKB lists through packet_type lookup") Reviewed-by: Edward Cree Signed-off-by: Alexander Lobakin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a2ef7723a13c6d6909371a5a4b640a266ae07b8b Author: Lorenzo Bianconi Date: Sat Apr 6 17:16:53 2019 +0200 net: ip6_gre: fix possible use-after-free in ip6erspan_rcv [ Upstream commit 2a3cabae4536edbcb21d344e7aa8be7a584d2afb ] erspan_v6 tunnels run __iptunnel_pull_header on received skbs to remove erspan header. This can determine a possible use-after-free accessing pkt_md pointer in ip6erspan_rcv since the packet will be 'uncloned' running pskb_expand_head if it is a cloned gso skb (e.g if the packet has been sent though a veth device). Fix it resetting pkt_md pointer after __iptunnel_pull_header Fixes: 1d7e2ed22f8d ("net: erspan: refactor existing erspan code") Signed-off-by: Lorenzo Bianconi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5c6f2f4c0e9f91daa436d118a7f5c2142541e4ac Author: Lorenzo Bianconi Date: Sat Apr 6 17:16:52 2019 +0200 net: ip_gre: fix possible use-after-free in erspan_rcv [ Upstream commit 492b67e28ee5f2a2522fb72e3d3bcb990e461514 ] erspan tunnels run __iptunnel_pull_header on received skbs to remove gre and erspan headers. This can determine a possible use-after-free accessing pkt_md pointer in erspan_rcv since the packet will be 'uncloned' running pskb_expand_head if it is a cloned gso skb (e.g if the packet has been sent though a veth device). Fix it resetting pkt_md pointer after __iptunnel_pull_header Fixes: 1d7e2ed22f8d ("net: erspan: refactor existing erspan code") Signed-off-by: Lorenzo Bianconi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ecee513a5273b87ac942af435f98f31d8622b415 Author: Michael Chan Date: Mon Apr 8 17:39:55 2019 -0400 bnxt_en: Reset device on RX buffer errors. [ Upstream commit 8e44e96c6c8e8fb80b84a2ca11798a8554f710f2 ] If the RX completion indicates RX buffers errors, the RX ring will be disabled by firmware and no packets will be received on that ring from that point on. Recover by resetting the device. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d2d055a554036b0240f296743942b8111fd4ce97 Author: Michael Chan Date: Mon Apr 8 17:39:54 2019 -0400 bnxt_en: Improve RX consumer index validity check. [ Upstream commit a1b0e4e684e9c300b9e759b46cb7a0147e61ddff ] There is logic to check that the RX/TPA consumer index is the expected index to work around a hardware problem. However, the potentially bad consumer index is first used to index into an array to reference an entry. This can potentially crash if the bad consumer index is beyond legal range. Improve the logic to use the consumer index for dereferencing after the validity check and log an error message. Fixes: fa7e28127a5a ("bnxt_en: Add workaround to detect bad opaque in rx completion (part 2)") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a333fcc410753b51742f3cb01ad123d4988958fb Author: Jakub Kicinski Date: Wed Mar 27 11:38:39 2019 -0700 nfp: disable netpoll on representors [ Upstream commit c3e1f7fff69c78169c8ac40cc74ac4307f74e36d ] NFP reprs are software device on top of the PF's vNIC. The comment above __dev_queue_xmit() sayeth: When calling this method, interrupts MUST be enabled. This is because the BH enable code must have IRQs enabled so that it will not deadlock. For netconsole we can't guarantee IRQ state, let's just disable netpoll on representors to be on the safe side. When the initial implementation of NFP reprs was added by the commit 5de73ee46704 ("nfp: general representor implementation") .ndo_poll_controller was required for netpoll to be enabled. Fixes: ac3d9dd034e5 ("netpoll: make ndo_poll_controller() optional") Signed-off-by: Jakub Kicinski Reviewed-by: John Hurley Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 81da1314596c88aa9e0e8dd610812b3f86afa5a5 Author: Jakub Kicinski Date: Wed Mar 27 11:38:38 2019 -0700 nfp: validate the return code from dev_queue_xmit() [ Upstream commit c8ba5b91a04e3e2643e48501c114108802f21cda ] dev_queue_xmit() may return error codes as well as netdev_tx_t, and it always consumes the skb. Make sure we always return a correct netdev_tx_t value. Fixes: eadfa4c3be99 ("nfp: add stats and xmit helpers for representors") Signed-off-by: Jakub Kicinski Reviewed-by: John Hurley Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c297e881457882b2121d2c539fd7e75a0977f8cd Author: Yuval Avnery Date: Mon Mar 11 06:18:24 2019 +0200 net/mlx5e: Add a lock on tir list [ Upstream commit 80a2a9026b24c6bd34b8d58256973e22270bedec ] Refresh tirs is looping over a global list of tirs while netdevs are adding and removing tirs from that list. That is why a lock is required. Fixes: 724b2aa15126 ("net/mlx5e: TIRs management refactoring") Signed-off-by: Yuval Avnery Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 9441317513b726864375b3d26c98d371417a13ec Author: Gavi Teitz Date: Mon Mar 11 11:56:34 2019 +0200 net/mlx5e: Fix error handling when refreshing TIRs [ Upstream commit bc87a0036826a37b43489b029af8143bd07c6cca ] Previously, a false positive would be caught if the TIRs list is empty, since the err value was initialized to -ENOMEM, and was only updated if a TIR is refreshed. This is resolved by initializing the err value to zero. Fixes: b676f653896a ("net/mlx5e: Refactor refresh TIRs") Signed-off-by: Gavi Teitz Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 0516ef27ddba5d46c6879fe5136fbdef441d9047 Author: Stephen Suryaputra Date: Mon Apr 1 09:17:32 2019 -0400 vrf: check accept_source_route on the original netdevice [ Upstream commit 8c83f2df9c6578ea4c5b940d8238ad8a41b87e9e ] Configuration check to accept source route IP options should be made on the incoming netdevice when the skb->dev is an l3mdev master. The route lookup for the source route next hop also needs the incoming netdev. v2->v3: - Simplify by passing the original netdevice down the stack (per David Ahern). Signed-off-by: Stephen Suryaputra Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7243e35209567783916eeb51669c886564a5a1be Author: Dust Li Date: Mon Apr 1 16:04:53 2019 +0800 tcp: fix a potential NULL pointer dereference in tcp_sk_exit [ Upstream commit b506bc975f60f06e13e74adb35e708a23dc4e87c ] When tcp_sk_init() failed in inet_ctl_sock_create(), 'net->ipv4.tcp_congestion_control' will be left uninitialized, but tcp_sk_exit() hasn't check for that. This patch add checking on 'net->ipv4.tcp_congestion_control' in tcp_sk_exit() to prevent NULL-ptr dereference. Fixes: 6670e1524477 ("tcp: Namespace-ify sysctl_tcp_default_congestion_control") Signed-off-by: Dust Li Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0e0afb06e11c7497893d3066d9474ad9761fe76b Author: Koen De Schepper Date: Thu Apr 4 12:24:02 2019 +0000 tcp: Ensure DCTCP reacts to losses [ Upstream commit aecfde23108b8e637d9f5c5e523b24fb97035dc3 ] RFC8257 §3.5 explicitly states that "A DCTCP sender MUST react to loss episodes in the same way as conventional TCP". Currently, Linux DCTCP performs no cwnd reduction when losses are encountered. Optionally, the dctcp_clamp_alpha_on_loss resets alpha to its maximal value if a RTO happens. This behavior is sub-optimal for at least two reasons: i) it ignores losses triggering fast retransmissions; and ii) it causes unnecessary large cwnd reduction in the future if the loss was isolated as it resets the historical term of DCTCP's alpha EWMA to its maximal value (i.e., denoting a total congestion). The second reason has an especially noticeable effect when using DCTCP in high BDP environments, where alpha normally stays at low values. This patch replace the clamping of alpha by setting ssthresh to half of cwnd for both fast retransmissions and RTOs, at most once per RTT. Consequently, the dctcp_clamp_alpha_on_loss module parameter has been removed. The table below shows experimental results where we measured the drop probability of a PIE AQM (not applying ECN marks) at a bottleneck in the presence of a single TCP flow with either the alpha-clamping option enabled or the cwnd halving proposed by this patch. Results using reno or cubic are given for comparison. | Link | RTT | Drop TCP CC | speed | base+AQM | probability ==================|=========|==========|============ CUBIC | 40Mbps | 7+20ms | 0.21% RENO | | | 0.19% DCTCP-CLAMP-ALPHA | | | 25.80% DCTCP-HALVE-CWND | | | 0.22% ------------------|---------|----------|------------ CUBIC | 100Mbps | 7+20ms | 0.03% RENO | | | 0.02% DCTCP-CLAMP-ALPHA | | | 23.30% DCTCP-HALVE-CWND | | | 0.04% ------------------|---------|----------|------------ CUBIC | 800Mbps | 1+1ms | 0.04% RENO | | | 0.05% DCTCP-CLAMP-ALPHA | | | 18.70% DCTCP-HALVE-CWND | | | 0.06% We see that, without halving its cwnd for all source of losses, DCTCP drives the AQM to large drop probabilities in order to keep the queue length under control (i.e., it repeatedly faces RTOs). Instead, if DCTCP reacts to all source of losses, it can then be controlled by the AQM using similar drop levels than cubic or reno. Signed-off-by: Koen De Schepper Signed-off-by: Olivier Tilmans Cc: Bob Briscoe Cc: Lawrence Brakmo Cc: Florian Westphal Cc: Daniel Borkmann Cc: Yuchung Cheng Cc: Neal Cardwell Cc: Eric Dumazet Cc: Andrew Shewmaker Cc: Glenn Judd Acked-by: Florian Westphal Acked-by: Neal Cardwell Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 87349583e517f5964e703a9404c06d89c97b65e3 Author: Xin Long Date: Sun Mar 31 16:58:15 2019 +0800 sctp: initialize _pad of sockaddr_in before copying to user memory [ Upstream commit 09279e615c81ce55e04835970601ae286e3facbe ] Syzbot report a kernel-infoleak: BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32 Call Trace: _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32 copy_to_user include/linux/uaccess.h:174 [inline] sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline] sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562 ... Uninit was stored to memory at: sctp_transport_init net/sctp/transport.c:61 [inline] sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115 sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637 sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline] sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361 ... Bytes 8-15 of 16 are uninitialized It was caused by that th _pad field (the 8-15 bytes) of a v4 addr (saved in struct sockaddr_in) wasn't initialized, but directly copied to user memory in sctp_getsockopt_peer_addrs(). So fix it by calling memset(addr->v4.sin_zero, 0, 8) to initialize _pad of sockaddr_in before copying it to user memory in sctp_v4_addr_to_user(), as sctp_v6_addr_to_user() does. Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com Signed-off-by: Xin Long Tested-by: Alexander Potapenko Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1e4a7e7869acc57987d0e0b2ecf53b9a74fb911a Author: Heiner Kallweit Date: Fri Apr 5 20:46:46 2019 +0200 r8169: disable ASPM again [ Upstream commit b75bb8a5b755d0c7bf1ac071e4df2349a7644a1e ] There's a significant number of reports that re-enabling ASPM causes different issues, ranging from decreased performance to system not booting at all. This affects only a minority of users, but the number of affected users is big enough that we better switch off ASPM again. This will hurt notebook users who are not affected by the issues, they may see decreased battery runtime w/o ASPM. With the PCI core folks is being discussed to add generic sysfs attributes to control ASPM. Once this is in place brave enough users can re-enable ASPM on their system. Fixes: a99790bf5c7f ("r8169: Reinstate ASPM Support") Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 84dc2f872d2d70bfd045b0ef716d5b55b5e1ae13 Author: Bjørn Mork Date: Wed Mar 27 15:26:01 2019 +0100 qmi_wwan: add Olicard 600 [ Upstream commit 6289d0facd9ebce4cc83e5da39e15643ee998dc5 ] This is a Qualcomm based device with a QMI function on interface 4. It is mode switched from 2020:2030 using a standard eject message. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2020 ProdID=2031 Rev= 2.32 S: Manufacturer=Mobile Connect S: Product=Mobile Connect S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none) E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ec0e32da41a6a153be67ce105b5e45d814dcba77 Author: Andrea Righi Date: Thu Mar 28 07:36:00 2019 +0100 openvswitch: fix flow actions reallocation [ Upstream commit f28cd2af22a0c134e4aa1c64a70f70d815d473fb ] The flow action buffer can be resized if it's not big enough to contain all the requested flow actions. However, this resize doesn't take into account the new requested size, the buffer is only increased by a factor of 2x. This might be not enough to contain the new data, causing a buffer overflow, for example: [ 42.044472] ============================================================================= [ 42.045608] BUG kmalloc-96 (Not tainted): Redzone overwritten [ 42.046415] ----------------------------------------------------------------------------- [ 42.047715] Disabling lock debugging due to kernel taint [ 42.047716] INFO: 0x8bf2c4a5-0x720c0928. First byte 0x0 instead of 0xcc [ 42.048677] INFO: Slab 0xbc6d2040 objects=29 used=18 fp=0xdc07dec4 flags=0x2808101 [ 42.049743] INFO: Object 0xd53a3464 @offset=2528 fp=0xccdcdebb [ 42.050747] Redzone 76f1b237: cc cc cc cc cc cc cc cc ........ [ 42.051839] Object d53a3464: 6b 6b 6b 6b 6b 6b 6b 6b 0c 00 00 00 6c 00 00 00 kkkkkkkk....l... [ 42.053015] Object f49a30cc: 6c 00 0c 00 00 00 00 00 00 00 00 03 78 a3 15 f6 l...........x... [ 42.054203] Object acfe4220: 20 00 02 00 ff ff ff ff 00 00 00 00 00 00 00 00 ............... [ 42.055370] Object 21024e91: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 42.056541] Object 070e04c3: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 42.057797] Object 948a777a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 42.059061] Redzone 8bf2c4a5: 00 00 00 00 .... [ 42.060189] Padding a681b46e: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Fix by making sure the new buffer is properly resized to contain all the requested data. BugLink: https://bugs.launchpad.net/bugs/1813244 Signed-off-by: Andrea Righi Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit eeedfa94c195049e27d71b2222bb9be425bce0bc Author: Nicolas Dichtel Date: Thu Mar 28 10:35:06 2019 +0100 net/sched: fix ->get helper of the matchall cls [ Upstream commit 0db6f8befc32c68bb13d7ffbb2e563c79e913e13 ] It returned always NULL, thus it was never possible to get the filter. Example: $ ip link add foo type dummy $ ip link add bar type dummy $ tc qdisc add dev foo clsact $ tc filter add dev foo protocol all pref 1 ingress handle 1234 \ matchall action mirred ingress mirror dev bar Before the patch: $ tc filter get dev foo protocol all pref 1 ingress handle 1234 matchall Error: Specified filter handle not found. We have an error talking to the kernel After: $ tc filter get dev foo protocol all pref 1 ingress handle 1234 matchall filter ingress protocol all pref 1 matchall chain 0 handle 0x4d2 not_in_hw action order 1: mirred (Ingress Mirror to device bar) pipe index 1 ref 1 bind 1 CC: Yotam Gigi CC: Jiri Pirko Fixes: fd62d9f5c575 ("net/sched: matchall: Fix configuration race") Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 15c0770e2e83aa43cfa851be5edef81b06fcdf3f Author: Davide Caratti Date: Thu Apr 4 12:31:35 2019 +0200 net/sched: act_sample: fix divide by zero in the traffic path [ Upstream commit fae2708174ae95d98d19f194e03d6e8f688ae195 ] the control path of 'sample' action does not validate the value of 'rate' provided by the user, but then it uses it as divisor in the traffic path. Validate it in tcf_sample_init(), and return -EINVAL with a proper extack message in case that value is zero, to fix a splat with the script below: # tc f a dev test0 egress matchall action sample rate 0 group 1 index 2 # tc -s a s action sample total acts 1 action order 0: sample rate 1/0 group 1 pipe index 2 ref 1 bind 1 installed 19 sec used 19 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 # ping 192.0.2.1 -I test0 -c1 -q divide error: 0000 [#1] SMP PTI CPU: 1 PID: 6192 Comm: ping Not tainted 5.1.0-rc2.diag2+ #591 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:tcf_sample_act+0x9e/0x1e0 [act_sample] Code: 6a f1 85 c0 74 0d 80 3d 83 1a 00 00 00 0f 84 9c 00 00 00 4d 85 e4 0f 84 85 00 00 00 e8 9b d7 9c f1 44 8b 8b e0 00 00 00 31 d2 <41> f7 f1 85 d2 75 70 f6 85 83 00 00 00 10 48 8b 45 10 8b 88 08 01 RSP: 0018:ffffae320190ba30 EFLAGS: 00010246 RAX: 00000000b0677d21 RBX: ffff8af1ed9ec000 RCX: 0000000059a9fe49 RDX: 0000000000000000 RSI: 000000000c7e33b7 RDI: ffff8af23daa0af0 RBP: ffff8af1ee11b200 R08: 0000000074fcaf7e R09: 0000000000000000 R10: 0000000000000050 R11: ffffffffb3088680 R12: ffff8af232307f80 R13: 0000000000000003 R14: ffff8af1ed9ec000 R15: 0000000000000000 FS: 00007fe9c6d2f740(0000) GS:ffff8af23da80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff6772f000 CR3: 00000000746a2004 CR4: 00000000001606e0 Call Trace: tcf_action_exec+0x7c/0x1c0 tcf_classify+0x57/0x160 __dev_queue_xmit+0x3dc/0xd10 ip_finish_output2+0x257/0x6d0 ip_output+0x75/0x280 ip_send_skb+0x15/0x40 raw_sendmsg+0xae3/0x1410 sock_sendmsg+0x36/0x40 __sys_sendto+0x10e/0x140 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x60/0x210 entry_SYSCALL_64_after_hwframe+0x49/0xbe [...] Kernel panic - not syncing: Fatal exception in interrupt Add a TDC selftest to document that 'rate' is now being validated. Reported-by: Matteo Croce Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action") Signed-off-by: Davide Caratti Acked-by: Yotam Gigi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 78b4bf26a8a76569fd6d0b47d98fb553c333b06f Author: Mao Wenan Date: Thu Mar 28 17:10:56 2019 +0800 net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock(). [ Upstream commit cb66ddd156203daefb8d71158036b27b0e2caf63 ] When it is to cleanup net namespace, rds_tcp_exit_net() will call rds_tcp_kill_sock(), if t_sock is NULL, it will not call rds_conn_destroy(), rds_conn_path_destroy() and rds_tcp_conn_free() to free connection, and the worker cp_conn_w is not stopped, afterwards the net is freed in net_drop_ns(); While cp_conn_w rds_connect_worker() will call rds_tcp_conn_path_connect() and reference 'net' which has already been freed. In rds_tcp_conn_path_connect(), rds_tcp_set_callbacks() will set t_sock = sock before sock->ops->connect, but if connect() is failed, it will call rds_tcp_restore_callbacks() and set t_sock = NULL, if connect is always failed, rds_connect_worker() will try to reconnect all the time, so rds_tcp_kill_sock() will never to cancel worker cp_conn_w and free the connections. Therefore, the condition !tc->t_sock is not needed if it is going to do cleanup_net->rds_tcp_exit_net->rds_tcp_kill_sock, because tc->t_sock is always NULL, and there is on other path to cancel cp_conn_w and free connection. So this patch is to fix this. rds_tcp_kill_sock(): ... if (net != c_net || !tc->t_sock) ... Acked-by: Santosh Shilimkar ================================================================== BUG: KASAN: use-after-free in inet_create+0xbcc/0xd28 net/ipv4/af_inet.c:340 Read of size 4 at addr ffff8003496a4684 by task kworker/u8:4/3721 CPU: 3 PID: 3721 Comm: kworker/u8:4 Not tainted 5.1.0 #11 Hardware name: linux,dummy-virt (DT) Workqueue: krdsd rds_connect_worker Call trace: dump_backtrace+0x0/0x3c0 arch/arm64/kernel/time.c:53 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:152 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x120/0x188 lib/dump_stack.c:113 print_address_description+0x68/0x278 mm/kasan/report.c:253 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x21c/0x348 mm/kasan/report.c:409 __asan_report_load4_noabort+0x30/0x40 mm/kasan/report.c:429 inet_create+0xbcc/0xd28 net/ipv4/af_inet.c:340 __sock_create+0x4f8/0x770 net/socket.c:1276 sock_create_kern+0x50/0x68 net/socket.c:1322 rds_tcp_conn_path_connect+0x2b4/0x690 net/rds/tcp_connect.c:114 rds_connect_worker+0x108/0x1d0 net/rds/threads.c:175 process_one_work+0x6e8/0x1700 kernel/workqueue.c:2153 worker_thread+0x3b0/0xdd0 kernel/workqueue.c:2296 kthread+0x2f0/0x378 kernel/kthread.c:255 ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:1117 Allocated by task 687: save_stack mm/kasan/kasan.c:448 [inline] set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xd4/0x180 mm/kasan/kasan.c:553 kasan_slab_alloc+0x14/0x20 mm/kasan/kasan.c:490 slab_post_alloc_hook mm/slab.h:444 [inline] slab_alloc_node mm/slub.c:2705 [inline] slab_alloc mm/slub.c:2713 [inline] kmem_cache_alloc+0x14c/0x388 mm/slub.c:2718 kmem_cache_zalloc include/linux/slab.h:697 [inline] net_alloc net/core/net_namespace.c:384 [inline] copy_net_ns+0xc4/0x2d0 net/core/net_namespace.c:424 create_new_namespaces+0x300/0x658 kernel/nsproxy.c:107 unshare_nsproxy_namespaces+0xa0/0x198 kernel/nsproxy.c:206 ksys_unshare+0x340/0x628 kernel/fork.c:2577 __do_sys_unshare kernel/fork.c:2645 [inline] __se_sys_unshare kernel/fork.c:2643 [inline] __arm64_sys_unshare+0x38/0x58 kernel/fork.c:2643 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall arch/arm64/kernel/syscall.c:47 [inline] el0_svc_common+0x168/0x390 arch/arm64/kernel/syscall.c:83 el0_svc_handler+0x60/0xd0 arch/arm64/kernel/syscall.c:129 el0_svc+0x8/0xc arch/arm64/kernel/entry.S:960 Freed by task 264: save_stack mm/kasan/kasan.c:448 [inline] set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x114/0x220 mm/kasan/kasan.c:521 kasan_slab_free+0x10/0x18 mm/kasan/kasan.c:528 slab_free_hook mm/slub.c:1370 [inline] slab_free_freelist_hook mm/slub.c:1397 [inline] slab_free mm/slub.c:2952 [inline] kmem_cache_free+0xb8/0x3a8 mm/slub.c:2968 net_free net/core/net_namespace.c:400 [inline] net_drop_ns.part.6+0x78/0x90 net/core/net_namespace.c:407 net_drop_ns net/core/net_namespace.c:406 [inline] cleanup_net+0x53c/0x6d8 net/core/net_namespace.c:569 process_one_work+0x6e8/0x1700 kernel/workqueue.c:2153 worker_thread+0x3b0/0xdd0 kernel/workqueue.c:2296 kthread+0x2f0/0x378 kernel/kthread.c:255 ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:1117 The buggy address belongs to the object at ffff8003496a3f80 which belongs to the cache net_namespace of size 7872 The buggy address is located 1796 bytes inside of 7872-byte region [ffff8003496a3f80, ffff8003496a5e40) The buggy address belongs to the page: page:ffff7e000d25a800 count:1 mapcount:0 mapping:ffff80036ce4b000 index:0x0 compound_mapcount: 0 flags: 0xffffe0000008100(slab|head) raw: 0ffffe0000008100 dead000000000100 dead000000000200 ffff80036ce4b000 raw: 0000000000000000 0000000080040004 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8003496a4580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8003496a4600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8003496a4680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8003496a4700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8003496a4780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 467fa15356ac("RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.") Reported-by: Hulk Robot Signed-off-by: Mao Wenan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a1c2f3229734a4bb8d5ac008c0a67e025aa11547 Author: Eric Dumazet Date: Wed Mar 27 08:21:30 2019 -0700 netns: provide pure entropy for net_hash_mix() [ Upstream commit 355b98553789b646ed97ad801a619ff898471b92 ] net_hash_mix() currently uses kernel address of a struct net, and is used in many places that could be used to reveal this address to a patient attacker, thus defeating KASLR, for the typical case (initial net namespace, &init_net is not dynamically allocated) I believe the original implementation tried to avoid spending too many cycles in this function, but security comes first. Also provide entropy regardless of CONFIG_NET_NS. Fixes: 0b4419162aa6 ("netns: introduce the net_hash_mix "salt" for hashes") Signed-off-by: Eric Dumazet Reported-by: Amit Klein Reported-by: Benny Pinkas Cc: Pavel Emelyanov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 53a1906859a2ec1d2b5c33102086ce3e03ec0b37 Author: Artemy Kovalyov Date: Tue Mar 19 11:24:38 2019 +0200 net/mlx5: Decrease default mr cache size [ Upstream commit e8b26b2135dedc0284490bfeac06dfc4418d0105 ] Delete initialization of high order entries in mr cache to decrease initial memory footprint. When required, the administrator can populate the entries with memory keys via the /sys interface. This approach is very helpful to significantly reduce the per HW function memory footprint in virtualization environments such as SRIOV. Fixes: 9603b61de1ee ("mlx5: Move pci device handling from mlx5_ib to mlx5_core") Signed-off-by: Artemy Kovalyov Signed-off-by: Moni Shoua Signed-off-by: Leon Romanovsky Reported-by: Shalom Toledo Acked-by: Or Gerlitz Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit b87ec81362ac54ad33a001fffb11d1b9d9a28fc8 Author: Steffen Klassert Date: Tue Apr 2 08:16:03 2019 +0200 net-gro: Fix GRO flush when receiving a GSO packet. [ Upstream commit 0ab03f353d3613ea49d1f924faf98559003670a8 ] Currently we may merge incorrectly a received GSO packet or a packet with frag_list into a packet sitting in the gro_hash list. skb_segment() may crash case because the assumptions on the skb layout are not met. The correct behaviour would be to flush the packet in the gro_hash list and send the received GSO packet directly afterwards. Commit d61d072e87c8e ("net-gro: avoid reorders") sets NAPI_GRO_CB(skb)->flush in this case, but this is not checked before merging. This patch makes sure to check this flag and to not merge in that case. Fixes: d61d072e87c8e ("net-gro: avoid reorders") Signed-off-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 80c205813d3f5d7a912c73487d1ee6d76a696af1 Author: Li RongQing Date: Fri Mar 29 09:18:02 2019 +0800 net: ethtool: not call vzalloc for zero sized memory request [ Upstream commit 3d8830266ffc28c16032b859e38a0252e014b631 ] NULL or ZERO_SIZE_PTR will be returned for zero sized memory request, and derefencing them will lead to a segfault so it is unnecessory to call vzalloc for zero sized memory request and not call functions which maybe derefence the NULL allocated memory this also fixes a possible memory leak if phy_ethtool_get_stats returns error, memory should be freed before exit Signed-off-by: Li RongQing Reviewed-by: Wang Li Reviewed-by: Michal Kubecek Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b7b058315577de56aff6bdcd836c8ec60cdb25a4 Author: Jiri Slaby Date: Fri Mar 29 12:19:46 2019 +0100 kcm: switch order of device registration to fix a crash [ Upstream commit 3c446e6f96997f2a95bf0037ef463802162d2323 ] When kcm is loaded while many processes try to create a KCM socket, a crash occurs: BUG: unable to handle kernel NULL pointer dereference at 000000000000000e IP: mutex_lock+0x27/0x40 kernel/locking/mutex.c:240 PGD 8000000016ef2067 P4D 8000000016ef2067 PUD 3d6e9067 PMD 0 Oops: 0002 [#1] SMP KASAN PTI CPU: 0 PID: 7005 Comm: syz-executor.5 Not tainted 4.12.14-396-default #1 SLE15-SP1 (unreleased) RIP: 0010:mutex_lock+0x27/0x40 kernel/locking/mutex.c:240 RSP: 0018:ffff88000d487a00 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 000000000000000e RCX: 1ffff100082b0719 ... CR2: 000000000000000e CR3: 000000004b1bc003 CR4: 0000000000060ef0 Call Trace: kcm_create+0x600/0xbf0 [kcm] __sock_create+0x324/0x750 net/socket.c:1272 ... This is due to race between sock_create and unfinished register_pernet_device. kcm_create tries to do "net_generic(net, kcm_net_id)". but kcm_net_id is not initialized yet. So switch the order of the two to close the race. This can be reproduced with mutiple processes doing socket(PF_KCM, ...) and one process doing module removal. Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Reviewed-by: Michal Kubecek Signed-off-by: Jiri Slaby Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 42f1fa0fcf55e531186e84d396c3621869a8edf6 Author: Lorenzo Bianconi Date: Thu Apr 4 16:37:53 2019 +0200 ipv6: sit: reset ip header pointer in ipip6_rcv [ Upstream commit bb9bd814ebf04f579be466ba61fc922625508807 ] ipip6 tunnels run iptunnel_pull_header on received skbs. This can determine the following use-after-free accessing iph pointer since the packet will be 'uncloned' running pskb_expand_head if it is a cloned gso skb (e.g if the packet has been sent though a veth device) [ 706.369655] BUG: KASAN: use-after-free in ipip6_rcv+0x1678/0x16e0 [sit] [ 706.449056] Read of size 1 at addr ffffe01b6bd855f5 by task ksoftirqd/1/= [ 706.669494] Hardware name: HPE ProLiant m400 Server/ProLiant m400 Server, BIOS U02 08/19/2016 [ 706.771839] Call trace: [ 706.801159] dump_backtrace+0x0/0x2f8 [ 706.845079] show_stack+0x24/0x30 [ 706.884833] dump_stack+0xe0/0x11c [ 706.925629] print_address_description+0x68/0x260 [ 706.982070] kasan_report+0x178/0x340 [ 707.025995] __asan_report_load1_noabort+0x30/0x40 [ 707.083481] ipip6_rcv+0x1678/0x16e0 [sit] [ 707.132623] tunnel64_rcv+0xd4/0x200 [tunnel4] [ 707.185940] ip_local_deliver_finish+0x3b8/0x988 [ 707.241338] ip_local_deliver+0x144/0x470 [ 707.289436] ip_rcv_finish+0x43c/0x14b0 [ 707.335447] ip_rcv+0x628/0x1138 [ 707.374151] __netif_receive_skb_core+0x1670/0x2600 [ 707.432680] __netif_receive_skb+0x28/0x190 [ 707.482859] process_backlog+0x1d0/0x610 [ 707.529913] net_rx_action+0x37c/0xf68 [ 707.574882] __do_softirq+0x288/0x1018 [ 707.619852] run_ksoftirqd+0x70/0xa8 [ 707.662734] smpboot_thread_fn+0x3a4/0x9e8 [ 707.711875] kthread+0x2c8/0x350 [ 707.750583] ret_from_fork+0x10/0x18 [ 707.811302] Allocated by task 16982: [ 707.854182] kasan_kmalloc.part.1+0x40/0x108 [ 707.905405] kasan_kmalloc+0xb4/0xc8 [ 707.948291] kasan_slab_alloc+0x14/0x20 [ 707.994309] __kmalloc_node_track_caller+0x158/0x5e0 [ 708.053902] __kmalloc_reserve.isra.8+0x54/0xe0 [ 708.108280] __alloc_skb+0xd8/0x400 [ 708.150139] sk_stream_alloc_skb+0xa4/0x638 [ 708.200346] tcp_sendmsg_locked+0x818/0x2b90 [ 708.251581] tcp_sendmsg+0x40/0x60 [ 708.292376] inet_sendmsg+0xf0/0x520 [ 708.335259] sock_sendmsg+0xac/0xf8 [ 708.377096] sock_write_iter+0x1c0/0x2c0 [ 708.424154] new_sync_write+0x358/0x4a8 [ 708.470162] __vfs_write+0xc4/0xf8 [ 708.510950] vfs_write+0x12c/0x3d0 [ 708.551739] ksys_write+0xcc/0x178 [ 708.592533] __arm64_sys_write+0x70/0xa0 [ 708.639593] el0_svc_handler+0x13c/0x298 [ 708.686646] el0_svc+0x8/0xc [ 708.739019] Freed by task 17: [ 708.774597] __kasan_slab_free+0x114/0x228 [ 708.823736] kasan_slab_free+0x10/0x18 [ 708.868703] kfree+0x100/0x3d8 [ 708.905320] skb_free_head+0x7c/0x98 [ 708.948204] skb_release_data+0x320/0x490 [ 708.996301] pskb_expand_head+0x60c/0x970 [ 709.044399] __iptunnel_pull_header+0x3b8/0x5d0 [ 709.098770] ipip6_rcv+0x41c/0x16e0 [sit] [ 709.146873] tunnel64_rcv+0xd4/0x200 [tunnel4] [ 709.200195] ip_local_deliver_finish+0x3b8/0x988 [ 709.255596] ip_local_deliver+0x144/0x470 [ 709.303692] ip_rcv_finish+0x43c/0x14b0 [ 709.349705] ip_rcv+0x628/0x1138 [ 709.388413] __netif_receive_skb_core+0x1670/0x2600 [ 709.446943] __netif_receive_skb+0x28/0x190 [ 709.497120] process_backlog+0x1d0/0x610 [ 709.544169] net_rx_action+0x37c/0xf68 [ 709.589131] __do_softirq+0x288/0x1018 [ 709.651938] The buggy address belongs to the object at ffffe01b6bd85580 which belongs to the cache kmalloc-1024 of size 1024 [ 709.804356] The buggy address is located 117 bytes inside of 1024-byte region [ffffe01b6bd85580, ffffe01b6bd85980) [ 709.946340] The buggy address belongs to the page: [ 710.003824] page:ffff7ff806daf600 count:1 mapcount:0 mapping:ffffe01c4001f600 index:0x0 [ 710.099914] flags: 0xfffff8000000100(slab) [ 710.149059] raw: 0fffff8000000100 dead000000000100 dead000000000200 ffffe01c4001f600 [ 710.242011] raw: 0000000000000000 0000000000380038 00000001ffffffff 0000000000000000 [ 710.334966] page dumped because: kasan: bad access detected Fix it resetting iph pointer after iptunnel_pull_header Fixes: a09a4c8dd1ec ("tunnels: Remove encapsulation offloads on decap") Tested-by: Jianlin Shi Signed-off-by: Lorenzo Bianconi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ea06796f8857b41c603b243590c968eb6b70ab41 Author: Junwei Hu Date: Tue Apr 2 19:38:04 2019 +0800 ipv6: Fix dangling pointer when ipv6 fragment [ Upstream commit ef0efcd3bd3fd0589732b67fb586ffd3c8705806 ] At the beginning of ip6_fragment func, the prevhdr pointer is obtained in the ip6_find_1stfragopt func. However, all the pointers pointing into skb header may change when calling skb_checksum_help func with skb->ip_summed = CHECKSUM_PARTIAL condition. The prevhdr pointe will be dangling if it is not reloaded after calling __skb_linearize func in skb_checksum_help func. Here, I add a variable, nexthdr_offset, to evaluate the offset, which does not changes even after calling __skb_linearize func. Fixes: 405c92f7a541 ("ipv6: add defensive check for CHECKSUM_PARTIAL skbs in ip_fragment") Signed-off-by: Junwei Hu Reported-by: Wenhao Zhang Reported-by: syzbot+e8ce541d095e486074fc@syzkaller.appspotmail.com Reviewed-by: Zhiqiang Liu Acked-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8e4b4da3d3d9c163fef201cb9cf76c17a6e932e4 Author: Sheena Mira-ato Date: Mon Apr 1 13:04:42 2019 +1300 ip6_tunnel: Match to ARPHRD_TUNNEL6 for dev type [ Upstream commit b2e54b09a3d29c4db883b920274ca8dca4d9f04d ] The device type for ip6 tunnels is set to ARPHRD_TUNNEL6. However, the ip4ip6_err function is expecting the device type of the tunnel to be ARPHRD_TUNNEL. Since the device types do not match, the function exits and the ICMP error packet is not sent to the originating host. Note that the device type for IPv4 tunnels is set to ARPHRD_TUNNEL. Fix is to expect a tunnel device type of ARPHRD_TUNNEL6 instead. Now the tunnel device type matches and the ICMP error packet is sent to the originating host. Signed-off-by: Sheena Mira-ato Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 167019572ca89fee8ad8dc98c70203c105c97e53 Author: Thomas Falcon Date: Thu Apr 4 18:58:26 2019 -0500 ibmvnic: Fix completion structure initialization [ Upstream commit bbd669a868bba591ffd38b7bc75a7b361bb54b04 ] Fix device initialization completion handling for vNIC adapters. Initialize the completion structure on probe and reinitialize when needed. This also fixes a race condition during kdump where the driver can attempt to access the completion struct before it is initialized: Unable to handle kernel paging request for data at address 0x00000000 Faulting instruction address: 0xc0000000081acbe0 Oops: Kernel access of bad area, sig: 11 [#1] LE SMP NR_CPUS=2048 NUMA pSeries Modules linked in: ibmvnic(+) ibmveth sunrpc overlay squashfs loop CPU: 19 PID: 301 Comm: systemd-udevd Not tainted 4.18.0-64.el8.ppc64le #1 NIP: c0000000081acbe0 LR: c0000000081ad964 CTR: c0000000081ad900 REGS: c000000027f3f990 TRAP: 0300 Not tainted (4.18.0-64.el8.ppc64le) MSR: 800000010280b033 CR: 28228288 XER: 00000006 CFAR: c000000008008934 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 GPR00: c0000000081ad964 c000000027f3fc10 c0000000095b5800 c0000000221b4e58 GPR04: 0000000000000003 0000000000000001 000049a086918581 00000000000000d4 GPR08: 0000000000000007 0000000000000000 ffffffffffffffe8 d0000000014dde28 GPR12: c0000000081ad900 c000000009a00c00 0000000000000001 0000000000000100 GPR16: 0000000000000038 0000000000000007 c0000000095e2230 0000000000000006 GPR20: 0000000000400140 0000000000000001 c00000000910c880 0000000000000000 GPR24: 0000000000000000 0000000000000006 0000000000000000 0000000000000003 GPR28: 0000000000000001 0000000000000001 c0000000221b4e60 c0000000221b4e58 NIP [c0000000081acbe0] __wake_up_locked+0x50/0x100 LR [c0000000081ad964] complete+0x64/0xa0 Call Trace: [c000000027f3fc10] [c000000027f3fc60] 0xc000000027f3fc60 (unreliable) [c000000027f3fc60] [c0000000081ad964] complete+0x64/0xa0 [c000000027f3fca0] [d0000000014dad58] ibmvnic_handle_crq+0xce0/0x1160 [ibmvnic] [c000000027f3fd50] [d0000000014db270] ibmvnic_tasklet+0x98/0x130 [ibmvnic] [c000000027f3fda0] [c00000000813f334] tasklet_action_common.isra.3+0xc4/0x1a0 [c000000027f3fe00] [c000000008cd13f4] __do_softirq+0x164/0x400 [c000000027f3fef0] [c00000000813ed64] irq_exit+0x184/0x1c0 [c000000027f3ff20] [c0000000080188e8] __do_irq+0xb8/0x210 [c000000027f3ff90] [c00000000802d0a4] call_do_irq+0x14/0x24 [c000000026a5b010] [c000000008018adc] do_IRQ+0x9c/0x130 [c000000026a5b060] [c000000008008ce4] hardware_interrupt_common+0x114/0x120 Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9a7c4f5acc0e1f2fafa6867af639a4ebbe1fc69c Author: Haiyang Zhang Date: Thu Mar 28 19:40:36 2019 +0000 hv_netvsc: Fix unwanted wakeup after tx_disable [ Upstream commit 1b704c4a1ba95574832e730f23817b651db2aa59 ] After queue stopped, the wakeup mechanism may wake it up again when ring buffer usage is lower than a threshold. This may cause send path panic on NULL pointer when we stopped all tx queues in netvsc_detach and start removing the netvsc device. This patch fix it by adding a tx_disable flag to prevent unwanted queue wakeup. Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic") Reported-by: Mohammed Gamal Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 902eca1a0ccfd2661106731db3a74b2304f31217 Author: Breno Leitao Date: Mon Apr 8 16:32:38 2019 +1000 powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM commit 897bc3df8c5aebb54c32d831f917592e873d0559 upstream. Commit e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint") moved a code block around and this block uses a 'msr' variable outside of the CONFIG_PPC_TRANSACTIONAL_MEM, however the 'msr' variable is declared inside a CONFIG_PPC_TRANSACTIONAL_MEM block, causing a possible error when CONFIG_PPC_TRANSACTION_MEM is not defined. error: 'msr' undeclared (first use in this function) This is not causing a compilation error in the mainline kernel, because 'msr' is being used as an argument of MSR_TM_ACTIVE(), which is defined as the following when CONFIG_PPC_TRANSACTIONAL_MEM is *not* set: #define MSR_TM_ACTIVE(x) 0 This patch just fixes this issue avoiding the 'msr' variable usage outside the CONFIG_PPC_TRANSACTIONAL_MEM block, avoiding trusting in the MSR_TM_ACTIVE() definition. Cc: stable@vger.kernel.org Reported-by: Christoph Biedl Fixes: e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint") Signed-off-by: Breno Leitao Signed-off-by: Michael Ellerman Signed-off-by: Michael Neuling Signed-off-by: Sasha Levin commit 8ad895bf4b8bb365d074af01ab9deead7130246d Author: Yan Zhao Date: Wed Mar 27 00:55:45 2019 -0400 drm/i915/gvt: do not let pin count of shadow mm go negative [ Upstream commit 663a50ceac75c2208d2ad95365bc8382fd42f44d ] shadow mm's pin count got increased in workload preparation phase, which is after workload scanning. it will get decreased in complete_current_workload() anyway after workload completion. Sometimes, if a workload meets a scanning error, its shadow mm pin count will not get increased but will get decreased in the end. This patch lets shadow mm's pin count not go below 0. Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization") Cc: zhenyuw@linux.intel.com Cc: stable@vger.kernel.org #4.14+ Signed-off-by: Yan Zhao Signed-off-by: Zhenyu Wang Signed-off-by: Sasha Levin commit 646f8e01fc37f383c82eb497f925759fefe440c8 Author: Jim Mattson Date: Mon Nov 26 11:22:32 2018 -0800 kvm: nVMX: NMI-window and interrupt-window exiting should wake L2 from HLT [ Upstream commit 9ebdfe5230f2e50e3ba05c57723a06e90946815a ] According to the SDM, "NMI-window exiting" VM-exits wake a logical processor from the same inactive states as would an NMI and "interrupt-window exiting" VM-exits wake a logical processor from the same inactive states as would an external interrupt. Specifically, they wake a logical processor from the shutdown state and from the states entered using the HLT and MWAIT instructions. Fixes: 6dfacadd5858 ("KVM: nVMX: Add support for activity state HLT") Signed-off-by: Jim Mattson Reviewed-by: Peter Shier Suggested-by: Sean Christopherson [Squashed comments of two Jim's patches and used the simplified code hunk provided by Sean. - Radim] Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 4d552acf337038028f7e2f63a927afb7adf65fc1 Author: Greg Kroah-Hartman Date: Fri Apr 5 22:33:17 2019 +0200 Linux 4.19.34 commit d5813e77363cf550d23472aab64b3c9345de5d5c Author: Andrea Righi Date: Thu Dec 6 10:56:48 2018 +0100 kprobes/x86: Blacklist non-attachable interrupt functions [ Upstream commit a50480cb6d61d5c5fc13308479407b628b6bc1c5 ] These interrupt functions are already non-attachable by kprobes. Blacklist them explicitly so that they can show up in /sys/kernel/debug/kprobes/blacklist and tools like BCC can use this additional information. Signed-off-by: Andrea Righi Cc: Andy Lutomirski Cc: Anil S Keshavamurthy Cc: Borislav Petkov Cc: David S. Miller Cc: Linus Torvalds Cc: Masami Hiramatsu Cc: Naveen N. Rao Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Yonghong Song Link: http://lkml.kernel.org/r/20181206095648.GA8249@Dell Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit e7d26616c92bd96364b45c532b39e455523abb5f Author: Coly Li Date: Sat Feb 9 12:53:06 2019 +0800 bcache: fix potential div-zero error of writeback_rate_p_term_inverse [ Upstream commit 5b5fd3c94eef69dcfaa8648198e54c92e5687d6d ] Current code already uses d_strtoul_nonzero() to convert input string to an unsigned integer, to make sure writeback_rate_p_term_inverse won't be zero value. But overflow may happen when converting input string to an unsigned integer value by d_strtoul_nonzero(), then dc->writeback_rate_p_term_inverse can still be set to 0 even if the sysfs file input value is not zero, e.g. 4294967296 (a.k.a UINT_MAX+1). If dc->writeback_rate_p_term_inverse is set to 0, it might cause a dev-zero error in following code from __update_writeback_rate(), int64_t proportional_scaled = div_s64(error, dc->writeback_rate_p_term_inverse); This patch replaces d_strtoul_nonzero() by sysfs_strtoul_clamp() and limit the value range in [1, UINT_MAX]. Then the unsigned integer overflow and dev-zero error can be avoided. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 09abe130820ba36ad6bd9d3b9632624a9391b15b Author: Hans de Goede Date: Mon Jan 7 17:08:21 2019 +0100 ACPI / video: Extend chassis-type detection with a "Lunch Box" check [ Upstream commit d693c008e3ca04db5916ff72e68ce661888a913b ] Commit 53fa1f6e8a59 ("ACPI / video: Only default only_lcd to true on Win8-ready _desktops_") introduced chassis type detection, limiting the lcd_only check for the backlight to devices where the chassis-type indicates their is no builtin LCD panel. The purpose of the lcd_only check is to avoid advertising a backlight interface on desktops, since skylake and newer machines seem to always have a backlight interface even if there is no LCD panel. The limiting of this check to desktops only was done to avoid breaking backlight support on some laptops which do not have the lcd flag set. The Fujitsu ESPRIMO Q910 which is a compact (NUC like) desktop machine has a chassis type of 0x10 aka "Lunch Box". Without the lcd_only check we end up falsely advertising backlight/brightness control on this device. This commit extend the dmi_is_desktop check to return true for type 0x10 to fix this. Fixes: 53fa1f6e8a59 ("ACPI / video: Only default only_lcd to true ...") Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d1d2ca98b78f5d4805c33e5da3ed731f3712fe52 Author: Nathan Chancellor Date: Thu Mar 7 21:02:39 2019 -0700 net: stmmac: Avoid one more sometimes uninitialized Clang warning [ Upstream commit 1f5d861f7fefa971b2c6e766f77932c86419a319 ] When building with -Wsometimes-uninitialized, Clang warns: drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable 'ns' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c:111:2: error: variable 'ns' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized] Clang is concerned with the use of stmmac_do_void_callback (which stmmac_get_systime wraps), as it may fail to initialize these values if the if condition was ever false (meaning the callback doesn't exist). It's not wrong because the callback is what initializes ns. While it's unlikely that the callback is going to disappear at some point and make that condition false, we can easily avoid this warning by zero initializing the variable. Link: https://github.com/ClangBuiltLinux/linux/issues/384 Fixes: df103170854e ("net: stmmac: Avoid sometimes uninitialized Clang warnings") Suggested-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 972e31ba4bc2cd60e2bc955da292b07830543ff4 Author: Ville Syrjälä Date: Fri Sep 28 21:03:59 2018 +0300 drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers [ Upstream commit c978ae9bde582e82a04c63a4071701691dd8b35c ] We aren't supposed to force a stop+start between every i2c msg when performing multi message transfers. This should eg. cause the DDC segment address to be reset back to 0 between writing the segment address and reading the actual EDID extension block. To quote the E-DDC spec: "... this standard requires that the segment pointer be reset to 00h when a NO ACK or a STOP condition is received." Since we're going to touch this might as well consult the I2C_M_STOP flag to determine whether we want to force the stop or not. Cc: Brian Vincent References: https://bugs.freedesktop.org/show_bug.cgi?id=108081 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180928180403.22499-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan Signed-off-by: Sasha Levin commit 986a2bb54a31179b0c99b94743723d49388ad900 Author: Hans de Goede Date: Thu Jan 3 18:10:45 2019 -0800 Input: soc_button_array - fix mapping of the 5th GPIO in a PNP0C40 device [ Upstream commit e9eb788f9442d1b5d93efdb30c3be071ce8a22b1 ] The Microsoft documenation for the PNP0C40 device aka the "Windows-compatible button array" describes the 5th GpioInt listed in the resources as: '5. Interrupt corresponding to the "Rotation Lock" button, if supported'. Notice this describes the 5th entry as a button while we sofar have been mapping it to EV_SW, SW_ROTATE_LOCK. On my Point of View TAB P1006W-232 which actually comes with a rotation-lock button, the button indeed is a button and not a slider/switch. An image search for other Windows tablets has found 2 more models with a rotation-lock button and on both of those it too is a push-button and not a slider/switch. Further evidence can be found in the HUT extension HUTRR52 from Microsoft which adds rotation lock support to the HUT, which describes 2 different usages: "0xC9 System Display Rotation Lock Button" and "0xCA System Display Rotation Lock Slider Switch" note that switch is seen as a separate thing here and the non switch wording is an exact match for the "Windows-compatible button array" spec wording. TL;DR: our current mapping of the 5th GPIO to SW_ROTATE_LOCK is wrong because the 5th GPIO is for a push-button not a switch. This commit fixes this by maping the 5th GPIO to KEY_ROTATE_LOCK_TOGGLE. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 6d2817e2ab8c0f29ca603cb30a3e99c7fddb10ec Author: Ben Dooks Date: Wed Nov 21 16:13:19 2018 +0000 dmaengine: tegra: avoid overflow of byte tracking [ Upstream commit e486df39305864604b7e25f2a95d51039517ac57 ] The dma_desc->bytes_transferred counter tracks the number of bytes moved by the DMA channel. This is then used to calculate the information passed back in the in the tegra_dma_tx_status callback, which is usually fine. When the DMA channel is configured as continous, then the bytes_transferred counter will increase over time and eventually overflow to become negative so the residue count will become invalid and the ALSA sound-dma code will report invalid hardware pointer values to the application. This results in some users becoming confused about the playout position and putting audio data in the wrong place. To fix this issue, always ensure the bytes_transferred field is modulo the size of the request. We only do this for the case of the cyclic transfer done ISR as anyone attempting to move 2GiB of DMA data in one transfer is unlikely. Note, we don't fix the issue that we should /never/ transfer a negative number of bytes so we could make those fields unsigned. Reviewed-by: Dmitry Osipenko Signed-off-by: Ben Dooks Acked-by: Jon Hunter Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7386f095b7097f669dda3c4efd6ec47d7468ef83 Author: Katsuhiro Suzuki Date: Sun Dec 23 01:42:49 2018 +0900 clk: rockchip: fix frac settings of GPLL clock for rk3328 [ Upstream commit a0e447b0c50240a90ab84b7126b3c06b0bab4adc ] This patch fixes settings of GPLL frequency in fractional mode for rk3328. In this mode, FOUTVCO is calcurated by following formula: FOUTVCO = FREF * FBDIV / REFDIV + ((FREF * FRAC / REFDIV) >> 24) The problem is in FREF * FRAC >> 24 term. This result always lacks one from target value is specified by rate member. For example first itme of rk3328_pll_frac_rate originally has - rate : 1016064000 - refdiv: 3 - fbdiv : 127 - frac : 134217 - FREF * FBDIV / REFDIV = 1016000000 - (FREF * FRAC / REFDIV) >> 24 = 63999 Thus calculated rate is 1016063999. It seems wrong. If frac has 134218 (it is increased 1 from original value), second term is 64000. All other items have same situation. So this patch adds 1 to frac member in all items of rk3328_pll_frac_rate. Signed-off-by: Katsuhiro Suzuki Acked-by: Elaine Zhang Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit c8e4f8406842332fb55cd792016e5dac266f6354 Author: Jerome Brunet Date: Fri Dec 21 17:02:36 2018 +0100 clk: meson: clean-up clock registration [ Upstream commit 8d9981efbcab066d17af4d3c85c169200f6f78df ] Order, ids and size between the table of regmap clocks and the onecell data table could be different. Set regmap pointer in all the regmap clocks before starting the registration using the onecell data, to make sure we don't get into an incoherent situation. Signed-off-by: Jerome Brunet Acked-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lkml.kernel.org/r/20181221160239.26265-3-jbrunet@baylibre.com Signed-off-by: Sasha Levin commit 6251c1db04f2ac1ef799763da0f2fa1821dde403 Author: Peter Wu Date: Sun Dec 23 01:55:07 2018 +0100 drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup [ Upstream commit 00eb5b0da8d27b3c944bfc959c3344d665caae26 ] After drm_fb_helper_fbdev_setup calls drm_fb_helper_init, "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will have some effect). After that, drm_fb_helper_initial_config is called which may call the "fb_probe" driver callback. This driver callback may call drm_fb_helper_defio_init (as is done by drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs) as documented. These are normally cleaned up on exit by drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini. If an error occurs after "fb_probe", but before setup is complete, then calling just drm_fb_helper_fini will leak resources. This was triggered by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"): [ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this framebuffer [ 50.009436] bochs-drm 0000:00:02.0: [drm:drm_fb_helper_fbdev_setup] *ERROR* fbdev: Failed to set configuration (ret=-38) [ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 2 [ 50.013604] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0 [ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G T 4.20.0-rc7 #1 [ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0 ... [ 50.023155] Call Trace: [ 50.023155] ? bochs_kms_fini+0x1e/0x30 [ 50.023155] ? bochs_unload+0x18/0x40 This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n. Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian Link: https://lkml.kernel.org/r/20181223004315.GA11455@al Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()") Reported-by: kernel test robot Cc: Noralf Trønnes Signed-off-by: Peter Wu Reviewed-by: Noralf Trønnes Signed-off-by: Noralf Trønnes Link: https://patchwork.freedesktop.org/patch/msgid/20181223005507.28328-1-peter@lekensteyn.nl Signed-off-by: Sasha Levin commit 648b949b787095aa7e34e5f9c209c9f85a5f194c Author: Rafael Ávila de Espíndola Date: Wed Dec 19 11:01:43 2018 -0800 x86/build: Mark per-CPU symbols as absolute explicitly for LLD [ Upstream commit d071ae09a4a1414c1433d5ae9908959a7325b0ad ] Accessing per-CPU variables is done by finding the offset of the variable in the per-CPU block and adding it to the address of the respective CPU's block. Section 3.10.8 of ld.bfd's documentation states: For expressions involving numbers, relative addresses and absolute addresses, ld follows these rules to evaluate terms: Other binary operations, that is, between two relative addresses not in the same section, or between a relative address and an absolute address, first convert any non-absolute term to an absolute address before applying the operator." Note that LLVM's linker does not adhere to the GNU ld's implementation and as such requires implicitly-absolute terms to be explicitly marked as absolute in the linker script. If not, it fails currently with: ld.lld: error: ./arch/x86/kernel/vmlinux.lds:153: at least one side of the expression must be absolute ld.lld: error: ./arch/x86/kernel/vmlinux.lds:154: at least one side of the expression must be absolute Makefile:1040: recipe for target 'vmlinux' failed This is not a functional change for ld.bfd which converts the term to an absolute symbol anyways as specified above. Based on a previous submission by Tri Vo . Reported-by: Dmitry Golovin Signed-off-by: Rafael Ávila de Espíndola [ Update commit message per Boris' and Michael's suggestions. ] Signed-off-by: Nick Desaulniers [ Massage commit message more, fix typos. ] Signed-off-by: Borislav Petkov Tested-by: Dmitry Golovin Cc: "H. Peter Anvin" Cc: Andy Lutomirski Cc: Brijesh Singh Cc: Cao Jin Cc: Ingo Molnar Cc: Joerg Roedel Cc: Masahiro Yamada Cc: Masami Hiramatsu Cc: Thomas Gleixner Cc: Tri Vo Cc: dima@golovin.in Cc: morbo@google.com Cc: x86-ml Link: https://lkml.kernel.org/r/20181219190145.252035-1-ndesaulniers@google.com Signed-off-by: Sasha Levin commit 52cd9e0e43c7bda1621a2ce66765a4a369967caf Author: Zumeng Chen Date: Wed Dec 19 15:50:29 2018 +0800 wlcore: Fix memory leak in case wl12xx_fetch_firmware failure [ Upstream commit ba2ffc96321c8433606ceeb85c9e722b8113e5a7 ] Release fw_status, raw_fw_status, and tx_res_if when wl12xx_fetch_firmware failed instead of meaningless goto out to avoid the following memory leak reports(Only the last one listed): unreferenced object 0xc28a9a00 (size 512): comm "kworker/0:4", pid 31298, jiffies 2783204 (age 203.290s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<6624adab>] kmemleak_alloc+0x40/0x74 [<500ddb31>] kmem_cache_alloc_trace+0x1ac/0x270 [] wl12xx_chip_wakeup+0xc4/0x1fc [wlcore] [<76c5db53>] wl1271_op_add_interface+0x4a4/0x8f4 [wlcore] [] drv_add_interface+0xa4/0x1a0 [mac80211] [<65bac325>] ieee80211_reconfig+0x9c0/0x1644 [mac80211] [<2817c80e>] ieee80211_restart_work+0x90/0xc8 [mac80211] [<7e1d425a>] process_one_work+0x284/0x42c [<55f9432e>] worker_thread+0x2fc/0x48c [] kthread+0x148/0x160 [<63144b13>] ret_from_fork+0x14/0x2c [< (null)>] (null) [<1f6e7715>] 0xffffffff Signed-off-by: Zumeng Chen Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 05b23c66bb6e96720b3d6b0e9ebb2ee693e8d9f5 Author: Hans de Goede Date: Mon Jan 7 14:33:27 2019 +0100 brcmfmac: Use firmware_request_nowarn for the clm_blob [ Upstream commit 4ad0be160544ffbdafb7cec39bb8e6dd0a97317a ] The linux-firmware brcmfmac firmware files contain an embedded table with per country allowed channels and strength info. For recent hardware these versions of the firmware are specially build for linux-firmware, the firmware files directly available from Cypress rely on a separate clm_blob file for this info. For some unknown reason Cypress refuses to provide the standard firmware files + clm_blob files it uses elsewhere for inclusion into linux-firmware, instead relying on these special builds with the clm_blob info embedded. This means that the linux-firmware firmware versions often lag behind, but I digress. The brcmfmac driver does support the separate clm_blob file and always tries to load this. Currently we use request_firmware for this. This means that on any standard install, using the standard combo of linux-kernel + linux-firmware, we will get a warning: "Direct firmware load for ... failed with error -2" On top of this, brcmfmac itself prints: "no clm_blob available (err=-2), device may have limited channels available". This commit switches to firmware_request_nowarn, fixing almost any brcmfmac device logging the warning (it leaves the brcmfmac info message in place). Signed-off-by: Hans de Goede Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit e30e0b0915b67e28799f31e43ab3ead79a368ded Author: Ondrej Mosnacek Date: Fri Dec 21 21:18:53 2018 +0100 selinux: do not override context on context mounts [ Upstream commit 53e0c2aa9a59a48e3798ef193d573ade85aa80f5 ] Ignore all selinux_inode_notifysecctx() calls on mounts with SBLABEL_MNT flag unset. This is achived by returning -EOPNOTSUPP for this case in selinux_inode_setsecurtity() (because that function should not be called in such case anyway) and translating this error to 0 in selinux_inode_notifysecctx(). This fixes behavior of kernfs-based filesystems when mounted with the 'context=' option. Before this patch, if a node's context had been explicitly set to a non-default value and later the filesystem has been remounted with the 'context=' option, then this node would show up as having the manually-set context and not the mount-specified one. Steps to reproduce: # mount -t cgroup2 cgroup2 /sys/fs/cgroup/unified # chcon unconfined_u:object_r:user_home_t:s0 /sys/fs/cgroup/unified/cgroup.stat # ls -lZ /sys/fs/cgroup/unified total 0 -r--r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.controllers -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.max.depth -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.max.descendants -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.procs -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.subtree_control -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0 0 Dec 13 10:41 cgroup.threads # umount /sys/fs/cgroup/unified # mount -o context=system_u:object_r:tmpfs_t:s0 -t cgroup2 cgroup2 /sys/fs/cgroup/unified Result before: # ls -lZ /sys/fs/cgroup/unified total 0 -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.controllers -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.depth -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.descendants -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.procs -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.subtree_control -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.threads Result after: # ls -lZ /sys/fs/cgroup/unified total 0 -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.controllers -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.depth -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.descendants -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.procs -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.stat -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.subtree_control -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.threads Signed-off-by: Ondrej Mosnacek Reviewed-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit d2053718e08769c14e704bfd1cb4d91f944ad9bf Author: George Rimar Date: Fri Jan 11 12:10:12 2019 -0800 x86/build: Specify elf_i386 linker emulation explicitly for i386 objects [ Upstream commit 927185c124d62a9a4d35878d7f6d432a166b74e3 ] The kernel uses the OUTPUT_FORMAT linker script command in it's linker scripts. Most of the time, the -m option is passed to the linker with correct architecture, but sometimes (at least for x86_64) the -m option contradicts the OUTPUT_FORMAT directive. Specifically, arch/x86/boot and arch/x86/realmode/rm produce i386 object files, but are linked with the -m elf_x86_64 linker flag when building for x86_64. The GNU linker manpage doesn't explicitly state any tie-breakers between -m and OUTPUT_FORMAT. But with BFD and Gold linkers, OUTPUT_FORMAT overrides the emulation value specified with the -m option. LLVM lld has a different behavior, however. When supplied with contradicting -m and OUTPUT_FORMAT values it fails with the following error message: ld.lld: error: arch/x86/realmode/rm/header.o is incompatible with elf_x86_64 Therefore, just add the correct -m after the incorrect one (it overrides it), so the linker invocation looks like this: ld -m elf_x86_64 -z max-page-size=0x200000 -m elf_i386 --emit-relocs -T \ realmode.lds header.o trampoline_64.o stack.o reboot.o -o realmode.elf This is not a functional change for GNU ld, because (although not explicitly documented) OUTPUT_FORMAT overrides -m EMULATION. Tested by building x86_64 kernel with GNU gcc/ld toolchain and booting it in QEMU. [ bp: massage and clarify text. ] Suggested-by: Dmitry Golovin Signed-off-by: George Rimar Signed-off-by: Tri Vo Signed-off-by: Borislav Petkov Tested-by: Tri Vo Tested-by: Nick Desaulniers Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Michael Matz Cc: Thomas Gleixner Cc: morbo@google.com Cc: ndesaulniers@google.com Cc: ruiu@google.com Cc: x86-ml Link: https://lkml.kernel.org/r/20190111201012.71210-1-trong@android.com Signed-off-by: Sasha Levin commit e0662d00c98a5d7defce2a2a24e7f00d6edbfcc6 Author: Daniel Vetter Date: Mon Dec 17 20:42:58 2018 +0100 drm/nouveau: Stop using drm_crtc_force_disable [ Upstream commit 934c5b32a5e43d8de2ab4f1566f91d7c3bf8cb64 ] The correct way for legacy drivers to update properties that need to do a full modeset, is to do a full modeset. Note that we don't need to call the drm_mode_config_internal helper because we're not changing any of the refcounted paramters. v2: Fixup error handling (Ville). Since the old code didn't bother I decided to just delete it instead of adding even more code for just error handling. Cc: Ville Syrjälä Reviewed-by: Alex Deucher (v1) Cc: Sean Paul Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181217194303.14397-2-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 1d377200482b570b55ea4340bed85377c929eac5 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init [ Upstream commit 890880ddfdbe256083170866e49c87618b706ac7 ] When drivers pass non-empty lists of modifiers for initializing their planes, we can infer that they allow framebuffer modifiers and set the driver's allow_fb_modifiers mode config element. In case the allow_fb_modifiers element was not set (some drivers tend to set them after registering planes), the modifiers will still be registered but won't be available to userspace unless the flag is set later. However in that case, the IN_FORMATS blob won't be created. In order to avoid this case and generally reduce the trouble associated with the flag, always set allow_fb_modifiers when a non-empty list of format modifiers is passed at plane init. Reviewed-by: Daniel Vetter Signed-off-by: Paul Kocialkowski Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20190104085610.5829-1-paul.kocialkowski@bootlin.com Signed-off-by: Sasha Levin commit 27d6de370cdc6ceabdae7e11547910db28cfe7c4 Author: Martin Blumenstingl Date: Sat Jan 12 13:59:13 2019 +0100 pinctrl: meson: meson8b: add the eth_rxd2 and eth_rxd3 pins [ Upstream commit 6daae00243e622dd3feec7965bfe421ad6dd317e ] Gigabit Ethernet requires the Ethernet TXD0..3 and RXD0..3 data lines. Add the missing eth_rxd2 and eth_rxd3 definitions so we don't have to rely on the bootloader to set them up correctly. The vendor u-boot sources for Odroid-C1 use the following Ethernet pinmux configuration: SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_6, 0x3f4f); SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_7, 0xf00000); This translates to the following pin groups in the mainline kernel: - register 6 bit 0: eth_rxd1 (DIF_0_P) - register 6 bit 1: eth_rxd0 (DIF_0_N) - register 6 bit 2: eth_rx_dv (DIF_1_P) - register 6 bit 3: eth_rx_clk (DIF_1_N) - register 6 bit 6: eth_tx_en (DIF_3_P) - register 6 bit 8: eth_ref_clk (DIF_3_N) - register 6 bit 9: eth_mdc (DIF_4_P) - register 6 bit 10: eth_mdio_en (DIF_4_N) - register 6 bit 11: eth_tx_clk (GPIOH_9) - register 6 bit 12: eth_txd2 (GPIOH_8) - register 6 bit 13: eth_txd3 (GPIOH_7) - register 7 bit 20: eth_txd0_0 (GPIOH_6) - register 7 bit 21: eth_txd1_0 (GPIOH_5) - register 7 bit 22: eth_rxd3 (DIF_2_P) - register 7 bit 23: eth_rxd2 (DIF_2_N) All functions except eth_rxd2 and eth_rxd3 are already supported by the pinctrl-meson8b driver. Suggested-by: Jianxin Pan Signed-off-by: Martin Blumenstingl Reviewed-by: Kevin Hilman Tested-by: Emiliano Ingrassia Reviewed-by: Emiliano Ingrassia Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 61174e34611f52346fb714c98849803971996c56 Author: Axel Lin Date: Thu Jan 10 17:26:16 2019 +0800 regulator: act8865: Fix act8600_sudcdc_voltage_ranges setting [ Upstream commit f01a7beb6791f1c419424c1a6958b7d0a289c974 ] The act8600_sudcdc_voltage_ranges setting does not match the datasheet. The problems in below entry: REGULATOR_LINEAR_RANGE(19000000, 191, 255, 400000), 1. The off-by-one min_sel causes wrong volatage calculation. The min_sel should be 192. 2. According to the datasheet[1] Table 7. (on page 43): The selector 248 (0b11111000) ~ 255 (0b11111111) are 41.400V. Also fix off-by-one for ACT8600_SUDCDC_VOLTAGE_NUM. [1] https://active-semi.com/wp-content/uploads/ACT8600_Datasheet.pdf Fixes: df3a950e4e73 ("regulator: act8865: Add act8600 support") Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bcdd4a5ee1c5a37eaf0ab209fe38961dd49a00a0 Author: Pawe? Chmiel Date: Sat Dec 29 10:46:01 2018 -0500 media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumeration [ Upstream commit 49710c32cd9d6626a77c9f5f978a5f58cb536b35 ] Previously when doing format enumeration, it was returning all formats supported by driver, even if they're not supported by hw. Add missing check for fmt_ver_flag, so it'll be fixed and only those supported by hw will be returned. Similar thing is already done in s5p_jpeg_find_format. It was found by using v4l2-compliance tool and checking result of VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS test and using v4l2-ctl to get list of all supported formats. Tested on s5pv210-galaxys (Samsung i9000 phone). Fixes: bb677f3ac434 ("[media] Exynos4 JPEG codec v4l2 driver") Signed-off-by: Pawe? Chmiel Reviewed-by: Jacek Anaszewski [hverkuil-cisco@xs4all.nl: fix a few alignment issues] Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9bfd4ab5e8e43644b95d73891f2ddd5e01378306 Author: Steve Longerbeam Date: Mon Jan 14 20:10:19 2019 -0500 media: rcar-vin: Allow independent VIN link enablement [ Upstream commit c5ff0edb8e2270a75935c73217fb0de1abd2d910 ] There is a block of code in rvin_group_link_notify() that prevents enabling a link to a VIN node if any entity in the media graph is in use. This prevents enabling a VIN link even if there is an in-use entity somewhere in the graph that is independent of the link's pipeline. For example, the code block will prevent enabling a link from the first rcar-csi2 receiver to a VIN node even if there is an enabled link somewhere far upstream on the second independent rcar-csi2 receiver pipeline. If this code block is meant to prevent modifying a link if any entity in the graph is actively involved in streaming (because modifying the CHSEL register fields can disrupt any/all running streams), then the entities stream counts should be checked rather than the use counts. (There is already such a check in __media_entity_setup_link() that verifies the stream_count of the link's source and sink entities are both zero, but that is insufficient, since there should be no running streams in the entire graph). Modify the code block to check the entity stream_count instead of the use_count (and elaborate on the comment). VIN node links can now be enabled even if there are other independent in-use entities that are not streaming. Fixes: c0cc5aef31 ("media: rcar-vin: add link notify for Gen3") Signed-off-by: Steve Longerbeam Reviewed-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2e6bcc327b0b4e64b5cff2a11427bcd046e06a70 Author: Florian Westphal Date: Fri Jan 11 14:46:15 2019 +0100 netfilter: physdev: relax br_netfilter dependency [ Upstream commit 8e2f311a68494a6677c1724bdcb10bada21af37c ] Following command: iptables -D FORWARD -m physdev ... causes connectivity loss in some setups. Reason is that iptables userspace will probe kernel for the module revision of the physdev patch, and physdev has an artificial dependency on br_netfilter (xt_physdev use makes no sense unless a br_netfilter module is loaded). This causes the "phydev" module to be loaded, which in turn enables the "call-iptables" infrastructure. bridged packets might then get dropped by the iptables ruleset. The better fix would be to change the "call-iptables" defaults to 0 and enforce explicit setting to 1, but that breaks backwards compatibility. This does the next best thing: add a request_module call to checkentry. This was a stray '-D ... -m physdev' won't activate br_netfilter anymore. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 24296fbc5445d8497382a8a802a5fa6819cbe014 Author: Shunyong Yang Date: Mon Jan 7 09:32:14 2019 +0800 dmaengine: qcom_hidma: initialize tx flags in hidma_prep_dma_* [ Upstream commit 875aac8a46424e5b73a9ff7f40b83311b609e407 ] In async_tx_test_ack(), it uses flags in struct dma_async_tx_descriptor to check the ACK status. As hidma reuses the descriptor in a free list when hidma_prep_dma_*(memcpy/memset) is called, the flag will keep ACKed if the descriptor has been used before. This will cause a BUG_ON in async_tx_quiesce(). kernel BUG at crypto/async_tx/async_tx.c:282! Internal error: Oops - BUG: 0 1 SMP ... task: ffff8017dd3ec000 task.stack: ffff8017dd3e8000 PC is at async_tx_quiesce+0x54/0x78 [async_tx] LR is at async_trigger_callback+0x98/0x110 [async_tx] This patch initializes flags in dma_async_tx_descriptor by the flags passed from the caller when hidma_prep_dma_*(memcpy/memset) is called. Cc: Joey Zheng Reviewed-by: Sinan Kaya Signed-off-by: Shunyong Yang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c55f4a6e798dad7383f4e4f99d351d6016e943a2 Author: Shunyong Yang Date: Mon Jan 7 09:34:02 2019 +0800 dmaengine: qcom_hidma: assign channel cookie correctly [ Upstream commit 546c0547555efca8ba8c120716c325435e29df1b ] When dma_cookie_complete() is called in hidma_process_completed(), dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then, hidma_txn_is_success() will be called to use channel cookie mchan->last_success to do additional DMA status check. Current code assigns mchan->last_success after dma_cookie_complete(). This causes a race condition of dma_cookie_status() returns DMA_COMPLETE before mchan->last_success is assigned correctly. The race will cause hidma_tx_status() return DMA_ERROR but the transaction is actually a success. Moreover, in async_tx case, it will cause a timeout panic in async_tx_quiesce(). Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction ... Call trace: [] dump_backtrace+0x0/0x1f4 [] show_stack+0x24/0x2c [] dump_stack+0x84/0xa8 [] panic+0x12c/0x29c [] async_tx_quiesce+0xa4/0xc8 [async_tx] [] async_trigger_callback+0x70/0x1c0 [async_tx] [] raid_run_ops+0x86c/0x1540 [raid456] [] handle_stripe+0x5e8/0x1c7c [raid456] [] handle_active_stripes.isra.45+0x2d4/0x550 [raid456] [] raid5d+0x38c/0x5d0 [raid456] [] md_thread+0x108/0x168 [] kthread+0x10c/0x138 [] ret_from_fork+0x10/0x18 Cc: Joey Zheng Reviewed-by: Sinan Kaya Signed-off-by: Shunyong Yang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit afacaf85543bc422343a525d07e5cae32782c1cb Author: Anders Roxell Date: Thu Jan 10 12:15:35 2019 +0100 dmaengine: imx-dma: fix warning comparison of distinct pointer types [ Upstream commit 9227ab5643cb8350449502dd9e3168a873ab0e3b ] The warning got introduced by commit 930507c18304 ("arm64: add basic Kconfig symbols for i.MX8"). Since it got enabled for arm64. The warning haven't been seen before since size_t was 'unsigned int' when built on arm32. ../drivers/dma/imx-dma.c: In function ‘imxdma_sg_next’: ../include/linux/kernel.h:846:29: warning: comparison of distinct pointer types lacks a cast (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^~ ../include/linux/kernel.h:860:4: note: in expansion of macro ‘__typecheck’ (__typecheck(x, y) && __no_side_effects(x, y)) ^~~~~~~~~~~ ../include/linux/kernel.h:870:24: note: in expansion of macro ‘__safe_cmp’ __builtin_choose_expr(__safe_cmp(x, y), \ ^~~~~~~~~~ ../include/linux/kernel.h:879:19: note: in expansion of macro ‘__careful_cmp’ #define min(x, y) __careful_cmp(x, y, <) ^~~~~~~~~~~~~ ../drivers/dma/imx-dma.c:288:8: note: in expansion of macro ‘min’ now = min(d->len, sg_dma_len(sg)); ^~~ Rework so that we use min_t and pass in the size_t that returns the minimum of two values, using the specified type. Signed-off-by: Anders Roxell Acked-by: Olof Johansson Reviewed-by: Fabio Estevam Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit fba4c61e9888ce5735495bd6480ea80791fecd1f Author: Valentin Schneider Date: Wed Dec 19 18:23:15 2018 +0000 cpu/hotplug: Mute hotplug lockdep during init [ Upstream commit ce48c457b95316b9a01b5aa9d4456ce820df94b4 ] Since we've had: commit cb538267ea1e ("jump_label/lockdep: Assert we hold the hotplug lock for _cpuslocked() operations") we've been getting some lockdep warnings during init, such as on HiKey960: [ 0.820495] WARNING: CPU: 4 PID: 0 at kernel/cpu.c:316 lockdep_assert_cpus_held+0x3c/0x48 [ 0.820498] Modules linked in: [ 0.820509] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G S 4.20.0-rc5-00051-g4cae42a #34 [ 0.820511] Hardware name: HiKey960 (DT) [ 0.820516] pstate: 600001c5 (nZCv dAIF -PAN -UAO) [ 0.820520] pc : lockdep_assert_cpus_held+0x3c/0x48 [ 0.820523] lr : lockdep_assert_cpus_held+0x38/0x48 [ 0.820526] sp : ffff00000a9cbe50 [ 0.820528] x29: ffff00000a9cbe50 x28: 0000000000000000 [ 0.820533] x27: 00008000b69e5000 x26: ffff8000bff4cfe0 [ 0.820537] x25: ffff000008ba69e0 x24: 0000000000000001 [ 0.820541] x23: ffff000008fce000 x22: ffff000008ba70c8 [ 0.820545] x21: 0000000000000001 x20: 0000000000000003 [ 0.820548] x19: ffff00000a35d628 x18: ffffffffffffffff [ 0.820552] x17: 0000000000000000 x16: 0000000000000000 [ 0.820556] x15: ffff00000958f848 x14: 455f3052464d4d34 [ 0.820559] x13: 00000000769dde98 x12: ffff8000bf3f65a8 [ 0.820564] x11: 0000000000000000 x10: ffff00000958f848 [ 0.820567] x9 : ffff000009592000 x8 : ffff00000958f848 [ 0.820571] x7 : ffff00000818ffa0 x6 : 0000000000000000 [ 0.820574] x5 : 0000000000000000 x4 : 0000000000000001 [ 0.820578] x3 : 0000000000000000 x2 : 0000000000000001 [ 0.820582] x1 : 00000000ffffffff x0 : 0000000000000000 [ 0.820587] Call trace: [ 0.820591] lockdep_assert_cpus_held+0x3c/0x48 [ 0.820598] static_key_enable_cpuslocked+0x28/0xd0 [ 0.820606] arch_timer_check_ool_workaround+0xe8/0x228 [ 0.820610] arch_timer_starting_cpu+0xe4/0x2d8 [ 0.820615] cpuhp_invoke_callback+0xe8/0xd08 [ 0.820619] notify_cpu_starting+0x80/0xb8 [ 0.820625] secondary_start_kernel+0x118/0x1d0 We've also had a similar warning in sched_init_smp() for every asymmetric system that would enable the sched_asym_cpucapacity static key, although that was singled out in: commit 40fa3780bac2 ("sched/core: Take the hotplug lock in sched_init_smp()") Those warnings are actually harmless, since we cannot have hotplug operations at the time they appear. Instead of starting to sprinkle useless hotplug lock operations in the init codepaths, mute the warnings until they start warning about real problems. Suggested-by: Peter Zijlstra Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Thomas Gleixner Cc: Will Deacon Cc: cai@gmx.us Cc: daniel.lezcano@linaro.org Cc: dietmar.eggemann@arm.com Cc: linux-arm-kernel@lists.infradead.org Cc: longman@redhat.com Cc: marc.zyngier@arm.com Cc: mark.rutland@arm.com Link: https://lkml.kernel.org/r/1545243796-23224-2-git-send-email-valentin.schneider@arm.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit a6c671e23168eceefc66be118700a23484dd52e5 Author: Buland Singh Date: Thu Dec 20 17:35:24 2018 +0530 hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable [ Upstream commit 24d48a61f2666630da130cc2ec2e526eacf229e3 ] Commit '3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for user processes")' introduced a new kernel command line parameter hpet_mmap, that is required to expose the memory map of the HPET registers to user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is broken and never takes effect due to missing '=' character in the __setup() code of hpet_mmap_enable. Before this patch: dmesg output with the kernel command line parameter hpet_mmap=1 [ 0.204152] HPET mmap disabled dmesg output with the kernel command line parameter hpet_mmap=0 [ 0.204192] HPET mmap disabled After this patch: dmesg output with the kernel command line parameter hpet_mmap=1 [ 0.203945] HPET mmap enabled dmesg output with the kernel command line parameter hpet_mmap=0 [ 0.204652] HPET mmap disabled Fixes: 3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for user processes") Signed-off-by: Buland Singh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dbeca415575f2cbeb4594ab63fa83d97987994c1 Author: Sheng Yong Date: Tue Jan 15 20:02:15 2019 +0000 f2fs: UBSAN: set boolean value iostat_enable correctly [ Upstream commit ac92985864e187a1735502f6a02f54eaa655b2aa ] When setting /sys/fs/f2fs//iostat_enable with non-bool value, UBSAN reports the following warning. [ 7562.295484] ================================================================================ [ 7562.296531] UBSAN: Undefined behaviour in fs/f2fs/f2fs.h:2776:10 [ 7562.297651] load of value 64 is not a valid value for type '_Bool' [ 7562.298642] CPU: 1 PID: 7487 Comm: dd Not tainted 4.20.0-rc4+ #79 [ 7562.298653] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 7562.298662] Call Trace: [ 7562.298760] dump_stack+0x46/0x5b [ 7562.298811] ubsan_epilogue+0x9/0x40 [ 7562.298830] __ubsan_handle_load_invalid_value+0x72/0x90 [ 7562.298863] f2fs_file_write_iter+0x29f/0x3f0 [ 7562.298905] __vfs_write+0x115/0x160 [ 7562.298922] vfs_write+0xa7/0x190 [ 7562.298934] ksys_write+0x50/0xc0 [ 7562.298973] do_syscall_64+0x4a/0xe0 [ 7562.298992] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 7562.299001] RIP: 0033:0x7fa45ec19c00 [ 7562.299004] Code: 73 01 c3 48 8b 0d 88 92 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d dd eb 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 24 [ 7562.299044] RSP: 002b:00007ffca52b49e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 7562.299052] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa45ec19c00 [ 7562.299059] RDX: 0000000000000400 RSI: 000000000093f000 RDI: 0000000000000001 [ 7562.299065] RBP: 000000000093f000 R08: 0000000000000004 R09: 0000000000000000 [ 7562.299071] R10: 00007ffca52b47b0 R11: 0000000000000246 R12: 0000000000000400 [ 7562.299077] R13: 000000000093f000 R14: 000000000093f400 R15: 0000000000000000 [ 7562.299091] ================================================================================ So, if iostat_enable is enabled, set its value as true. Signed-off-by: Sheng Yong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 16b06b15dd53a33d9d289069429cf8d877303d9c Author: Song Hongyan Date: Tue Jan 22 09:06:26 2019 +0800 HID: intel-ish: ipc: handle PIMR before ish_wakeup also clear PISR busy_clear bit [ Upstream commit 2edefc056e4f0e6ec9508dd1aca2c18fa320efef ] Host driver should handle interrupt mask register earlier than wake up ish FW else there will be conditions when FW interrupt comes, host PIMR register still not set ready, so move the interrupt mask setting before ish_wakeup. Clear PISR busy_clear bit in ish_irq_handler. If not clear, there will be conditions host driver received a busy_clear interrupt (before the busy_clear mask bit is ready), it will return IRQ_NONE after check_generated_interrupt, the interrupt will never be cleared, causing the DEVICE not sending following IRQ. Since PISR clear should not be called for the CHV device we do this change. After the change, both ISH2HOST interrupt and busy_clear interrupt will be considered as interrupt from ISH, busy_clear interrupt will return IRQ_HANDLED from IPC_IS_BUSY check. Signed-off-by: Song Hongyan Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 67c2be160519423490e91c24d5ae967d5471622f Author: Timo Alho Date: Sun Dec 30 17:58:08 2018 +0200 soc/tegra: fuse: Fix illegal free of IO base address [ Upstream commit 51294bf6b9e897d595466dcda5a3f2751906a200 ] On cases where device tree entries for fuse and clock provider are in different order, fuse driver needs to defer probing. This leads to freeing incorrect IO base address as the fuse->base variable gets overwritten once during first probe invocation. This leads to the following spew during boot: [ 3.082285] Trying to vfree() nonexistent vm area (00000000cfe8fd94) [ 3.082308] WARNING: CPU: 5 PID: 126 at /hdd/l4t/kernel/stable/mm/vmalloc.c:1511 __vunmap+0xcc/0xd8 [ 3.082318] Modules linked in: [ 3.082330] CPU: 5 PID: 126 Comm: kworker/5:1 Tainted: G S 4.19.7-tegra-gce119d3 #1 [ 3.082340] Hardware name: quill (DT) [ 3.082353] Workqueue: events deferred_probe_work_func [ 3.082364] pstate: 40000005 (nZcv daif -PAN -UAO) [ 3.082372] pc : __vunmap+0xcc/0xd8 [ 3.082379] lr : __vunmap+0xcc/0xd8 [ 3.082385] sp : ffff00000a1d3b60 [ 3.082391] x29: ffff00000a1d3b60 x28: 0000000000000000 [ 3.082402] x27: 0000000000000000 x26: ffff000008e8b610 [ 3.082413] x25: 0000000000000000 x24: 0000000000000009 [ 3.082423] x23: ffff000009221a90 x22: ffff000009f6d000 [ 3.082432] x21: 0000000000000000 x20: 0000000000000000 [ 3.082442] x19: ffff000009f6d000 x18: ffffffffffffffff [ 3.082452] x17: 0000000000000000 x16: 0000000000000000 [ 3.082462] x15: ffff0000091396c8 x14: 0720072007200720 [ 3.082471] x13: 0720072007200720 x12: 0720072907340739 [ 3.082481] x11: 0764076607380765 x10: 0766076307300730 [ 3.082491] x9 : 0730073007300730 x8 : 0730073007280720 [ 3.082501] x7 : 0761076507720761 x6 : 0000000000000102 [ 3.082510] x5 : 0000000000000000 x4 : 0000000000000000 [ 3.082519] x3 : ffffffffffffffff x2 : ffff000009150ff8 [ 3.082528] x1 : 3d95b1429fff5200 x0 : 0000000000000000 [ 3.082538] Call trace: [ 3.082545] __vunmap+0xcc/0xd8 [ 3.082552] vunmap+0x24/0x30 [ 3.082561] __iounmap+0x2c/0x38 [ 3.082569] tegra_fuse_probe+0xc8/0x118 [ 3.082577] platform_drv_probe+0x50/0xa0 [ 3.082585] really_probe+0x1b0/0x288 [ 3.082593] driver_probe_device+0x58/0x100 [ 3.082601] __device_attach_driver+0x98/0xf0 [ 3.082609] bus_for_each_drv+0x64/0xc8 [ 3.082616] __device_attach+0xd8/0x130 [ 3.082624] device_initial_probe+0x10/0x18 [ 3.082631] bus_probe_device+0x90/0x98 [ 3.082638] deferred_probe_work_func+0x74/0xb0 [ 3.082649] process_one_work+0x1e0/0x318 [ 3.082656] worker_thread+0x228/0x450 [ 3.082664] kthread+0x128/0x130 [ 3.082672] ret_from_fork+0x10/0x18 [ 3.082678] ---[ end trace 0810fe6ba772c1c7 ]--- Fix this by retaining the value of fuse->base until driver has successfully probed. Signed-off-by: Timo Alho Acked-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit a3aa9d93b9ab68ca76956f2425805ede49d125cd Author: David Tolnay Date: Mon Jan 7 14:36:11 2019 -0800 hwrng: virtio - Avoid repeated init of completion [ Upstream commit aef027db48da56b6f25d0e54c07c8401ada6ce21 ] The virtio-rng driver uses a completion called have_data to wait for a virtio read to be fulfilled by the hypervisor. The completion is reset before placing a buffer on the virtio queue and completed by the virtio callback once data has been written into the buffer. Prior to this commit, the driver called init_completion on this completion both during probe as well as when registering virtio buffers as part of a hwrng read operation. The second of these init_completion calls should instead be reinit_completion because the have_data completion has already been inited by probe. As described in Documentation/scheduler/completion.txt, "Calling init_completion() twice on the same completion object is most likely a bug". This bug was present in the initial implementation of virtio-rng in f7f510ec1957 ("virtio: An entropy device, as suggested by hpa"). Back then the have_data completion was a single static completion rather than a member of one of potentially multiple virtrng_info structs as implemented later by 08e53fbdb85c ("virtio-rng: support multiple virtio-rng devices"). The original driver incorrectly used init_completion rather than INIT_COMPLETION to reset have_data during read. Tested by running `head -c48 /dev/random | hexdump` within crosvm, the Chrome OS virtual machine monitor, and confirming that the virtio-rng driver successfully produces random bytes from the host. Signed-off-by: David Tolnay Tested-by: David Tolnay Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7aaa76e8a6abc787ffd8f40f39bf406762090641 Author: Akinobu Mita Date: Tue Jan 15 12:05:41 2019 -0200 media: mt9m111: set initial frame size other than 0x0 [ Upstream commit 29856308137de1c21eda89411695f4fc6e9780ff ] This driver sets initial frame width and height to 0x0, which is invalid. So set it to selection rectangle bounds instead. This is detected by v4l2-compliance detected. Cc: Enrico Scholz Cc: Michael Grzeschik Cc: Marco Felsch Signed-off-by: Akinobu Mita Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fd400e96c599940e4bbbda29d436efc4d4e035c3 Author: Tony Jones Date: Wed Jan 23 16:52:24 2019 -0800 perf script python: Add trace_context extension module to sys.modules [ Upstream commit cc437642255224e4140fed1f3e3156fc8ad91903 ] In Python3, the result of PyModule_Create (called from scripts/python/Perf-Trace-Util/Context.c) is not automatically added to sys.modules. See: https://bugs.python.org/issue4592 Below is the observed behavior without the fix: # ldd /usr/bin/perf | grep -i python libpython3.6m.so.1.0 => /usr/lib64/libpython3.6m.so.1.0 (0x00007f8e1dfb2000) # perf record /bin/false [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.015 MB perf.data (17 samples) ] # perf script -g python | cat generated Python script: perf-script.py # perf script -s ./perf-script.py Traceback (most recent call last): File "./perf-script.py", line 18, in from perf_trace_context import * ModuleNotFoundError: No module named 'perf_trace_context' Error running python script ./perf-script.py # Committer notes: To build with python3 use: $ make -C tools/perf PYTHON=python3 Use a non-const variable to pass the 'name' arg to PyImport_AppendInittab(), as python2.6 has that as 'char *', which ends up trowing this in some environments: CC /tmp/build/perf/util/parse-branch-options.o util/scripting-engines/trace-event-python.c: In function 'python_start_script': util/scripting-engines/trace-event-python.c:1520:2: error: passing argument 1 of 'PyImport_AppendInittab' discards 'const' qualifier from pointer target type [-Werror] PyImport_AppendInittab("perf_trace_context", initfunc); ^ In file included from /usr/include/python2.6/Python.h:130:0, from util/scripting-engines/trace-event-python.c:22: /usr/include/python2.6/import.h:54:17: note: expected 'char *' but argument is of type 'const char *' PyAPI_FUNC(int) PyImport_AppendInittab(char *name, void (*initfunc)(void)); ^ cc1: all warnings being treated as errors Signed-off-by: Tony Jones Acked-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Jaroslav Škarvada Cc: Jonathan Corbet Cc: Ravi Bangoria Cc: Seeteena Thoufeek Fixes: 66dfdff03d19 ("perf tools: Add Python 3 support") Link: http://lkml.kernel.org/r/20190124005229.16146-2-tonyj@suse.de Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit d90a375b786c98dc21955733d1a624637ebbe64c Author: Tony Jones Date: Wed Jan 23 16:52:25 2019 -0800 perf script python: Use PyBytes for attr in trace-event-python [ Upstream commit 72e0b15cb24a497d7d0d4707cf51ff40c185ae8c ] With Python3. PyUnicode_FromStringAndSize is unsafe to call on attr and will return NULL. Use _PyBytes_FromStringAndSize (as with raw_buf). Below is the observed behavior without the fix. Note it is first necessary to apply the prior fix (Add trace_context extension module to sys,modules): # ldd /usr/bin/perf | grep -i python libpython3.6m.so.1.0 => /usr/lib64/libpython3.6m.so.1.0 (0x00007f8e1dfb2000) # perf record -e raw_syscalls:sys_enter /bin/false [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.018 MB perf.data (21 samples) ] # perf script -g python | cat generated Python script: perf-script.py # perf script -s ./perf-script.py in trace_begin Segmentation fault (core dumped) Signed-off-by: Tony Jones Acked-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Jaroslav Škarvada Cc: Jonathan Corbet Cc: Ravi Bangoria Cc: Seeteena Thoufeek Fixes: 66dfdff03d19 ("perf tools: Add Python 3 support") Link: http://lkml.kernel.org/r/20190124005229.16146-3-tonyj@suse.de Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f94e369fe7a867481c86d2ed5e31ab30972af136 Author: Jérôme de Bretagne Date: Sun Jan 6 18:56:44 2019 +0100 platform/x86: intel-hid: Missing power button release on some Dell models [ Upstream commit e97a34563d18606ee5db93e495382a967f999cd4 ] Power button suspend for some Dell models was added in: commit 821b85366284 ("platform/x86: intel-hid: Power button suspend on Dell Latitude 7275") by checking against the power button press notification (0xCE) to report the power button press event. The corresponding power button release notification (0xCF) was caught and ignored to stop it from being reported as an "unknown event" in the logs. The missing button release event is creating issues on Android-x86, as reported on the project mailing list for a Dell Latitude 5175 model, since the events are expected in down/up pairs. Report the power button release event to fix this issue. Link: https://groups.google.com/forum/#!topic/android-x86/aSwZK9Nf9Ro Tested-by: Tristian Celestin Tested-by: Jérôme de Bretagne Signed-off-by: Jérôme de Bretagne Reviewed-by: Mario Limonciello [dvhart: corrected commit reference format per checkpatch] Signed-off-by: Darren Hart (VMware) Signed-off-by: Sasha Levin commit 1e55e3f6c7359ef4c8dfdb2d79c9bd3dbf006186 Author: Roger Quadros Date: Thu Jan 10 17:04:28 2019 +0200 usb: dwc3: gadget: Fix OTG events when gadget driver isn't loaded [ Upstream commit 169e3b68cadb5775daca009ced4faf01ffd97dcf ] On v3.10a in dual-role mode, if port is in device mode and gadget driver isn't loaded, the OTG event interrupts don't come through. It seems that if the core is configured to be OTG2.0 only, then we can't leave the DCFG.DEVSPD at Super-speed (default) if we expect OTG to work properly. It must be set to High-speed. Fix this issue by configuring DCFG.DEVSPD to the supported maximum speed at gadget init. Device tree still needs to provide correct supported maximum speed for this to work. This issue wasn't present on v2.40a but is seen on v3.10a. It doesn't cause any side effects on v2.40a. Signed-off-by: Roger Quadros Signed-off-by: Sekhar Nori Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 2b20c29bcdf649d18540de84d416844bd19953d3 Author: Takashi Sakamoto Date: Mon Jan 28 20:40:58 2019 +0900 ALSA: dice: add support for Solid State Logic Duende Classic/Mini [ Upstream commit b2e9e1c8810ee05c95f4d55800b8afae70ab01b4 ] Duende Classic was produced by Solid State Logic in 2006, as a first model of Duende DSP series. The following model, Duende Mini was produced in 2008. They are designed to receive isochronous packets for PCM frames via IEEE 1394 bus, perform signal processing by downloaded program, then transfer isochronous packets for converted PCM frames. These two models includes the same embedded board, consists of several ICs below: - Texus Instruments Inc, TSB41AB3 for physical layer of IEEE 1394 bus - WaveFront semiconductor, DICE II STD ASIC for link/protocol layer - Altera MAX 3000A CPLD for programs - Analog devices, SHARC ADSP-21363 for signal processing (4 chips) This commit adds support for the two models to ALSA dice driver. Like support for the other devices, packet streaming is just available. Userspace applications should be developed if full features became available; e.g. program uploader and parameter controller. $ ./hinawa-config-rom-printer /dev/fw1 { 'bus-info': { 'adj': False, 'bmc': False, 'chip_ID': 349771402425, 'cmc': True, 'cyc_clk_acc': 255, 'generation': 1, 'imc': True, 'isc': True, 'link_spd': 2, 'max_ROM': 1, 'max_rec': 512, 'name': '1394', 'node_vendor_ID': 20674, 'pmc': False}, 'root-directory': [ ['VENDOR', 20674], ['DESCRIPTOR', 'Solid State Logic'], ['MODEL', 112], ['DESCRIPTOR', 'Duende board'], [ 'NODE_CAPABILITIES', { 'addressing': {'64': True, 'fix': True, 'prv': True}, 'misc': {'int': False, 'ms': False, 'spt': True}, 'state': { 'atn': False, 'ded': False, 'drq': True, 'elo': False, 'init': False, 'lst': True, 'off': False}, 'testing': {'bas': False, 'ext': False}}], [ 'UNIT', [ ['SPECIFIER_ID', 20674], ['VERSION', 1], ['MODEL', 112], ['DESCRIPTOR', 'Duende board']]]]} Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3abb3d0418e1418c3e53641367d91e0205867128 Author: Nicholas Kazlauskas Date: Mon Jan 14 16:04:10 2019 -0500 drm/amd/display: Enable vblank interrupt during CRC capture [ Upstream commit 428da2bdb05d76c48d0bd8fbfa2e4c102685be08 ] [Why] In order to read CRC events when CRC capture is enabled the vblank interrput handler needs to be running for the CRTC. The handler is enabled while there is an active vblank reference. When running IGT tests there will often be no active vblank reference but the test expects to read a CRC value. This is valid usage (and works on i915 since they have a CRC interrupt handler) so the reference to the vblank should be grabbed while capture is active. This issue was found running: igt@kms_plane_multiple@atomic-pipe-b-tiling-none The pipe-b is the only one in the initial commit and was not previously active so no vblank reference is grabbed. The vblank interrupt is not enabled and the test times out. [How] Keep a reference to the vblank as long as CRC capture is enabled. If userspace never explicitly disables it then the reference is also dropped when removing the CRTC from the context (stream = NULL). Signed-off-by: Nicholas Kazlauskas Reviewed-by: Harry Wentland Reviewed-by: Sun peng Li Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 06af7dda05b33fe7b37bdf95b87e944b2e2de608 Author: Nathan Fontenot Date: Mon Oct 29 13:43:36 2018 -0500 powerpc/pseries: Perform full re-add of CPU for topology update post-migration [ Upstream commit 81b61324922c67f73813d8a9c175f3c153f6a1c6 ] On pseries systems, performing a partition migration can result in altering the nodes a CPU is assigned to on the destination system. For exampl, pre-migration on the source system CPUs are in node 1 and 3, post-migration on the destination system CPUs are in nodes 2 and 3. Handling the node change for a CPU can cause corruption in the slab cache if we hit a timing where a CPUs node is changed while cache_reap() is invoked. The corruption occurs because the slab cache code appears to rely on the CPU and slab cache pages being on the same node. The current dynamic updating of a CPUs node done in arch/powerpc/mm/numa.c does not prevent us from hitting this scenario. Changing the device tree property update notification handler that recognizes an affinity change for a CPU to do a full DLPAR remove and add of the CPU instead of dynamically changing its node resolves this issue. Signed-off-by: Nathan Fontenot Signed-off-by: Michael W. Bringmann Tested-by: Michael W. Bringmann Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 57f03bbd42363b8e6287acc4116c676c99807080 Author: Manfred Schlaegl Date: Mon Jan 28 19:01:10 2019 +0100 tty: increase the default flip buffer limit to 2*640K [ Upstream commit 7ab57b76ebf632bf2231ccabe26bea33868118c6 ] We increase the default limit for buffer memory allocation by a factor of 10 to 640K to prevent data loss when using fast serial interfaces. For example when using RS485 without flow-control at speeds of 1Mbit/s an upwards we've run into problems such as applications being too slow to read out this buffer (on embedded devices based on imx53 or imx6). If you want to write transmitted data to a slow SD card and thus have realtime requirements, this limit can become a problem. That shouldn't be the case and 640K buffers fix such problems for us. This value is a maximum limit for allocation only. It has no effect on systems that currently run fine. When transmission is slow enough applications and hardware can keep up and increasing this limit doesn't change anything. It only _allows_ to allocate more than 2*64K in cases we currently fail to allocate memory despite having some. Signed-off-by: Manfred Schlaegl Signed-off-by: Martin Kepplinger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2142eba848a16969b2f959714c9ee81df11c41ee Author: Chen-Yu Tsai Date: Sun Jan 27 22:50:54 2019 +0800 backlight: pwm_bl: Use gpiod_get_value_cansleep() to get initial state [ Upstream commit cec2b18832e26bc866bef2be22eff4e25bbc4034 ] gpiod_get_value() gives out a warning if access to the underlying gpiochip requires sleeping, which is common for I2C based chips: WARNING: CPU: 0 PID: 77 at drivers/gpio/gpiolib.c:2500 gpiod_get_value+0xd0/0x100 Modules linked in: CPU: 0 PID: 77 Comm: kworker/0:2 Not tainted 4.14.0-rc3-00589-gf32897915d48-dirty #90 Hardware name: Allwinner sun4i/sun5i Families Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x88/0x9c) [] (dump_stack) from [] (__warn+0xe8/0x100) [] (__warn) from [] (warn_slowpath_null+0x20/0x28) [] (warn_slowpath_null) from [] (gpiod_get_value+0xd0/0x100) [] (gpiod_get_value) from [] (pwm_backlight_probe+0x238/0x508) [] (pwm_backlight_probe) from [] (platform_drv_probe+0x50/0xac) [] (platform_drv_probe) from [] (driver_probe_device+0x238/0x2e8) [] (driver_probe_device) from [] (bus_for_each_drv+0x44/0x94) [] (bus_for_each_drv) from [] (__device_attach+0xb0/0x114) [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [] (bus_probe_device) from [] (deferred_probe_work_func+0x50/0x14c) [] (deferred_probe_work_func) from [] (process_one_work+0x1ec/0x414) [] (process_one_work) from [] (worker_thread+0x2b0/0x5a0) [] (worker_thread) from [] (kthread+0x14c/0x154) [] (kthread) from [] (ret_from_fork+0x14/0x24) This was missed in commit 0c9501f823a4 ("backlight: pwm_bl: Handle gpio that can sleep"). The code was then moved to a separate function in commit 7613c922315e ("backlight: pwm_bl: Move the checks for initial power state to a separate function"). The only usage of gpiod_get_value() is during the probe stage, which is safe to sleep in. Switch to gpiod_get_value_cansleep(). Fixes: 0c9501f823a4 ("backlight: pwm_bl: Handle gpio that can sleep") Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Acked-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d0bc74c5632f8e5080bcb4bb1843be5f3ed112cd Author: Oleg Nesterov Date: Mon Jan 28 17:00:13 2019 +0100 cgroup/pids: turn cgroup_subsys->free() into cgroup_subsys->release() to fix the accounting [ Upstream commit 51bee5abeab2058ea5813c5615d6197a23dbf041 ] The only user of cgroup_subsys->free() callback is pids_cgrp_subsys which needs pids_free() to uncharge the pid. However, ->free() is called from __put_task_struct()->cgroup_free() and this is too late. Even the trivial program which does for (;;) { int pid = fork(); assert(pid >= 0); if (pid) wait(NULL); else exit(0); } can run out of limits because release_task()->call_rcu(delayed_put_task_struct) implies an RCU gp after the task/pid goes away and before the final put(). Test-case: mkdir -p /tmp/CG mount -t cgroup2 none /tmp/CG echo '+pids' > /tmp/CG/cgroup.subtree_control mkdir /tmp/CG/PID echo 2 > /tmp/CG/PID/pids.max perl -e 'while ($p = fork) { wait; } $p // die "fork failed: $!\n"' & echo $! > /tmp/CG/PID/cgroup.procs Without this patch the forking process fails soon after migration. Rename cgroup_subsys->free() to cgroup_subsys->release() and move the callsite into the new helper, cgroup_release(), called by release_task() which actually frees the pid(s). Reported-by: Herton R. Krzesinski Reported-by: Jan Stancek Signed-off-by: Oleg Nesterov Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b52681e6e6236d7feb5953d3afd9c2080f33c85e Author: Nicolai Stange Date: Tue Jan 22 10:57:21 2019 -0500 powerpc/64s: Clear on-stack exception marker upon exception return [ Upstream commit eddd0b332304d554ad6243942f87c2fcea98c56b ] The ppc64 specific implementation of the reliable stacktracer, save_stack_trace_tsk_reliable(), bails out and reports an "unreliable trace" whenever it finds an exception frame on the stack. Stack frames are classified as exception frames if the STACK_FRAME_REGS_MARKER magic, as written by exception prologues, is found at a particular location. However, as observed by Joe Lawrence, it is possible in practice that non-exception stack frames can alias with prior exception frames and thus, that the reliable stacktracer can find a stale STACK_FRAME_REGS_MARKER on the stack. It in turn falsely reports an unreliable stacktrace and blocks any live patching transition to finish. Said condition lasts until the stack frame is overwritten/initialized by function call or other means. In principle, we could mitigate this by making the exception frame classification condition in save_stack_trace_tsk_reliable() stronger: in addition to testing for STACK_FRAME_REGS_MARKER, we could also take into account that for all exceptions executing on the kernel stack - their stack frames's backlink pointers always match what is saved in their pt_regs instance's ->gpr[1] slot and that - their exception frame size equals STACK_INT_FRAME_SIZE, a value uncommonly large for non-exception frames. However, while these are currently true, relying on them would make the reliable stacktrace implementation more sensitive towards future changes in the exception entry code. Note that false negatives, i.e. not detecting exception frames, would silently break the live patching consistency model. Furthermore, certain other places (diagnostic stacktraces, perf, xmon) rely on STACK_FRAME_REGS_MARKER as well. Make the exception exit code clear the on-stack STACK_FRAME_REGS_MARKER for those exceptions running on the "normal" kernel stack and returning to kernelspace: because the topmost frame is ignored by the reliable stack tracer anyway, returns to userspace don't need to take care of clearing the marker. Furthermore, as I don't have the ability to test this on Book 3E or 32 bits, limit the change to Book 3S and 64 bits. Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack tracing for the consistency model") Reported-by: Joe Lawrence Signed-off-by: Nicolai Stange Signed-off-by: Joe Lawrence Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 118d38a3577f7728278f6afda8436af05a6bec7f Author: Stanislav Fomichev Date: Mon Jan 28 09:21:16 2019 -0800 selftests/bpf: skip verifier tests for unsupported program types [ Upstream commit 8184d44c9a577a2f1842ed6cc844bfd4a9981d8e ] Use recently introduced bpf_probe_prog_type() to skip tests in the test_verifier() if bpf_verify_program() fails. The skipped test is indicated in the output. Example: ... 679/p bpf_get_stack return R0 within range SKIP (unsupported program type 5) 680/p ld_abs: invalid op 1 OK ... Summary: 863 PASSED, 165 SKIPPED, 3 FAILED Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit ae92cf4760f8ee21db0297299be11cf3ed09bcc9 Author: Valdis Kletnieks Date: Tue Jan 29 01:04:25 2019 -0500 bpf: fix missing prototype warnings [ Upstream commit 116bfa96a255123ed209da6544f74a4f2eaca5da ] Compiling with W=1 generates warnings: CC kernel/bpf/core.o kernel/bpf/core.c:721:12: warning: no previous prototype for ?bpf_jit_alloc_exec_limit? [-Wmissing-prototypes] 721 | u64 __weak bpf_jit_alloc_exec_limit(void) | ^~~~~~~~~~~~~~~~~~~~~~~~ kernel/bpf/core.c:757:14: warning: no previous prototype for ?bpf_jit_alloc_exec? [-Wmissing-prototypes] 757 | void *__weak bpf_jit_alloc_exec(unsigned long size) | ^~~~~~~~~~~~~~~~~~ kernel/bpf/core.c:762:13: warning: no previous prototype for ?bpf_jit_free_exec? [-Wmissing-prototypes] 762 | void __weak bpf_jit_free_exec(void *addr) | ^~~~~~~~~~~~~~~~~ All three are weak functions that archs can override, provide proper prototypes for when a new arch provides their own. Signed-off-by: Valdis Kletnieks Acked-by: Song Liu Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 06666a19d5a5854f0936c02088f0217d2b167d6d Author: Paolo Valente Date: Tue Jan 29 12:06:38 2019 +0100 block, bfq: fix in-service-queue check for queue merging [ Upstream commit 058fdecc6de7cdecbf4c59b851e80eb2d6c5295f ] When a new I/O request arrives for a bfq_queue, say Q, bfq checks whether that request is close to (a) the head request of some other queue waiting to be served, or (b) the last request dispatched for the in-service queue (in case Q itself is not the in-service queue) If a queue, say Q2, is found for which the above condition holds, then bfq merges Q and Q2, to hopefully get a more sequential I/O in the resulting merged queue, and thus a possibly higher throughput. Case (b) is checked by comparing the new request for Q with the last request dispatched, assuming that the latter necessarily belonged to the in-service queue. Unfortunately, this assumption is no longer always correct, since commit d0edc2473be9 ("block, bfq: inject other-queue I/O into seeky idle queues on NCQ flash"). When the assumption does not hold, queues that must not be merged may be merged, causing unexpected loss of control on per-queue service guarantees. This commit solves this problem by adding an extra field, which stores the actual last request dispatched for the in-service queue, and by using this new field to correctly check case (b). Signed-off-by: Paolo Valente Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 30d503bae9673ff6b0c67c6fa61b95db66319088 Author: Russell King Date: Tue Apr 10 11:35:36 2018 +0100 ARM: avoid Cortex-A9 livelock on tight dmb loops [ Upstream commit 5388a5b82199facacd3d7ac0d05aca6e8f902fed ] machine_crash_nonpanic_core() does this: while (1) cpu_relax(); because the kernel has crashed, and we have no known safe way to deal with the CPU. So, we place the CPU into an infinite loop which we expect it to never exit - at least not until the system as a whole is reset by some method. In the absence of erratum 754327, this code assembles to: b . In other words, an infinite loop. When erratum 754327 is enabled, this becomes: 1: dmb b 1b It has been observed that on some systems (eg, OMAP4) where, if a crash is triggered, the system tries to kexec into the panic kernel, but fails after taking the secondary CPU down - placing it into one of these loops. This causes the system to livelock, and the most noticable effect is the system stops after issuing: Loading crashdump kernel... to the system console. The tested as working solution I came up with was to add wfe() to these infinite loops thusly: while (1) { cpu_relax(); wfe(); } which, without 754327 builds to: 1: wfe b 1b or with 754327 is enabled: 1: dmb wfe b 1b Adding "wfe" does two things depending on the environment we're running under: - where we're running on bare metal, and the processor implements "wfe", it stops us spinning endlessly in a loop where we're never going to do any useful work. - if we're running in a VM, it allows the CPU to be given back to the hypervisor and rescheduled for other purposes (maybe a different VM) rather than wasting CPU cycles inside a crashed VM. However, in light of erratum 794072, Will Deacon wanted to see 10 nops as well - which is reasonable to cover the case where we have erratum 754327 enabled _and_ we have a processor that doesn't implement the wfe hint. So, we now end up with: 1: wfe b 1b when erratum 754327 is disabled, or: 1: dmb nop nop nop nop nop nop nop nop nop nop wfe b 1b when erratum 754327 is enabled. We also get the dmb + 10 nop sequence elsewhere in the kernel, in terminating loops. This is reasonable - it means we get the workaround for erratum 794072 when erratum 754327 is enabled, but still relinquish the dead processor - either by placing it in a lower power mode when wfe is implemented as such or by returning it to the hypervisior, or in the case where wfe is a no-op, we use the workaround specified in erratum 794072 to avoid the problem. These as two entirely orthogonal problems - the 10 nops addresses erratum 794072, and the wfe is an optimisation that makes the system more efficient when crashed either in terms of power consumption or by allowing the host/other VMs to make use of the CPU. I don't see any reason not to use kexec() inside a VM - it has the potential to provide automated recovery from a failure of the VMs kernel with the opportunity for saving a crashdump of the failure. A panic() with a reboot timeout won't do that, and reading the libvirt documentation, setting on_reboot to "preserve" won't either (the documentation states "The preserve action for an on_reboot event is treated as a destroy".) Surely it has to be a good thing to avoiding having CPUs spinning inside a VM that is doing no useful work. Acked-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Sasha Levin commit d8945878ded6e5850b59e101bcc9fe4167ab7fb1 Author: Vladimir Murzin Date: Fri Jan 25 15:18:37 2019 +0100 ARM: 8830/1: NOMMU: Toggle only bits in EXC_RETURN we are really care of [ Upstream commit 72cd4064fccaae15ab84d40d4be23667402df4ed ] ARMv8M introduces support for Security extension to M class, among other things it affects exception handling, especially, encoding of EXC_RETURN. The new bits have been added: Bit [6] Secure or Non-secure stack Bit [5] Default callee register stacking Bit [0] Exception Secure which conflicts with hard-coded value of EXC_RETURN: In fact, we only care of few bits: Bit [3] Mode (0 - Handler, 1 - Thread) Bit [2] Stack pointer selection (0 - Main, 1 - Process) We can toggle only those bits and left other bits as they were on exception entry. It is basically, what patch does - saves EXC_RETURN when we do transition form Thread to Handler mode (it is first svc), so later saved value is used instead of EXC_RET_THREADMODE_PROCESSSTACK. Signed-off-by: Vladimir Murzin Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 668713493a19886c8e8c4db731694aacdf1cd287 Author: Stanislaw Gruszka Date: Tue Jan 22 13:47:54 2019 +0100 mt7601u: bump supported EEPROM version [ Upstream commit 3bd1505fed71d834f45e87b32ff07157fdda47e0 ] As reported by Michael eeprom 0d is supported and work with the driver. Dump of /sys/kernel/debug/ieee80211/phy1/mt7601u/eeprom_param with 0d EEPORM looks like this: RSSI offset: 0 0 Reference temp: f9 LNA gain: 8 Reg channels: 1-14 Per rate power: raw:05 bw20:05 bw40:05 raw:05 bw20:05 bw40:05 raw:03 bw20:03 bw40:03 raw:03 bw20:03 bw40:03 raw:04 bw20:04 bw40:04 raw:00 bw20:00 bw40:00 raw:00 bw20:00 bw40:00 raw:00 bw20:00 bw40:00 raw:02 bw20:02 bw40:02 raw:00 bw20:00 bw40:00 Per channel power: tx_power ch1:09 ch2:09 tx_power ch3:0a ch4:0a tx_power ch5:0a ch6:0a tx_power ch7:0b ch8:0b tx_power ch9:0b ch10:0b tx_power ch11:0b ch12:0b tx_power ch13:0b ch14:0b Reported-and-tested-by: Michael Signed-off-by: Stanislaw Gruszka Acked-by: Jakub Kicinski Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit a2479c401054913f1bbc780d06dbf5ceada7d1ff Author: Alexey Khoroshilov Date: Sat Dec 8 01:57:04 2018 +0300 soc: qcom: gsbi: Fix error handling in gsbi_probe() [ Upstream commit 8cd09a3dd3e176c62da67efcd477a44a8d87185e ] If of_platform_populate() fails in gsbi_probe(), gsbi->hclk is left undisabled. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Bjorn Andersson Signed-off-by: Andy Gross Signed-off-by: Sasha Levin commit ce80ebf7a04e6467eb35108e32804769d80695a4 Author: Ard Biesheuvel Date: Sat Feb 2 10:41:16 2019 +0100 efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted [ Upstream commit 4e46c2a956215482418d7b315749fb1b6c6bc224 ] The UEFI spec revision 2.7 errata A section 8.4 has the following to say about the virtual memory runtime services: "This section contains function definitions for the virtual memory support that may be optionally used by an operating system at runtime. If an operating system chooses to make EFI runtime service calls in a virtual addressing mode instead of the flat physical mode, then the operating system must use the services in this section to switch the EFI runtime services from flat physical addressing to virtual addressing." So it is pretty clear that calling SetVirtualAddressMap() is entirely optional, and so there is no point in doing so unless it achieves anything useful for us. This is not the case for 64-bit ARM. The identity mapping used by the firmware is arbitrarily converted into another permutation of userland addresses (i.e., bits [63:48] cleared), and the runtime code could easily deal with the original layout in exactly the same way as it deals with the converted layout. However, due to constraints related to page size differences if the OS is not running with 4k pages, and related to systems that may expose the individual sections of PE/COFF runtime modules as different memory regions, creating the virtual layout is a bit fiddly, and requires us to sort the memory map and reason about adjacent regions with identical memory types etc etc. So the obvious fix is to stop calling SetVirtualAddressMap() altogether on arm64 systems. However, to avoid surprises, which are notoriously hard to diagnose when it comes to OS<->firmware interactions, let's start by making it an opt-out feature, and implement support for the 'efi=novamap' kernel command line parameter on ARM and arm64 systems. ( Note that 32-bit ARM generally does require SetVirtualAddressMap() to be used, given that the physical memory map and the kernel virtual address map are not guaranteed to be non-overlapping like on arm64. However, having support for efi=novamap,noruntime on 32-bit ARM, combined with the recently proposed support for earlycon=efifb, is likely to be useful to diagnose boot issues on such systems if they have no accessible serial port. ) Tested-by: Jeffrey Hugo Tested-by: Bjorn Andersson Tested-by: Lee Jones Signed-off-by: Ard Biesheuvel Cc: AKASHI Takahiro Cc: Alexander Graf Cc: Borislav Petkov Cc: Heinrich Schuchardt Cc: Leif Lindholm Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Jones Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 240a9050a3d855e89546002968a622986108780f Author: Mathieu Malaterre Date: Fri Dec 15 13:46:39 2017 +0100 ARM: dts: lpc32xx: Remove leading 0x and 0s from bindings notation [ Upstream commit 3e3380d0675d5e20b0af067d60cb947a4348bf9b ] Improve the DTS files by removing all the leading "0x" and zeros to fix the following dtc warnings: Warning (unit_address_format): Node /XXX unit name should not have leading "0x" and Warning (unit_address_format): Node /XXX unit name should not have leading 0s Converted using the following command: find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} + For simplicity, two sed expressions were used to solve each warnings separately. To make the regex expression more robust a few other issues were resolved, namely setting unit-address to lower case, and adding a whitespace before the opening curly brace: https://elinux.org/Device_Tree_Linux#Linux_conventions This will solve as a side effect warning: Warning (simple_bus_reg): Node /XXX@ simple-bus unit address format error, expected "" This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation") Reported-by: David Daney Suggested-by: Rob Herring Signed-off-by: Mathieu Malaterre [vzapolskiy: fixed commit message to pass checkpatch.pl test] Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sasha Levin commit b5c1dc9d8fa4d52153ddc10375e977905fca2c98 Author: Shayenne Moura Date: Wed Jan 30 14:06:36 2019 -0200 drm/vkms: Bugfix extra vblank frame [ Upstream commit def35e7c592616bc09be328de8795e5e624a3cf8 ] kms_flip tests are breaking on vkms when simulate vblank because vblank event sequence count returns one extra frame after arm vblank event to make a page flip. When vblank interrupt happens, userspace processes the vblank event and issues the next page flip command. Kernel calls queue_work to call commit_planes and arm the new page flip. The next vblank picks up the newly armed vblank event and vblank interrupt happens again. The arm and vblank event are asynchronous, then, on the next vblank, we receive x+2 from `get_vblank_timestamp`, instead x+1, although timestamp and vblank seqno matches. Function `get_vblank_timestamp` is reached by 2 ways: - from `drm_mode_page_flip_ioctl`: driver is doing one atomic operation to synchronize planes in the same output. There is no vblank simulation, the `drm_crtc_arm_vblank_event` function adds 1 on vblank count, and the variable in_vblank_irq is false - from `vkms_vblank_simulate`: since the driver is doing a vblank simulation, the variable in_vblank_irq is true. Fix this problem subtracting one vblank period from vblank_time when `get_vblank_timestamp` is called from trace `drm_mode_page_flip_ioctl`, i.e., is not a real vblank interrupt, and getting the timestamp and vblank seqno when it is a real vblank interrupt. The reason for all this is that get_vblank_timestamp always supplies the timestamp for the next vblank event. The hrtimer is the vblank simulator, and it needs the correct previous value to present the next vblank. Since this is how hw timestamp registers work and what the vblank core expects. Signed-off-by: Shayenne Moura Signed-off-by: Daniel Vetter Reviewed-by: Rodrigo Siqueira Signed-off-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/171e6e1c239cbca0c3df7183ed8acdfeeace9cf4.1548856186.git.shayenneluzmoura@gmail.com Signed-off-by: Sasha Levin commit e8e0bd4915ec8b2ee7b69f966719329ec65ba781 Author: Andrea Parri Date: Mon Jan 21 16:52:40 2019 +0100 sched/core: Use READ_ONCE()/WRITE_ONCE() in move_queued_task()/task_rq_lock() [ Upstream commit c546951d9c9300065bad253ecdf1ac59ce9d06c8 ] move_queued_task() synchronizes with task_rq_lock() as follows: move_queued_task() task_rq_lock() [S] ->on_rq = MIGRATING [L] rq = task_rq() WMB (__set_task_cpu()) ACQUIRE (rq->lock); [S] ->cpu = new_cpu [L] ->on_rq where "[L] rq = task_rq()" is ordered before "ACQUIRE (rq->lock)" by an address dependency and, in turn, "ACQUIRE (rq->lock)" is ordered before "[L] ->on_rq" by the ACQUIRE itself. Use READ_ONCE() to load ->cpu in task_rq() (c.f., task_cpu()) to honor this address dependency. Also, mark the accesses to ->cpu and ->on_rq with READ_ONCE()/WRITE_ONCE() to comply with the LKMM. Signed-off-by: Andrea Parri Signed-off-by: Peter Zijlstra (Intel) Cc: Alan Stern Cc: Linus Torvalds Cc: Mike Galbraith Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Link: https://lkml.kernel.org/r/20190121155240.27173-1-andrea.parri@amarulasolutions.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit b12a060a0bd217ca75e96ad5c06bae962d8d7030 Author: Ard Biesheuvel Date: Sat Feb 2 10:41:12 2019 +0100 efi/memattr: Don't bail on zero VA if it equals the region's PA [ Upstream commit 5de0fef0230f3c8d75cff450a71740a7bf2db866 ] The EFI memory attributes code cross-references the EFI memory map with the more granular EFI memory attributes table to ensure that they are in sync before applying the strict permissions to the regions it describes. Since we always install virtual mappings for the EFI runtime regions to which these strict permissions apply, we currently perform a sanity check on the EFI memory descriptor, and ensure that the EFI_MEMORY_RUNTIME bit is set, and that the virtual address has been assigned. However, in cases where a runtime region exists at physical address 0x0, and the virtual mapping equals the physical mapping, e.g., when running in mixed mode on x86, we encounter a memory descriptor with the runtime attribute and virtual address 0x0, and incorrectly draw the conclusion that a runtime region exists for which no virtual mapping was installed, and give up altogether. The consequence of this is that firmware mappings retain their read-write-execute permissions, making the system more vulnerable to attacks. So let's only bail if the virtual address of 0x0 has been assigned to a physical region that does not reside at address 0x0. Signed-off-by: Ard Biesheuvel Acked-by: Sai Praneeth Prakhya Cc: AKASHI Takahiro Cc: Alexander Graf Cc: Bjorn Andersson Cc: Borislav Petkov Cc: Heinrich Schuchardt Cc: Jeffrey Hugo Cc: Lee Jones Cc: Leif Lindholm Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Jones Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory ...") Link: http://lkml.kernel.org/r/20190202094119.13230-4-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit f056c90f079a3283a08d7fa55a54bfdb66745892 Author: Hidetoshi Seto Date: Tue Jan 29 10:12:45 2019 -0500 sched/debug: Initialize sd_sysctl_cpus if !CONFIG_CPUMASK_OFFSTACK [ Upstream commit 1ca4fa3ab604734e38e2a3000c9abf788512ffa7 ] register_sched_domain_sysctl() copies the cpu_possible_mask into sd_sysctl_cpus, but only if sd_sysctl_cpus hasn't already been allocated (ie, CONFIG_CPUMASK_OFFSTACK is set). However, when CONFIG_CPUMASK_OFFSTACK is not set, sd_sysctl_cpus is left uninitialized (all zeroes) and the kernel may fail to initialize sched_domain sysctl entries for all possible CPUs. This is visible to the user if the kernel is booted with maxcpus=n, or if ACPI tables have been modified to leave CPUs offline, and then checking for missing /proc/sys/kernel/sched_domain/cpu* entries. Fix this by separating the allocation and initialization, and adding a flag to initialize the possible CPU entries while system booting only. Tested-by: Syuuichirou Ishii Tested-by: Tarumizu, Kohei Signed-off-by: Hidetoshi Seto Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Masayoshi Mizuma Acked-by: Joe Lawrence Cc: Linus Torvalds Cc: Masayoshi Mizuma Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/20190129151245.5073-1-msys.mizuma@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 442caac9fce9f4690dd92046654af554a1ab176f Author: wen yang Date: Sat Feb 2 14:53:16 2019 +0000 ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe [ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ] The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. Signed-off-by: Wen Yang Cc: Timur Tabi Cc: Nicolin Chen Cc: Xiubo Li Cc: Fabio Estevam Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: alsa-devel@alsa-project.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b4410c7d731db051926bb83e8d62fc0b02241c3d Author: Johannes Berg Date: Tue Dec 11 21:20:43 2018 +0100 iwlwifi: mvm: fix RFH config command with >=10 CPUs [ Upstream commit dbf592f3d14fb7d532cb7c820b1065cf33e02aaa ] If we have >=10 (logical) CPUs, our command size exceeds the internal buffer size and the command fails; fix that by using IWL_HCMD_DFL_NOCOPY for the command that's allocated anyway. While at it, also fix the leak of cmd, and use struct_size() to calculate its size. Signed-off-by: Johannes Berg Fixes: 8edbfaa19835 ("iwlwifi: mvm: configure multi RX queue") Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 080e00c8f6f96dc6837e2ad220c5d7032fa00788 Author: Stefan Roese Date: Fri Feb 1 11:17:09 2019 +0100 staging: spi: mt7621: Add return code check on device_reset() [ Upstream commit 46c337872f34bc6387b0c29a4964f562c70139e3 ] This patch adds a return code check on device_reset() and removes the compile warning. Signed-off-by: Stefan Roese Cc: Mark Brown Cc: Sankalp Negi Cc: Chuanhong Guo Cc: John Crispin Reviewed-by: NeilBrown Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f0eb935c50b9272b6a48bc52c2c4e3c5d4a4ed2b Author: Thierry Reding Date: Fri Jan 25 14:11:42 2019 +0100 i2c: of: Try to find an I2C adapter matching the parent [ Upstream commit e814e688413aabd7b0d75e2a8ed1caa472951dec ] If an I2C adapter doesn't match the provided device tree node, also try matching the parent's device tree node. This allows finding an adapter based on the device node of the parent device that was used to register it. This fixes a regression on Tegra124-based Chromebooks (Nyan) where the eDP controller registers an I2C adapter that is used to read to EDID. After commit 993a815dcbb2 ("dt-bindings: panel: Add missing .txt suffix") this stopped working because the I2C adapter could no longer be found. The approach in this patch fixes the regression without introducing the issues that the above commit solved. Fixes: 17ab7806de0c ("drm: don't link DP aux i2c adapter to the hardware device node") Signed-off-by: Thierry Reding Tested-by: Tristan Bastian Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7c114e8605a9319afae86a6ccd8b677f75a4f0ce Author: Rajneesh Bhardwaj Date: Fri Feb 1 13:02:26 2019 +0530 platform/x86: intel_pmc_core: Fix PCH IP sts reading [ Upstream commit 0e68eeea9894feeba2edf7ec63e4551b87f39621 ] A previous commit "platform/x86: intel_pmc_core: Make the driver PCH family agnostic " provided better abstraction to this driver but has some fundamental issues. e.g. the following condition for (index = 0; index < pmcdev->map->ppfear_buckets && index < PPFEAR_MAX_NUM_ENTRIES; index++, iter++) is wrong because for CNL, PPFEAR_MAX_NUM_ENTRIES is hardcoded as 5 which is _wrong_ and even though ppfear_buckets is 8, the loop fails to read all eight registers needed for CNL PCH i.e. PPFEAR0 and PPFEAR1. This patch refactors the pfear show logic to correctly read PCH IP power gating status for Cannonlake and beyond. Cc: "David E. Box" Cc: Srinivas Pandruvada Fixes: c977b98bbef5 ("platform/x86: intel_pmc_core: Make the driver PCH family agnostic") Signed-off-by: Rajneesh Bhardwaj Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit b9f257e27890c462cc07c3e6d4fa7509730ea396 Author: Kai-Heng Feng Date: Tue Dec 11 15:59:37 2018 +0800 e1000e: Exclude device from suspend direct complete optimization [ Upstream commit 59f58708c5047289589cbf6ee95146b76cf57d1e ] e1000e sets different WoL settings in system suspend callback and runtime suspend callback. The suspend direct complete optimization leaves e1000e in runtime suspended state with wrong WoL setting during system suspend. To fix this, we need to disable suspend direct complete optimization to let e1000e always use suspend callback to set correct WoL during system suspend. Signed-off-by: Kai-Heng Feng Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit c23242c36bdd6c755d696f50feba58e177a44c0c Author: Konstantin Khlebnikov Date: Mon Jan 14 16:29:30 2019 +0300 e1000e: fix cyclic resets at link up with active tx [ Upstream commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61 ] I'm seeing series of e1000e resets (sometimes endless) at system boot if something generates tx traffic at this time. In my case this is netconsole who sends message "e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames" from e1000e itself. As result e1000_watchdog_task sees used tx buffer while carrier is off and start this reset cycle again. [ 17.794359] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 17.794714] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 22.936455] e1000e 0000:02:00.0 eth1: changing MTU from 1500 to 9000 [ 23.033336] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 26.102364] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 27.174495] 8021q: 802.1Q VLAN Support v1.8 [ 27.174513] 8021q: adding VLAN 0 to HW filter on device eth1 [ 30.671724] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation [ 30.898564] netpoll: netconsole: local port 6666 [ 30.898566] netpoll: netconsole: local IPv6 address 2a02:6b8:0:80b:beae:c5ff:fe28:23f8 [ 30.898567] netpoll: netconsole: interface 'eth1' [ 30.898568] netpoll: netconsole: remote port 6666 [ 30.898568] netpoll: netconsole: remote IPv6 address 2a02:6b8:b000:605c:e61d:2dff:fe03:3790 [ 30.898569] netpoll: netconsole: remote ethernet address b0:a8:6e:f4:ff:c0 [ 30.917747] console [netcon0] enabled [ 30.917749] netconsole: network logging started [ 31.453353] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.185730] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.321840] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.465822] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.597423] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.745417] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.877356] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 35.005441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 35.157376] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 35.289362] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 35.417441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 37.790342] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None This patch flushes tx buffers only once when carrier is off rather than at each watchdog iteration. Signed-off-by: Konstantin Khlebnikov Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit efd85d83ac0f4a41f44625b37e3b92d4be98f5c0 Author: Mathieu Poirier Date: Thu Jan 31 11:47:08 2019 -0700 perf/aux: Make perf_event accessible to setup_aux() [ Upstream commit 840018668ce2d96783356204ff282d6c9b0e5f66 ] When pmu::setup_aux() is called the coresight PMU needs to know which sink to use for the session by looking up the information in the event's attr::config2 field. As such simply replace the cpu information by the complete perf_event structure and change all affected customers. Signed-off-by: Mathieu Poirier Reviewed-by: Suzuki Poulouse Acked-by: Peter Zijlstra Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Greg Kroah-Hartman Cc: H. Peter Anvin Cc: Heiko Carstens Cc: Jiri Olsa Cc: Mark Rutland Cc: Martin Schwidefsky Cc: Namhyung Kim Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.org Cc: linux-s390@vger.kernel.org Link: http://lkml.kernel.org/r/20190131184714.20388-2-mathieu.poirier@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 355ffe6cc2a175548477021dabc32bb03116fa4e Author: Nicholas Kazlauskas Date: Wed Jan 23 13:50:17 2019 -0500 drm/amd/display: Disconnect mpcc when changing tg [ Upstream commit 77476360f173c127c191bfe8ca8113130ef283b8 ] [Why] This fixes an mpc programming error for the following sequence of atomic commits when pipe split is enabled: Commit 1: CRTC0 (plane 4, plane 3) Pipe 0: old_plane_state = A0, new_plane_state = A1, new_tg = T0 Pipe 1: old_plane_state = B0, new_plane_state = B1, new_tg = T0 Pipe 2: old_plane_state = A0, new_plane_state = A1, new_tg = T0 Pipe 3: old_plane_state = B0, new_plane_state = B1, new_tg = T0 Commit 2: CRTC0 (plane 3), CRTC1 (plane 2) Pipe 0: old_plane_state = A1, new_plane_state = A2, new_tg = T0 Pipe 1: old_plane_state = B1, new_plane_state = B2, new_tg = T1 Pipe 2: old_plane_state = A1, new_plane_state = NULL, new_tg = NULL Pipe 3: old_plane_state = B1, new_plane_state = NULL, new_tg = NULL In the second commit the assertion for mpcc in use is hit because mpcc disconnect never occurs for pipe 1. This is because the stream changes for pipe 1 and the opp_list is empty. This sequence occurs when running the "igt@kms_plane_multiple@atomic-pipe-A-tiling-none" test with two displays connected. [How] Expand the reset condition to include: "old_pipe_ctx->stream_res.tg != new_pipe_ctx->stream_res.tg" ...but only when the plane state is non-NULL for both old and new. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Dmytro Laktyushkin Reviewed-by: Tony Cheng Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6c68d1654c27d5f6fd2b066672efe6029038b556 Author: Nicholas Kazlauskas Date: Wed Jan 23 14:55:58 2019 -0500 drm/amd/display: Don't re-program planes for DPMS changes [ Upstream commit 5062b797db4103218fa00ee254417b8ecaab7401 ] [Why] There are opt1c lock warnings and CRTC read timeouts when running the "igt@kms_plane@plane-position-hole-dpms-pipe-*" tests. These are caused by trying to reprogram planes that are not in the current context. DPMS off removes the stream from the context. In this case: new_crtc_state->active_changed = true new_crtc_state->mode_changed = false The planes are reprogrammed before the stream is removed from the context because stream_state->mode_changed = false. For DPMS adds the stream and planes back to the context: new_crtc_state->active_changed = true new_crtc_state->mode_changed = false The planes are also reprogrammed here before the stream is added to the context because stream_state->mode_changed = true. They were not previously in the current context so warnings occur here. [How] Set stream_state->mode_changed = true when new_crtc_state->active_changed = true too. This prevents reprogramming before the context is applied in DC. The programming will be done after the context is applied. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Sun peng Li Acked-by: Bhawanpreet Lakha Acked-by: Tony Cheng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 322a55a56a2acfa7763c95fd6f3ed72f1b54618f Author: Julia Lawall Date: Mon Jan 14 17:44:56 2019 +0100 drm: rcar-du: add missing of_node_put [ Upstream commit 4c6d8fc20b09f9684743afd72e4dbc3f15524479 ] Add an of_node_put when the result of of_graph_get_remote_port_parent is not available. Add a second of_node_put if no encoder is selected (encoder remains NULL). The semantic match that finds the first problem is as follows (http://coccinelle.lip6.fr): // @r exists@ local idexpression e; expression x; @@ e = of_graph_get_remote_port_parent(...); ... when != x = e when != true e == NULL when != of_node_put(e) when != of_fwnode_handle(e) ( return e; | *return ...; ) // Signed-off-by: Julia Lawall Reviewed-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 924af49998c241b95c8c3be69d635e97b49dc362 Author: Guenter Roeck Date: Wed Feb 6 21:13:49 2019 -0800 cdrom: Fix race condition in cdrom_sysctl_register [ Upstream commit f25191bb322dec8fa2979ecb8235643aa42470e1 ] The following traceback is sometimes seen when booting an image in qemu: [ 54.608293] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 54.611085] Fusion MPT base driver 3.04.20 [ 54.611877] Copyright (c) 1999-2008 LSI Corporation [ 54.616234] Fusion MPT SAS Host driver 3.04.20 [ 54.635139] sysctl duplicate entry: /dev/cdrom//info [ 54.639578] CPU: 0 PID: 266 Comm: kworker/u4:5 Not tainted 5.0.0-rc5 #1 [ 54.639578] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 54.641273] Workqueue: events_unbound async_run_entry_fn [ 54.641273] Call Trace: [ 54.641273] dump_stack+0x67/0x90 [ 54.641273] __register_sysctl_table+0x50b/0x570 [ 54.641273] ? rcu_read_lock_sched_held+0x6f/0x80 [ 54.641273] ? kmem_cache_alloc_trace+0x1c7/0x1f0 [ 54.646814] __register_sysctl_paths+0x1c8/0x1f0 [ 54.646814] cdrom_sysctl_register.part.7+0xc/0x5f [ 54.646814] register_cdrom.cold.24+0x2a/0x33 [ 54.646814] sr_probe+0x4bd/0x580 [ 54.646814] ? __driver_attach+0xd0/0xd0 [ 54.646814] really_probe+0xd6/0x260 [ 54.646814] ? __driver_attach+0xd0/0xd0 [ 54.646814] driver_probe_device+0x4a/0xb0 [ 54.646814] ? __driver_attach+0xd0/0xd0 [ 54.646814] bus_for_each_drv+0x73/0xc0 [ 54.646814] __device_attach+0xd6/0x130 [ 54.646814] bus_probe_device+0x9a/0xb0 [ 54.646814] device_add+0x40c/0x670 [ 54.646814] ? __pm_runtime_resume+0x4f/0x80 [ 54.646814] scsi_sysfs_add_sdev+0x81/0x290 [ 54.646814] scsi_probe_and_add_lun+0x888/0xc00 [ 54.646814] ? scsi_autopm_get_host+0x21/0x40 [ 54.646814] __scsi_add_device+0x116/0x130 [ 54.646814] ata_scsi_scan_host+0x93/0x1c0 [ 54.646814] async_run_entry_fn+0x34/0x100 [ 54.646814] process_one_work+0x237/0x5e0 [ 54.646814] worker_thread+0x37/0x380 [ 54.646814] ? rescuer_thread+0x360/0x360 [ 54.646814] kthread+0x118/0x130 [ 54.646814] ? kthread_create_on_node+0x60/0x60 [ 54.646814] ret_from_fork+0x3a/0x50 The only sensible explanation is that cdrom_sysctl_register() is called twice, once from the module init function and once from register_cdrom(). cdrom_sysctl_register() is not mutex protected and may happily execute twice if the second call is made before the first call is complete. Use a static atomic to ensure that the function is executed exactly once. Signed-off-by: Guenter Roeck Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6d293647f8d91e827a308ce53af9f7c953d4a242 Author: Manfred Schlaegl Date: Fri Feb 8 19:24:47 2019 +0100 fbdev: fbmem: fix memory access if logo is bigger than the screen [ Upstream commit a5399db139cb3ad9b8502d8b1bd02da9ce0b9df0 ] There is no clipping on the x or y axis for logos larger that the framebuffer size. Therefore: a logo bigger than screen size leads to invalid memory access: [ 1.254664] Backtrace: [ 1.254728] [] (cfb_imageblit) from [] (fb_show_logo+0x620/0x684) [ 1.254763] r10:00000003 r9:00027fd8 r8:c6a40000 r7:c6a36e50 r6:00000000 r5:c06b81e4 [ 1.254774] r4:c6a3e800 [ 1.254810] [] (fb_show_logo) from [] (fbcon_switch+0x3fc/0x46c) [ 1.254842] r10:c6a3e824 r9:c6a3e800 r8:00000000 r7:c6a0c000 r6:c070b014 r5:c6a3e800 [ 1.254852] r4:c6808c00 [ 1.254889] [] (fbcon_switch) from [] (redraw_screen+0xf0/0x1e8) [ 1.254918] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:c070d5a0 r5:00000080 [ 1.254928] r4:c6808c00 [ 1.254961] [] (redraw_screen) from [] (do_bind_con_driver+0x194/0x2e4) [ 1.254991] r9:00000000 r8:00000000 r7:00000014 r6:c070d5a0 r5:c070d5a0 r4:c070d5a0 So prevent displaying a logo bigger than screen size and avoid invalid memory access. Signed-off-by: Manfred Schlaegl Signed-off-by: Martin Kepplinger Cc: Daniel Vetter Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit 2dd699432958f8de930f3782d0a41cfe71e12698 Author: Heiner Kallweit Date: Wed Feb 6 19:39:52 2019 +0100 net: phy: consider latched link-down status in polling mode [ Upstream commit 93c0970493c71f264e6c3c7caf1ff24a9e1de786 ] The link status value latches link-down events. To get the current status we read the register twice in genphy_update_link(). There's a potential risk that we miss a link-down event in polling mode. This may cause issues if the user e.g. connects his machine to a different network. On the other hand reading the latched value may cause issues in interrupt mode. Following scenario: - After boot link goes up - phy_start() is called triggering an aneg restart, hence link goes down and link-down info is latched. - After aneg has finished link goes up and triggers an interrupt. Interrupt handler reads link status, means it reads the latched "link is down" info. But there won't be another interrupt as long as link stays up, therefore phylib will never recognize that link is up. Deal with both scenarios by reading the register twice in interrupt mode only. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5203cf8e29e57599138e7bfb61b786a7d84d3988 Author: Raju Rangoju Date: Wed Feb 6 22:54:44 2019 +0530 iw_cxgb4: fix srqidx leak during connection abort [ Upstream commit f368ff188ae4b3ef6f740a15999ea0373261b619 ] When an application aborts the connection by moving QP from RTS to ERROR, then iw_cxgb4's modify_rc_qp() RTS->ERROR logic sets the *srqidxp to 0 via t4_set_wq_in_error(&qhp->wq, 0), and aborts the connection by calling c4iw_ep_disconnect(). c4iw_ep_disconnect() does the following: 1. sends up a close_complete_upcall(ep, -ECONNRESET) to libcxgb4. 2. sends abort request CPL to hw. But, since the close_complete_upcall() is sent before sending the ABORT_REQ to hw, libcxgb4 would fail to release the srqidx if the connection holds one. Because, the srqidx is passed up to libcxgb4 only after corresponding ABORT_RPL is processed by kernel in abort_rpl(). This patch handle the corner-case by moving the call to close_complete_upcall() from c4iw_ep_disconnect() to abort_rpl(). So that libcxgb4 is notified about the -ECONNRESET only after abort_rpl(), and libcxgb4 can relinquish the srqidx properly. Signed-off-by: Raju Rangoju Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a78aae93ba9c8e00a2055ebf5644cca8666f9805 Author: Russell King Date: Fri Feb 8 15:35:43 2019 +0000 net: marvell: mvpp2: fix stuck in-band SGMII negotiation [ Upstream commit 316734fdcf70900a83065360cff11a5826919067 ] It appears that the mvpp22 can get stuck with SGMII negotiation. The symptoms are that in-band negotiation never completes and the partner (eg, PHY) never reports SGMII link up, or if it supports negotiation bypass, goes into negotiation bypass mode (which will happen when the PHY sees that the MAC is alive but gets no response.) Triggering the PHY end of the link to re-negotiate results in the bypass bit clearing on the PHY, and then re-setting - indicating that the problem is at the mvpp22 GMAC end. Asserting the GMAC reset and de-asserting it resolves the issue. Arrange to assert the GMAC reset at probe time, and deassert it only after we have configured the GMAC for the appropriate mode. This resolves the issue. Tested-by: Sven Auhagen Signed-off-by: Russell King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1f3694865d5600bb23938f26a6effa843dc7cbca Author: Thomas Gleixner Date: Fri Feb 8 14:48:03 2019 +0100 genirq: Avoid summation loops for /proc/stat [ Upstream commit 1136b0728969901a091f0471968b2b76ed14d9ad ] Waiman reported that on large systems with a large amount of interrupts the readout of /proc/stat takes a long time to sum up the interrupt statistics. In principle this is not a problem. but for unknown reasons some enterprise quality software reads /proc/stat with a high frequency. The reason for this is that interrupt statistics are accounted per cpu. So the /proc/stat logic has to sum up the interrupt stats for each interrupt. This can be largely avoided for interrupts which are not marked as 'PER_CPU' interrupts by simply adding a per interrupt summation counter which is incremented along with the per interrupt per cpu counter. The PER_CPU interrupts need to avoid that and use only per cpu accounting because they share the interrupt number and the interrupt descriptor and concurrent updates would conflict or require unwanted synchronization. Reported-by: Waiman Long Signed-off-by: Thomas Gleixner Reviewed-by: Waiman Long Reviewed-by: Marc Zyngier Reviewed-by: Davidlohr Bueso Cc: Matthew Wilcox Cc: Andrew Morton Cc: Alexey Dobriyan Cc: Kees Cook Cc: linux-fsdevel@vger.kernel.org Cc: Davidlohr Bueso Cc: Miklos Szeredi Cc: Daniel Colascione Cc: Dave Chinner Cc: Randy Dunlap Link: https://lkml.kernel.org/r/20190208135020.925487496@linutronix.de 8<------------- v2: Undo the unintentional layout change of struct irq_desc. include/linux/irqdesc.h | 1 + kernel/irq/chip.c | 12 ++++++++++-- kernel/irq/internals.h | 8 +++++++- kernel/irq/irqdesc.c | 7 ++++++- 4 files changed, 24 insertions(+), 4 deletions(-) Signed-off-by: Sasha Levin commit 98eddc19f9e9a0c941fa85315bbbd1083b3e0db3 Author: Coly Li Date: Sat Feb 9 12:52:59 2019 +0800 bcache: improve sysfs_strtoul_clamp() [ Upstream commit 596b5a5dd1bc2fa019fdaaae522ef331deef927f ] Currently sysfs_strtoul_clamp() is defined as, 82 #define sysfs_strtoul_clamp(file, var, min, max) \ 83 do { \ 84 if (attr == &sysfs_ ## file) \ 85 return strtoul_safe_clamp(buf, var, min, max) \ 86 ?: (ssize_t) size; \ 87 } while (0) The problem is, if bit width of var is less then unsigned long, min and max may not protect var from integer overflow, because overflow happens in strtoul_safe_clamp() before checking min and max. To fix such overflow in sysfs_strtoul_clamp(), to make min and max take effect, this patch adds an unsigned long variable, and uses it to macro strtoul_safe_clamp() to convert an unsigned long value in range defined by [min, max]. Then assign this value to var. By this method, if bit width of var is less than unsigned long, integer overflow won't happen before min and max are checking. Now sysfs_strtoul_clamp() can properly handle smaller data type like unsigned int, of cause min and max should be defined in range of unsigned int too. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b468e0007435222879d5f4b52f7681a9ac2e1640 Author: Coly Li Date: Sat Feb 9 12:53:05 2019 +0800 bcache: fix potential div-zero error of writeback_rate_i_term_inverse [ Upstream commit c3b75a2199cdbfc1c335155fe143d842604b1baa ] dc->writeback_rate_i_term_inverse can be set via sysfs interface. It is in type unsigned int, and convert from input string by d_strtoul(). The problem is d_strtoul() does not check valid range of the input, if 4294967296 is written into sysfs file writeback_rate_i_term_inverse, an overflow of unsigned integer will happen and value 0 is set to dc->writeback_rate_i_term_inverse. In writeback.c:__update_writeback_rate(), there are following lines of code, integral_scaled = div_s64(dc->writeback_rate_integral, dc->writeback_rate_i_term_inverse); If dc->writeback_rate_i_term_inverse is set to 0 via sysfs interface, a div-zero error might be triggered in the above code. Therefore we need to add a range limitation in the sysfs interface, this is what this patch does, use sysfs_stroul_clamp() to replace d_strtoul() and restrict the input range in [1, UINT_MAX]. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c7b687ebe0fbd164ab0f8715fe7a098002c44f0f Author: Coly Li Date: Sat Feb 9 12:53:01 2019 +0800 bcache: fix input overflow to sequential_cutoff [ Upstream commit 8c27a3953e92eb0b22dbb03d599f543a05f9574e ] People may set sequential_cutoff of a cached device via sysfs file, but current code does not check input value overflow. E.g. if value 4294967295 (UINT_MAX) is written to file sequential_cutoff, its value is 4GB, but if 4294967296 (UINT_MAX + 1) is written into, its value will be 0. This is an unexpected behavior. This patch replaces d_strtoi_h() by sysfs_strtoul_clamp() to convert input string to unsigned integer value, and limit its range in [0, UINT_MAX]. Then the input overflow can be fixed. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 16975f04f2ca526ea66872319f4ab4a501d4af38 Author: Coly Li Date: Sat Feb 9 12:53:10 2019 +0800 bcache: fix input overflow to cache set sysfs file io_error_halflife [ Upstream commit a91fbda49f746119828f7e8ad0f0aa2ab0578f65 ] Cache set sysfs entry io_error_halflife is used to set c->error_decay. c->error_decay is in type unsigned int, and it is converted by strtoul_or_return(), therefore overflow to c->error_decay is possible for a large input value. This patch fixes the overflow by using strtoul_safe_clamp() to convert input string to an unsigned long value in range [0, UINT_MAX], then divides by 88 and set it to c->error_decay. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 845d4849b60cd024c24b6cf4d112ab85fed1ce14 Author: Luc Van Oostenryck Date: Fri Jan 18 15:49:36 2019 +0100 sched/topology: Fix percpu data types in struct sd_data & struct s_data [ Upstream commit 99687cdbb3f6c8e32bcc7f37496e811f30460e48 ] The percpu members of struct sd_data and s_data are declared as: struct ... ** __percpu member; So their type is: __percpu pointer to pointer to struct ... But looking at how they're used, their type should be: pointer to __percpu pointer to struct ... and they should thus be declared as: struct ... * __percpu *member; So fix the placement of '__percpu' in the definition of these structures. This addresses a bunch of Sparse's warnings like: warning: incorrect type in initializer (different address spaces) expected void const [noderef] *__vpp_verify got struct sched_domain ** Signed-off-by: Luc Van Oostenryck Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/20190118144936.79158-1-luc.vanoostenryck@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit ad02fb6a6cc87563aed320cf9cd99b110bd3686b Author: John Stultz Date: Tue Feb 5 10:24:40 2019 -0800 usb: f_fs: Avoid crash due to out-of-scope stack ptr access [ Upstream commit 54f64d5c983f939901dacc8cfc0983727c5c742e ] Since the 5.0 merge window opened, I've been seeing frequent crashes on suspend and reboot with the trace: [ 36.911170] Unable to handle kernel paging request at virtual address ffffff801153d660 [ 36.912769] Unable to handle kernel paging request at virtual address ffffff800004b564 ... [ 36.950666] Call trace: [ 36.950670] queued_spin_lock_slowpath+0x1cc/0x2c8 [ 36.950681] _raw_spin_lock_irqsave+0x64/0x78 [ 36.950692] complete+0x28/0x70 [ 36.950703] ffs_epfile_io_complete+0x3c/0x50 [ 36.950713] usb_gadget_giveback_request+0x34/0x108 [ 36.950721] dwc3_gadget_giveback+0x50/0x68 [ 36.950723] dwc3_thread_interrupt+0x358/0x1488 [ 36.950731] irq_thread_fn+0x30/0x88 [ 36.950734] irq_thread+0x114/0x1b0 [ 36.950739] kthread+0x104/0x130 [ 36.950747] ret_from_fork+0x10/0x1c I isolated this down to in ffs_epfile_io(): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/function/f_fs.c#n1065 Where the completion done is setup on the stack: DECLARE_COMPLETION_ONSTACK(done); Then later we setup a request and queue it, and wait for it: if (unlikely(wait_for_completion_interruptible(&done))) { /* * To avoid race condition with ffs_epfile_io_complete, * dequeue the request first then check * status. usb_ep_dequeue API should guarantee no race * condition with req->complete callback. */ usb_ep_dequeue(ep->ep, req); interrupted = ep->status < 0; } The problem is, that we end up being interrupted, dequeue the request, and exit. But then the irq triggers and we try calling complete() on the context pointer which points to now random stack space, which results in the panic. Alan Stern pointed out there is a bug here, in that the snippet above "assumes that usb_ep_dequeue() waits until the request has been completed." And that: wait_for_completion(&done); Is needed right after the usb_ep_dequeue(). Thus this patch implements that change. With it I no longer see the crashes on suspend or reboot. This issue seems to have been uncovered by behavioral changes in the dwc3 driver in commit fec9095bdef4e ("usb: dwc3: gadget: remove wait_end_transfer"). Cc: Alan Stern Cc: Felipe Balbi Cc: Zeng Tao Cc: Jack Pham Cc: Thinh Nguyen Cc: Chen Yu Cc: Jerry Zhang Cc: Lars-Peter Clausen Cc: Vincent Pelletier Cc: Andrzej Pietrasiewicz Cc: Greg Kroah-Hartman Cc: Linux USB List Suggested-by: Alan Stern Signed-off-by: John Stultz Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 126f2f6af291ac4695ba952fcfcaf646f73173dc Author: Rakesh Pillai Date: Fri Feb 8 15:50:24 2019 +0200 ath10k: fix shadow register implementation for WCN3990 [ Upstream commit 1863008369ae0407508033b4b00f98b985adeb15 ] WCN3990 supports shadow registers write operation support for copy engine for regular operation in powersave mode. Since WCN3990 is a 64-bit target, the shadow register implementation needs to be done in the copy engine handlers for 64-bit target. Currently the shadow register implementation is present in the 32-bit target handlers of copy engine. Fix the shadow register copy engine write operation implementation for 64-bit target(WCN3990). Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1 Fixes: b7ba83f7c414 ("ath10k: add support for shadow register for WNC3990") Signed-off-by: Rakesh Pillai Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit ccce764322d8d95262009892c354ed3acdcafb6f Author: Ranjani Sridharan Date: Fri Feb 8 17:29:53 2019 -0600 ALSA: PCM: check if ops are defined before suspending PCM [ Upstream commit d9c0b2afe820fa3b3f8258a659daee2cc71ca3ef ] BE dai links only have internal PCM's and their substream ops may not be set. Suspending these PCM's will result in their ops->trigger() being invoked and cause a kernel oops. So skip suspending PCM's if their ops are NULL. [ NOTE: this change is required now for following the recent PCM core change to get rid of snd_pcm_suspend() call. Since DPCM BE takes the runtime carried from FE while keeping NULL ops, it can hit this bug. See details at: https://github.com/thesofproject/linux/pull/582 -- tiwai ] Signed-off-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d21a63fc1e53f16911c8f162f739b85b734bdf04 Author: Martin Blumenstingl Date: Sat Dec 29 15:35:56 2018 +0100 ARM: dts: meson8b: fix the Ethernet data line signals in eth_rgmii_pins [ Upstream commit 29f0023d01f063feacfc404f0446905aee4f82ee ] According to the Odroid-C1+ schematics the Ethernet TXD1 signal is routed to GPIOH_5 and the TXD0 signal is routed to GPIOH_6. The public S805 datasheet shows that TXD0 can be routed to DIF_2_P and TXD1 can be routed to DIF_2_N instead. The pin groups eth_txd0_0 (GPIOH_6) and eth_txd0_1 (DIF_2_P) are both configured as Ethernet TXD0 and TXD1 data lines in meson8b.dtsi. At the same time eth_txd1_0 (GPIOH_5) and eth_txd1_1 (DIF_2_N) are configured as TXD0 and TXD1 data lines as well. This results in a bad Ethernet receive performance. Presumably this is due to the eth_txd0 and eth_txd1 signal being routed to the wrong pins. As a result of that data can only be transmitted on eth_txd2 and eth_txd3. However, I have no scope to fully confirm this assumption. The vendor u-boot sources for Odroid-C1 use the following Ethernet pinmux configuration: SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_6, 0x3f4f); SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_7, 0xf00000); This translates to the following pin groups in the mainline kernel: - register 6 bit 0: eth_rxd1 (DIF_0_P) - register 6 bit 1: eth_rxd0 (DIF_0_N) - register 6 bit 2: eth_rx_dv (DIF_1_P) - register 6 bit 3: eth_rx_clk (DIF_1_N) - register 6 bit 6: eth_tx_en (DIF_3_P) - register 6 bit 8: eth_ref_clk (DIF_3_N) - register 6 bit 9: eth_mdc (DIF_4_P) - register 6 bit 10: eth_mdio_en (DIF_4_N) - register 6 bit 11: eth_tx_clk (GPIOH_9) - register 6 bit 12: eth_txd2 (GPIOH_8) - register 6 bit 13: eth_txd3 (GPIOH_7) - register 7 bit 20: eth_txd0_0 (GPIOH_6) - register 7 bit 21: eth_txd1_0 (GPIOH_5) - register 7 bit 22: eth_rxd3 (DIF_2_P) - register 7 bit 23: eth_rxd2 (DIF_2_N) Drop the eth_txd0_1 and eth_txd1_1 groups from eth_rgmii_pins to fix the Ethernet transmit performance on Odroid-C1. Also add the eth_rxd2 and eth_rxd3 groups so we don't rely on the bootloader to set them up. iperf3 statistics before this change: - transmitting from Odroid-C1: 741 Mbits/sec (0 retries) - receiving on Odroid-C1: 199 Mbits/sec (1713 retries) iperf3 statistics after this change: - transmitting from Odroid-C1: 667 Mbits/sec (0 retries) - receiving on Odroid-C1: 750 Mbits/sec (0 retries) Fixes: b96446541d8390 ("ARM: dts: meson8b: extend ethernet controller description") Signed-off-by: Martin Blumenstingl Cc: Emiliano Ingrassia Cc: Linus Lüssing Tested-by: Emiliano Ingrassia Reviewed-by: Emiliano Ingrassia Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit d93fe5e6c9d92e3fc4f245422050c91d7f385836 Author: Nathan Chancellor Date: Sat Feb 2 03:34:36 2019 +0100 ARM: 8833/1: Ensure that NEON code always compiles with Clang [ Upstream commit de9c0d49d85dc563549972edc5589d195cd5e859 ] While building arm32 allyesconfig, I ran into the following errors: arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with '-mfloat-abi=softfp -mfpu=neon' In file included from lib/raid6/neon1.c:27: /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2: error: "NEON support not enabled" Building V=1 showed NEON_FLAGS getting passed along to Clang but __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang only defining __ARM_NEON__ when targeting armv7, rather than armv6k, which is the '-march' value for allyesconfig. >From lib/Basic/Targets/ARM.cpp in the Clang source: // This only gets set when Neon instructions are actually available, unlike // the VFP define, hence the soft float and arch check. This is subtly // different from gcc, we follow the intent which was that it should be set // when Neon instructions are actually available. if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) { Builder.defineMacro("__ARM_NEON", "1"); Builder.defineMacro("__ARM_NEON__"); // current AArch32 NEON implementations do not support double-precision // floating-point even when it is present in VFP. Builder.defineMacro("__ARM_NEON_FP", "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP)); } Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets definined by Clang. This doesn't functionally change anything because that code will only run where NEON is supported, which is implicitly armv7. Link: https://github.com/ClangBuiltLinux/linux/issues/287 Suggested-by: Ard Biesheuvel Signed-off-by: Nathan Chancellor Acked-by: Nicolas Pitre Reviewed-by: Nick Desaulniers Reviewed-by: Stefan Agner Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 3a1ce9793855935a2d2b4d9dc5003d42f797f6fc Author: Chieh-Min Wang Date: Tue Feb 12 00:59:55 2019 +0100 netfilter: conntrack: fix cloned unconfirmed skb->_nfct race in __nf_conntrack_confirm [ Upstream commit 13f5251fd17088170c18844534682d9cab5ff5aa ] For bridge(br_flood) or broadcast/multicast packets, they could clone skb with unconfirmed conntrack which break the rule that unconfirmed skb->_nfct is never shared. With nfqueue running on my system, the race can be easily reproduced with following warning calltrace: [13257.707525] CPU: 0 PID: 12132 Comm: main Tainted: P W 4.4.60 #7744 [13257.707568] Hardware name: Qualcomm (Flattened Device Tree) [13257.714700] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [13257.720253] [] (show_stack) from [] (dump_stack+0x94/0xa8) [13257.728240] [] (dump_stack) from [] (warn_slowpath_common+0x94/0xb0) [13257.735268] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [13257.743519] [] (warn_slowpath_null) from [] (__nf_conntrack_confirm+0xa8/0x618) [13257.752284] [] (__nf_conntrack_confirm) from [] (ipv4_confirm+0xb8/0xfc) [13257.761049] [] (ipv4_confirm) from [] (nf_iterate+0x48/0xa8) [13257.769725] [] (nf_iterate) from [] (nf_hook_slow+0x30/0xb0) [13257.777108] [] (nf_hook_slow) from [] (br_nf_post_routing+0x274/0x31c) [13257.784486] [] (br_nf_post_routing) from [] (nf_iterate+0x48/0xa8) [13257.792556] [] (nf_iterate) from [] (nf_hook_slow+0x30/0xb0) [13257.800458] [] (nf_hook_slow) from [] (br_forward_finish+0x94/0xa4) [13257.808010] [] (br_forward_finish) from [] (br_nf_forward_finish+0x150/0x1ac) [13257.815736] [] (br_nf_forward_finish) from [] (nf_reinject+0x108/0x170) [13257.824762] [] (nf_reinject) from [] (nfqnl_recv_verdict+0x3d8/0x420) [13257.832924] [] (nfqnl_recv_verdict) from [] (nfnetlink_rcv_msg+0x158/0x248) [13257.841256] [] (nfnetlink_rcv_msg) from [] (netlink_rcv_skb+0x54/0xb0) [13257.849762] [] (netlink_rcv_skb) from [] (netlink_unicast+0x148/0x23c) [13257.858093] [] (netlink_unicast) from [] (netlink_sendmsg+0x2ec/0x368) [13257.866348] [] (netlink_sendmsg) from [] (sock_sendmsg+0x34/0x44) [13257.874590] [] (sock_sendmsg) from [] (___sys_sendmsg+0x1ec/0x200) [13257.882489] [] (___sys_sendmsg) from [] (__sys_sendmsg+0x3c/0x64) [13257.890300] [] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x34) The original code just triggered the warning but do nothing. It will caused the shared conntrack moves to the dying list and the packet be droppped (nf_ct_resolve_clash returns NF_DROP for dying conntrack). - Reproduce steps: +----------------------------+ | br0(bridge) | | | +-+---------+---------+------+ | eth0| | eth1| | eth2| | | | | | | +--+--+ +--+--+ +---+-+ | | | | | | +--+-+ +-+--+ +--+-+ | PC1| | PC2| | PC3| +----+ +----+ +----+ iptables -A FORWARD -m mark --mark 0x1000000/0x1000000 -j NFQUEUE --queue-num 100 --queue-bypass ps: Our nfq userspace program will set mark on packets whose connection has already been processed. PC1 sends broadcast packets simulated by hping3: hping3 --rand-source --udp 192.168.1.255 -i u100 - Broadcast racing flow chart is as follow: br_handle_frame BR_HOOK(NFPROTO_BRIDGE, NF_BR_PRE_ROUTING, br_handle_frame_finish) // skb->_nfct (unconfirmed conntrack) is constructed at PRE_ROUTING stage br_handle_frame_finish // check if this packet is broadcast br_flood_forward br_flood list_for_each_entry_rcu(p, &br->port_list, list) // iterate through each port maybe_deliver deliver_clone skb = skb_clone(skb) __br_forward BR_HOOK(NFPROTO_BRIDGE, NF_BR_FORWARD,...) // queue in our nfq and received by our userspace program // goto __nf_conntrack_confirm with process context on CPU 1 br_pass_frame_up BR_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN,...) // goto __nf_conntrack_confirm with softirq context on CPU 0 Because conntrack confirm can happen at both INPUT and POSTROUTING stage. So with NFQUEUE running, skb->_nfct with the same unconfirmed conntrack could race on different core. This patch fixes a repeating kernel splat, now it is only displayed once. Signed-off-by: Chieh-Min Wang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d53b295f78057749bf803fe323988f917351fa08 Author: Masami Hiramatsu Date: Wed Feb 13 01:14:37 2019 +0900 kprobes: Prohibit probing on RCU debug routine [ Upstream commit a39f15b9644fac3f950f522c39e667c3af25c588 ] Since kprobe itself depends on RCU, probing on RCU debug routine can cause recursive breakpoint bugs. Prohibit probing on RCU debug routines. int3 ->do_int3() ->ist_enter() ->RCU_LOCKDEP_WARN() ->debug_lockdep_rcu_enabled() -> int3 Signed-off-by: Masami Hiramatsu Cc: Alexander Shishkin Cc: Andrea Righi Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/154998807741.31052.11229157537816341591.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit bc9d714395e2d44d35698b415c6dd7eea7189fc5 Author: Andrea Righi Date: Wed Feb 13 01:15:34 2019 +0900 kprobes: Prohibit probing on bsearch() [ Upstream commit 02106f883cd745523f7766d90a739f983f19e650 ] Since kprobe breakpoing handler is using bsearch(), probing on this routine can cause recursive breakpoint problem. int3 ->do_int3() ->ftrace_int3_handler() ->ftrace_location() ->ftrace_location_range() ->bsearch() -> int3 Prohibit probing on bsearch(). Signed-off-by: Andrea Righi Acked-by: Masami Hiramatsu Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/154998813406.31052.8791425358974650922.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit c63cc8d1487c3a15baa03c016a4b4344cbd0137d Author: Tycho Andersen Date: Fri Jan 18 17:12:15 2019 -0700 selftests: skip seccomp get_metadata test if not real root [ Upstream commit 3aa415dd2128e478ea3225b59308766de0e94d6b ] The get_metadata() test requires real root, so let's skip it if we're not real root. Note that I used XFAIL here because that's what the test does later if CONFIG_CHEKCKPOINT_RESTORE happens to not be enabled. After looking at the code, there doesn't seem to be a nice way to skip tests defined as TEST(), since there's no return code (I tried exit(KSFT_SKIP), but that didn't work either...). So let's do it this way to be consistent, and easier to fix when someone comes along and fixes it. Signed-off-by: Tycho Andersen Acked-by: Kees Cook Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 2df541d0a665947c35d6ace0badab604b846cda2 Author: Hans de Goede Date: Mon Jan 7 17:08:20 2019 +0100 ACPI / video: Refactor and fix dmi_is_desktop() [ Upstream commit cecf3e3e0803462335e25d083345682518097334 ] This commit refactors the chassis-type detection introduced by commit 53fa1f6e8a59 ("ACPI / video: Only default only_lcd to true on Win8-ready _desktops_") (where desktop means anything without a builtin screen). The DMI chassis_type is an unsigned integer, so rather then doing a whole bunch of string-compares on it, convert it to an int and feed the result to a switch case. Note the switch case uses hex values, this is done because the spec uses hex values too. This changes the check for "Main Server Chassis" from checking for 11 decimal to 11 hexadecimal, this is a bug fix, the original check for 11 decimal was wrong. Fixes: 53fa1f6e8a59 ("ACPI / video: Only default only_lcd to true ...") Signed-off-by: Hans de Goede [ rjw: Drop redundant return statements ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d63105845ac5566b44778d1a7d7cf915be4635b1 Author: Sara Sharon Date: Thu Dec 13 14:47:40 2018 +0200 iwlwifi: pcie: fix emergency path [ Upstream commit c6ac9f9fb98851f47b978a9476594fc3c477a34d ] Allocator swaps the pending requests with 0 when it starts working. This means that relying on it n RX path to decide if to move to emergency is not always a good idea, since it may be zero, but there are still a lot of unallocated RBs in the system. Change allocator to decrement the pending requests on real time. It is more expensive since it accesses the atomic variable more times, but it gives the RX path a better idea of the system's status. Reported-by: Ilan Peer Signed-off-by: Sara Sharon Fixes: 868a1e863f95 ("iwlwifi: pcie: avoid empty free RB queue") Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 5cdd025907b8efac43478bb2890c7707e15c49fa Author: Thomas Richter Date: Mon Feb 11 11:06:27 2019 +0100 perf report: Add s390 diagnosic sampling descriptor size [ Upstream commit 2187d87eacd46f6214ce3dc9cfd7a558375a4153 ] On IBM z13 machine types 2964 and 2965 the descriptor sizes for sampling and diagnostic sampling entries might be missing in the trailer entry and are set to zero. This leads to a perf report failure when processing diagnostic sampling entries. This patch adds missing descriptor sizes when the trailer entry contains zero for these fields. Output before: [root@s38lp82 perf]# ./perf report --stdio | fgrep Samples 0xabbf0 [0x8]: failed to process type: 68 Error: failed to process sample [root@s38lp82 perf]# Output after: [root@s38lp82 perf]# ./perf report --stdio | fgrep Samples # Total Lost Samples: 0 # Samples: 3K of event 'SF_CYCLES_BASIC_DIAG' # Samples: 162 of event 'CF_DIAG' [root@s38lp82 perf]# Fixes: 2b1444f2e28b ("perf report: Add raw report support for s390 auxiliary trace") Signed-off-by: Thomas Richter Reviewed-by: Hendrik Brueckner Cc: Heiko Carstens Cc: Martin Schwidefsky Link: http://lkml.kernel.org/r/20190211100627.85714-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5658279f50eaedf607f07750b99e9d41103ba7b5 Author: Michal Kazior Date: Mon Feb 11 10:29:27 2019 +0100 leds: lp55xx: fix null deref on firmware load failure [ Upstream commit 5ddb0869bfc1bca6cfc592c74c64a026f936638c ] I've stumbled upon a kernel crash and the logs pointed me towards the lp5562 driver: > <4>[306013.841294] lp5562 0-0030: Direct firmware load for lp5562 failed with error -2 > <4>[306013.894990] lp5562 0-0030: Falling back to user helper > ... > <3>[306073.924886] lp5562 0-0030: firmware request failed > <1>[306073.939456] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > <4>[306074.251011] PC is at _raw_spin_lock+0x1c/0x58 > <4>[306074.255539] LR is at release_firmware+0x6c/0x138 > ... After taking a look I noticed firmware_release() could be called with either NULL or a dangling pointer. Fixes: 10c06d178df11 ("leds-lp55xx: support firmware interface") Signed-off-by: Michal Kazior Signed-off-by: Jacek Anaszewski Signed-off-by: Sasha Levin commit 9154420173d56cedc5739fdc3a57799e94ae8238 Author: Theodore Ts'o Date: Thu Feb 14 16:27:14 2019 -0500 jbd2: fix race when writing superblock [ Upstream commit 538bcaa6261b77e71d37f5596c33127c1a3ec3f7 ] The jbd2 superblock is lockless now, so there is probably a race condition between writing it so disk and modifing contents of it, which may lead to checksum error. The following race is the one case that we have captured. jbd2 fsstress jbd2_journal_commit_transaction jbd2_journal_update_sb_log_tail jbd2_write_superblock jbd2_superblock_csum_set jbd2_journal_revoke jbd2_journal_set_features(revork) modify superblock submit_bh(checksum incorrect) Fix this by locking the buffer head before modifing it. We always write the jbd2 superblock after we modify it, so this just means calling the lock_buffer() a little earlier. This checksum corruption problem can be reproduced by xfstests generic/475. Reported-by: zhangyi (F) Suggested-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit a74ebf047e4fcac88e89fc14603d6d43be01bd9a Author: Tejun Heo Date: Fri Feb 15 11:01:31 2019 -0800 cgroup, rstat: Don't flush subtree root unless necessary [ Upstream commit b4ff1b44bcd384d22fcbac6ebaf9cc0d33debe50 ] cgroup_rstat_cpu_pop_updated() is used to traverse the updated cgroups on flush. While it was only visiting updated ones in the subtree, it was visiting @root unconditionally. We can easily check whether @root is updated or not by looking at its ->updated_next just as with the cgroups in the subtree. * Remove the unnecessary cgroup_parent() test. The system root cgroup is never updated and thus its ->updated_next is always NULL. No need to test whether cgroup_parent() exists in addition to ->updated_next. * Terminate traverse if ->updated_next is NULL. This can only happen for subtree @root and there's no reason to visit it if it's not marked updated. This reduces cpu consumption when reading a lot of rstat backed files. In a micro benchmark reading stat from ~1600 cgroups, the sys time was lowered by >40%. Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b13eb5245f9f730e79ab17593c4e3c8a62fee3b4 Author: Hong Liu Date: Tue Feb 12 20:05:20 2019 +0800 HID: intel-ish-hid: avoid binding wrong ishtp_cl_device [ Upstream commit 0d28f49412405d87d3aae83da255070a46e67627 ] When performing a warm reset in ishtp bus driver, the ishtp_cl_device will not be removed, its fw_client still points to the already freed ishtp_device.fw_clients array. Later after driver finishing ishtp client enumeration, this dangling pointer may cause driver to bind the wrong ishtp_cl_device to the new client, causing wrong callback to be called for messages intended for the new client. This helps in development of firmware where frequent switching of firmwares is required without Linux reboot. Signed-off-by: Hong Liu Tested-by: Hongyan Song Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c26d61ea90db085ad4871b5987f1cf033ce6cfb0 Author: Aurelien Jarno Date: Thu Dec 6 20:05:34 2018 +0100 vfs: fix preadv64v2 and pwritev64v2 compat syscalls with offset == -1 [ Upstream commit cc4b1242d7e3b42eed73881fc749944146493e4f ] The preadv2 and pwritev2 syscalls are supposed to emulate the readv and writev syscalls when offset == -1. Therefore the compat code should check for offset before calling do_compat_preadv64 and do_compat_pwritev64. This is the case for the preadv2 and pwritev2 syscalls, but handling of offset == -1 is missing in their 64-bit equivalent. This patch fixes that, calling do_compat_readv and do_compat_writev when offset == -1. This fixes the following glibc tests on x32: - misc/tst-preadvwritev2 - misc/tst-preadvwritev64v2 Cc: Alexander Viro Cc: H.J. Lu Signed-off-by: Aurelien Jarno Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 7273c2b1e79c042532960bcf55feaec33a288e41 Author: Oleksandr Andrushchenko Date: Thu Feb 14 16:23:20 2019 +0200 xen/gntdev: Do not destroy context while dma-bufs are in use [ Upstream commit fa13e665e02874c0a5f4d06d6967ae34a6cb3d6a ] If there are exported DMA buffers which are still in use and grant device is closed by either normal user-space close or by a signal this leads to the grant device context to be destroyed, thus making it not possible to correctly destroy those exported buffers when they are returned back to gntdev and makes the module crash: [ 339.617540] [] dmabuf_exp_ops_release+0x40/0xa8 [ 339.617560] [] dma_buf_release+0x60/0x190 [ 339.617577] [] __fput+0x88/0x1d0 [ 339.617589] [] ____fput+0xc/0x18 [ 339.617607] [] task_work_run+0x9c/0xc0 [ 339.617622] [] do_notify_resume+0xfc/0x108 Fix this by referencing gntdev on each DMA buffer export and unreferencing on buffer release. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Boris Ostrovsky@oracle.com> Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit e9cd7f5437640d4af2800c9db8283ec487332c43 Author: Lorenzo Bianconi Date: Sun Feb 10 22:49:15 2019 +0100 mt76: usb: do not run mt76u_queues_deinit twice [ Upstream commit b3098121c42caaf3aea239b8655cf52d45be116f ] Do not call mt76u_queues_deinit routine in mt76u_alloc_queues error path since it will be run in mt76x0u_register_device or mt76x2u_register_device error path. Current implementation triggers the following kernel warning: [ 67.005516] WARNING: CPU: 2 PID: 761 at lib/refcount.c:187 refcount_sub_and_test_checked+0xa4/0xb8 [ 67.019513] refcount_t: underflow; use-after-free. [ 67.099872] Hardware name: BCM2835 [ 67.106268] Backtrace: [ 67.111584] [<8010c91c>] (dump_backtrace) from [<8010cc00>] (show_stack+0x20/0x24) [ 67.124974] r6:60000013 r5:ffffffff r4:00000000 r3:a50bade6 [ 67.132226] [<8010cbe0>] (show_stack) from [<807ca5f4>] (dump_stack+0xc8/0x114) [ 67.141225] [<807ca52c>] (dump_stack) from [<8011e65c>] (__warn+0xf4/0x120) [ 67.149849] r9:000000bb r8:804d0138 r7:00000009 r6:8099dc84 r5:00000000 r4:b66c7b58 [ 67.160767] [<8011e568>] (__warn) from [<8011e6d0>] (warn_slowpath_fmt+0x48/0x50) [ 67.171436] r9:7f65e128 r8:80d1419c r7:80c0bac4 r6:b97b3044 r5:b7368e00 r4:00000000 [ 67.182433] [<8011e68c>] (warn_slowpath_fmt) from [<804d0138>] (refcount_sub_and_test_checked+0xa4/0xb8) [ 67.195221] r3:80c91c25 r2:8099dc94 [ 67.200370] r4:00000000 [ 67.204397] [<804d0094>] (refcount_sub_and_test_checked) from [<804d0164>] (refcount_dec_and_test_checked+0x18/0x1c) [ 67.218046] r4:b7368e00 r3:00000001 [ 67.223125] [<804d014c>] (refcount_dec_and_test_checked) from [<805db49c>] (usb_free_urb+0x20/0x4c) [ 67.235358] [<805db47c>] (usb_free_urb) from [<7f639804>] (mt76u_buf_free+0x98/0xac [mt76_usb]) [ 67.247302] r4:00000001 r3:00000001 [ 67.252468] [<7f63976c>] (mt76u_buf_free [mt76_usb]) from [<7f639ef8>] (mt76u_queues_deinit+0x44/0x100 [mt76_usb]) [ 67.266102] r8:b8fe8600 r7:b5dac480 r6:b5dace20 r5:00000001 r4:00000000 r3:00000080 [ 67.277132] [<7f639eb4>] (mt76u_queues_deinit [mt76_usb]) from [<7f65c040>] (mt76x0u_cleanup+0x40/0x4c [mt76x0u]) [ 67.290737] r7:b5dac480 r6:b8fe8600 r5:ffffffea r4:b5dace20 [ 67.298069] [<7f65c000>] (mt76x0u_cleanup [mt76x0u]) from [<7f65c564>] (mt76x0u_probe+0x1f0/0x354 [mt76x0u]) [ 67.311174] r4:b5dace20 r3:00000000 [ 67.316312] [<7f65c374>] (mt76x0u_probe [mt76x0u]) from [<805e0b6c>] (usb_probe_interface+0x104/0x240) [ 67.328915] r7:00000000 r6:7f65e034 r5:b6634800 r4:b8fe8620 [ 67.336276] [<805e0a68>] (usb_probe_interface) from [<8056a8bc>] (really_probe+0x224/0x2f8) [ 67.347965] r10:b65f0a00 r9:00000019 r8:7f65e034 r7:80d3e124 r6:00000000 r5:80d3e120 [ 67.359175] r4:b8fe8620 r3:805e0a68 [ 67.364384] [<8056a698>] (really_probe) from [<8056ab60>] (driver_probe_device+0x6c/0x180) [ 67.375974] r10:b65f0a00 r9:7f65e2c0 r8:b8fe8620 r7:00000000 r6:7f65e034 r5:7f65e034 [ 67.387170] r4:b8fe8620 r3:00000000 [ 67.392378] [<8056aaf4>] (driver_probe_device) from [<8056ad54>] (__driver_attach+0xe0/0xe4) [ 67.404097] r9:7f65e2c0 r8:7f65d22c r7:00000000 r6:b8fe8654 r5:7f65e034 r4:b8fe8620 [ 67.415122] [<8056ac74>] (__driver_attach) from [<8056880c>] (bus_for_each_dev+0x68/0xa0) [ 67.426628] r6:8056ac74 r5:7f65e034 r4:00000000 r3:00000027 [ 67.434017] [<805687a4>] (bus_for_each_dev) from [<8056a1cc>] (driver_attach+0x28/0x30) [ 67.445394] r6:80c6ddc8 r5:b7368f80 r4:7f65e034 [ 67.451703] [<8056a1a4>] (driver_attach) from [<80569c24>] (bus_add_driver+0x194/0x21c) [ 67.463081] [<80569a90>] (bus_add_driver) from [<8056b504>] (driver_register+0x8c/0x124) [ 67.474560] r7:80c6ddc8 r6:7f65e034 r5:00000000 r4:7f65e034 [ 67.481964] [<8056b478>] (driver_register) from [<805df510>] (usb_register_driver+0x74/0x140) [ 67.493901] r5:00000000 r4:7f65e000 [ 67.499131] [<805df49c>] (usb_register_driver) from [<7f661024>] (mt76x0_driver_init+0x24/0x1000 [mt76x0u]) [ 67.512258] r9:00000001 r8:7f65e308 r7:00000000 r6:80c08d48 r5:7f661000 r4:7f65e2c0 [ 67.523404] [<7f661000>] (mt76x0_driver_init [mt76x0u]) from [<80102f6c>] (do_one_initcall+0x4c/0x210) [ 67.536142] [<80102f20>] (do_one_initcall) from [<801ae63c>] (do_init_module+0x6c/0x21c) [ 67.547639] r8:7f65e308 r7:80c08d48 r6:b65f0ac0 r5:7f65e2c0 r4:7f65e2c0 [ 67.556129] [<801ae5d0>] (do_init_module) from [<801ad68c>] (load_module+0x1d10/0x2304) Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5cde7721dd05149225df69d34df6abbd1bb732d1 Author: Ezequiel Garcia Date: Fri Feb 8 11:17:39 2019 -0500 media: mtk-jpeg: Correct return type for mem2mem buffer helpers [ Upstream commit 1b275e4e8b70dbff9850874b30831c1bd8d3c504 ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 745cdc344f97562b1b841a240058c97006fd3ab9 Author: Ezequiel Garcia Date: Fri Feb 8 11:17:42 2019 -0500 media: mx2_emmaprp: Correct return type for mem2mem buffer helpers [ Upstream commit 8d20dcefe471763f23ad538369ec65b51993ffff ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 73a4cc59054ebec1c2c2471a99b028ec9511397f Author: Ezequiel Garcia Date: Fri Feb 8 11:17:44 2019 -0500 media: s5p-g2d: Correct return type for mem2mem buffer helpers [ Upstream commit 30fa627b32230737bc3f678067e2adfecf956987 ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3c6cd079058ef2a5f923292e526954606cbe27eb Author: Ezequiel Garcia Date: Fri Feb 8 11:17:43 2019 -0500 media: rockchip/rga: Correct return type for mem2mem buffer helpers [ Upstream commit da2d3a4e4adabc6ccfb100bc9abd58ee9cd6c4b7 ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 55919fc2841946a968d851934385a17a0de786a8 Author: Ezequiel Garcia Date: Fri Feb 8 11:17:45 2019 -0500 media: s5p-jpeg: Correct return type for mem2mem buffer helpers [ Upstream commit 4a88f89885c7cf65c62793f385261a6e3315178a ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a23fd268fdbb0aed811f26679e926fe57aba9720 Author: Ezequiel Garcia Date: Fri Feb 8 11:17:46 2019 -0500 media: sh_veu: Correct return type for mem2mem buffer helpers [ Upstream commit 43c145195c7fc3025ee7ecfc67112ac1c82af7c2 ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 635fabdd8202b397b7b4b3f5997235ac06ee6bed Author: Akinobu Mita Date: Sun Feb 17 10:17:47 2019 -0500 media: ov7740: fix runtime pm initialization [ Upstream commit 12aceee1f412c3ddc7750155fec06c906f14ab51 ] The runtime PM of this device is enabled after v4l2_ctrl_handler_setup(), and this makes this device's runtime PM usage count a negative value. The ov7740_set_ctrl() tries to do something only if the device's runtime PM usage counter is nonzero. ov7740_set_ctrl() { if (!pm_runtime_get_if_in_use(&client->dev)) return 0; ; pm_runtime_put(&client->dev); return ret; } However, the ov7740_set_ctrl() is called by v4l2_ctrl_handler_setup() while the runtime PM of this device is not yet enabled. In this case, the pm_runtime_get_if_in_use() returns -EINVAL (!= 0). Therefore we can't bail out of this function and the usage count is decreased by pm_runtime_put() without increment. This fixes this problem by enabling the runtime PM of this device before v4l2_ctrl_handler_setup() so that the ov7740_set_ctrl() is always called when the runtime PM is enabled. Cc: Wenyou Yang Signed-off-by: Akinobu Mita Tested-by: Eugen Hristev Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1d836ce73a107acb951a389cd2a0e96696c54fbd Author: Wen Yang Date: Mon Feb 18 15:13:47 2019 +0000 SoC: imx-sgtl5000: add missing put_device() [ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ] The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. Detected by coccinelle with the following warnings: ./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device; call of_find_device_by_node on line 105, but without a corresponding object release within this function. ./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device; call of_find_device_by_node on line 105, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: Timur Tabi Cc: Nicolin Chen Cc: Xiubo Li Cc: Fabio Estevam Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: NXP Linux Team Cc: alsa-devel@alsa-project.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d41687c82a700b67ad5c400f20f6f37722e09de8 Author: He Kuang Date: Tue Feb 19 21:05:31 2019 +0800 perf report: Don't shadow inlined symbol with different addr range [ Upstream commit 7346195e8643482968f547483e0d823ec1982fab ] We can't assume inlined symbols with the same name are equal, because their address range may be different. This will cause the symbols with different addresses be shadowed when adding to the hist entry, and lead to ERANGE error when checking the symbol address during sample parse, the addr should be within the range of [sym.start, sym.end]. The error message is like: "0x36aea60 [0x8]: failed to process type: 68". The second parameter of symbol__new() is the length of the fake symbol for the inline frame, which is the subtraction of the end and start address of base_sym. Signed-off-by: He Kuang Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Milian Wolff Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: aa441895f7b4 ("perf report: Compare symbol name for inlined frames when sorting") Link: http://lkml.kernel.org/r/20190219130531.15692-1-hekuang@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 801b8d8c7729e11bfbd94a6782be800f8f5260e7 Author: Brian Norris Date: Thu Feb 14 16:31:29 2019 -0800 mwifiex: don't advertise IBSS features without FW support [ Upstream commit 6f21ab30469d670de620f758330aca9f3433f693 ] As it is, doing something like # iw phy phy0 interface add foobar type ibss on a firmware that doesn't have ad-hoc support just yields failures of HostCmd_CMD_SET_BSS_MODE, which happened to return a '-1' error code (-EPERM? not really right...) and sometimes may even crash the firmware along the way. Let's parse the firmware capability flag while registering the wiphy, so we don't allow attempting IBSS at all, and we get a proper -EOPNOTSUPP from nl80211 instead. Fixes: e267e71e68ae ("mwifiex: Disable adhoc feature based on firmware capability") Signed-off-by: Brian Norris Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit d323e59f58bb985b6c1de7aa4a620eb0fee22999 Author: Thomas Richter Date: Tue Feb 19 16:36:39 2019 +0100 perf test: Fix failure of 'evsel-tp-sched' test on s390 [ Upstream commit 03d309711d687460d1345de8a0363f45b1c8cd11 ] Commit 489338a717a0 ("perf tests evsel-tp-sched: Fix bitwise operator") causes test case 14 "Parse sched tracepoints fields" to fail on s390. This test succeeds on x86. In fact this test now fails on all architectures with type char treated as type unsigned char. The root cause is the signed-ness of character arrays in the tracepoints sched_switch for structure members prev_comm and next_comm. On s390 the output of: [root@m35lp76 perf]# cat /sys/kernel/debug/tracing/events/sched/sched_switch/format name: sched_switch ID: 287 format: field:unsigned short common_type; offset:0; size:2; signed:0; ... field:char prev_comm[16]; offset:8; size:16; signed:0; ... field:char next_comm[16]; offset:40; size:16; signed:0; reveals the character arrays prev_comm and next_comm are per default unsigned char and have values in the range of 0..255. On x86 both fields are signed as this output shows: [root@f29]# cat /sys/kernel/debug/tracing/events/sched/sched_switch/format name: sched_switch ID: 287 format: field:unsigned short common_type; offset:0; size:2; signed:0; ... field:char prev_comm[16]; offset:8; size:16; signed:1; ... field:char next_comm[16]; offset:40; size:16; signed:1; and the character arrays prev_comm and next_comm are per default signed char and have values in the range of -1..127. The implementation of type char is architecture specific. Since the character arrays in both tracepoints sched_switch and sched_wakeup should contain ascii characters, simply omit the check for signedness in the test case. Output before: [root@m35lp76 perf]# ./perf test -F 14 14: Parse sched tracepoints fields : --- start --- sched:sched_switch: "prev_comm" signedness(0) is wrong, should be 1 sched:sched_switch: "next_comm" signedness(0) is wrong, should be 1 sched:sched_wakeup: "comm" signedness(0) is wrong, should be 1 ---- end ---- 14: Parse sched tracepoints fields : FAILED! [root@m35lp76 perf]# Output after: [root@m35lp76 perf]# ./perf test -Fv 14 14: Parse sched tracepoints fields : --- start --- ---- end ---- Parse sched tracepoints fields: Ok [root@m35lp76 perf]# Fixes: 489338a717a0 ("perf tests evsel-tp-sched: Fix bitwise operator") Signed-off-by: Thomas Richter Cc: Heiko Carstens Cc: Hendrik Brueckner Cc: Martin Schwidefsky Link: http://lkml.kernel.org/r/20190219153639.31267-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 345c7757fd545009feb36cf1bbceab895b17a39c Author: Nicholas Kazlauskas Date: Fri Jan 25 15:23:09 2019 -0500 drm/amd/display: Clear stream->mode_changed after commit [ Upstream commit d8d2f174bcc2c26c3485c70e0c6fe22b27bce739 ] [Why] The stream->mode_changed flag can persist in the following sequence of atomic commits: Commit 1: Enable CRTC0 (mode_changed = true), Enable CRTC1 (mode_changed = true) Commit 2: Disable CRTC1 (mode_changed = false) In this sequence we want to keep the exiting CRTC0 but it's not in the atomic state for the commit since it hasn't been modified. In this case the stream->mode_changed flag persists as true and we don't re-program the planes for the existing stream. [How] The flag needs to be cleared and it makes the most sense to do it within DC after the state has been committed. Nothing following dc_commit_state should think that the stream's mode has changed. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Leo Li Acked-by: Tony Cheng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1ef1b20f8711782366854046df2fd5b2e8d29c5b Author: Sedat Dilek Date: Fri Feb 15 13:19:20 2019 +0100 scsi: fcoe: make use of fip_mode enum complete [ Upstream commit 8beb90aaf334a6efa3e924339926b5f93a234dbb ] commit 1917d42d14b7 ("fcoe: use enum for fip_mode") introduces a separate enum for the fip_mode that shall be used during initialisation handling until it is passed to fcoe_ctrl_link_up to set the initial fip_state. That change was incomplete and gcc quietly converted in various places between the fip_mode and the fip_state enum values with implicit enum conversions, which fortunately cannot cause any issues in the actual code's execution. clang however warns about these implicit enum conversions in the scsi drivers. This commit consolidates the use of the two enums, guided by clang's enum-conversion warnings. This commit now completes the use of the fip_mode: It expects and uses fip_mode in {bnx2fc,fcoe}_interface_create and fcoe_ctlr_init, and it calls fcoe_ctrl_set_set() with the correct values in fcoe_ctlr_link_up(). It also breaks the association between FIP_MODE_AUTO and FIP_ST_AUTO to indicate these two enums are distinct. Link: https://github.com/ClangBuiltLinux/linux/issues/151 Fixes: 1917d42d14b7 ("fcoe: use enum for fip_mode") Reported-by: Dmitry Golovin Original-by: Lukas Bulwahn CC: Lukas Bulwahn CC: Nick Desaulniers CC: Nathan Chancellor Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Suggested-by: Johannes Thumshirn Signed-off-by: Sedat Dilek Signed-off-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8032fc9120c211cd40beef4c91c8206f4167e523 Author: Jason Yan Date: Fri Feb 15 19:50:27 2019 +0800 scsi: megaraid_sas: return error when create DMA pool failed [ Upstream commit bcf3b67d16a4c8ffae0aa79de5853435e683945c ] when create DMA pool for cmd frames failed, we should return -ENOMEM, instead of 0. In some case in: megasas_init_adapter_fusion() -->megasas_alloc_cmds() -->megasas_create_frame_pool create DMA pool failed, --> megasas_free_cmds() [1] -->megasas_alloc_cmds_fusion() failed, then goto fail_alloc_cmds. -->megasas_free_cmds() [2] we will call megasas_free_cmds twice, [1] will kfree cmd_list, [2] will use cmd_list.it will cause a problem: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc000f70000 [00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003, *pmd=0000001fbf894003, *pte=006000006d000707 Internal error: Oops: 96000005 [#1] SMP Modules linked in: CPU: 18 PID: 1 Comm: swapper/0 Not tainted task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000 PC is at megasas_free_cmds+0x30/0x70 LR is at megasas_free_cmds+0x24/0x70 ... Call trace: [] megasas_free_cmds+0x30/0x70 [] megasas_init_adapter_fusion+0x2f4/0x4d8 [] megasas_init_fw+0x2dc/0x760 [] megasas_probe_one+0x3c0/0xcd8 [] local_pci_probe+0x4c/0xb4 [] pci_device_probe+0x11c/0x14c [] driver_probe_device+0x1ec/0x430 [] __driver_attach+0xa8/0xb0 [] bus_for_each_dev+0x74/0xc8 [] driver_attach+0x28/0x34 [] bus_add_driver+0x16c/0x248 [] driver_register+0x6c/0x138 [] __pci_register_driver+0x5c/0x6c [] megasas_init+0xc0/0x1a8 [] do_one_initcall+0xe8/0x1ec [] kernel_init_freeable+0x1c8/0x284 [] kernel_init+0x1c/0xe4 Signed-off-by: Jason Yan Acked-by: Sumit Saxena Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2c6e3ec8a90699b82c99acd44d5d3c4c7143818c Author: Sebastian Ott Date: Thu Feb 14 14:46:23 2019 +0100 s390/ism: ignore some errors during deregistration [ Upstream commit 0ff06c44efeede4acd068847d3bf8cf894b6c664 ] Prior to dma unmap/free operations the ism driver tries to ensure that the memory is no longer accessed by the HW. When errors during deregistration of memory regions from the HW occur the ism driver will not unmap/free this memory. When we receive notification from the hypervisor that a PCI function has been detached we can no longer access the device and would never unmap/free these memory regions which led to complaints by the DMA debug API. Treat this kind of errors during the deregistration of memory regions from the HW as success since it is already ensured that the memory is no longer accessed by HW. Reported-by: Karsten Graul Reported-by: Hans Wippel Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit d60f458e4c4dddb4d7ad20656d41a0d83a3d855b Author: Ross Lagerwall Date: Mon Jan 28 10:04:24 2019 +0000 efi: cper: Fix possible out-of-bounds access [ Upstream commit 45b14a4ffcc1e0b5caa246638f942cbe7eaea7ad ] When checking a generic status block, we iterate over all the generic data blocks. The loop condition only checks that the start of the generic data block is valid (within estatus->data_length) but not the whole block. Because the size of data blocks (excluding error data) may vary depending on the revision and the revision is contained within the data block, ensure that enough of the current data block is valid before dereferencing any members otherwise an out-of-bounds access may occur if estatus->data_length is invalid. This relies on the fact that struct acpi_hest_generic_data_v300 is a superset of the earlier version. Also rework the other checks to avoid potential underflow. Signed-off-by: Ross Lagerwall Acked-by: Borislav Petkov Tested-by: Tyler Baicar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e57f4676b92fb8764e6a3ecee182f991345a38f3 Author: Erwan Velu Date: Wed Feb 20 11:10:17 2019 +0100 cpufreq: acpi-cpufreq: Report if CPU doesn't support boost technologies [ Upstream commit 1222d527f314c86a3b59a522115d62facc5a7965 ] There is some rare cases where CPB (and possibly IDA) are missing on processors. This is the case fixed by commit f7f3dc00f612 ("x86/cpu/AMD: Fix erratum 1076 (CPB bit)") and following. In such context, the boost status isn't reported by /sys/devices/system/cpu/cpufreq/boost. This commit is about printing a message to report that the CPU doesn't expose the boost capabilities. This message could help debugging platforms hit by this phenomena. Signed-off-by: Erwan Velu [ rjw: Change the message text somewhat ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit eb70531a95c84ac3780a6ffc7e8d698ee5862b52 Author: Takashi Iwai Date: Tue Feb 19 16:46:51 2019 +0100 ASoC: qcom: Fix of-node refcount unbalance in qcom_snd_parse_of() [ Upstream commit 70b773219a32c7b8f3e53e041bc023ad99fd81f4 ] Although qcom_snd_parse_of() tries to manage the of-node refcount, there are still a few places that lead to the unblanced refcount in the error code path. Namely, - for_each_child_of_node() needs to unreference the iterator node if aborting the loop in the middle, - cpu, codec and platform node objects have to be unreferenced at each iteration, - platform and codec node objects have to be referred before jumping to the error handling code that unreference them unconditionally. This patch tries to address these by moving the assignment of platform and codec node objects to the beginning of the loop and adding the of_node_put() calls adequately. Fixes: c25e295cd77b ("ASoC: qcom: Add support to parse common audio device nodes") Cc: Patrick Lai Cc: Banajit Goswami Signed-off-by: Takashi Iwai Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e6786f8686ef815ca2b895ace258e5e64774c0f3 Author: Wei Li Date: Thu Feb 21 17:57:16 2019 +0800 perf annotate: Fix getting source line failure [ Upstream commit 11db1ad4513d6205d2519e1a30ff4cef746e3243 ] The output of "perf annotate -l --stdio xxx" changed since commit 425859ff0de33 ("perf annotate: No need to calculate notes->start twice") removed notes->start assignment in symbol__calc_lines(). It will get failed in find_address_in_section() from symbol__tty_annotate() subroutine as the a2l->addr is wrong. So the annotate summary doesn't report the line number of source code correctly. Before fix: liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ cat common_while_1.c void hotspot_1(void) { volatile int i; for (i = 0; i < 0x10000000; i++); for (i = 0; i < 0x10000000; i++); for (i = 0; i < 0x10000000; i++); } int main(void) { hotspot_1(); return 0; } liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ gcc common_while_1.c -g -o common_while_1 liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ sudo ./perf record ./common_while_1 [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.488 MB perf.data (12498 samples) ] liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ sudo ./perf annotate -l -s hotspot_1 --stdio Sorted summary for file /home/liwei/main_code/hulk_work/hulk/tools/perf/common_while_1 ---------------------------------------------- 19.30 common_while_1[32] 19.03 common_while_1[4e] 19.01 common_while_1[16] 5.04 common_while_1[13] 4.99 common_while_1[4b] 4.78 common_while_1[2c] 4.77 common_while_1[10] 4.66 common_while_1[2f] 4.59 common_while_1[51] 4.59 common_while_1[35] 4.52 common_while_1[19] 4.20 common_while_1[56] 0.51 common_while_1[48] Percent | Source code & Disassembly of common_while_1 for cycles:ppp (12480 samples, percent: local period) ----------------------------------------------------------------------------------------------------------------- : : : : Disassembly of section .text: : : 00000000000005fa : : hotspot_1(): : void hotspot_1(void) : { 0.00 : 5fa: push %rbp 0.00 : 5fb: mov %rsp,%rbp : volatile int i; : : for (i = 0; i < 0x10000000; i++); 0.00 : 5fe: movl $0x0,-0x4(%rbp) 0.00 : 605: jmp 610 0.00 : 607: mov -0x4(%rbp),%eax common_while_1[10] 4.77 : 60a: add $0x1,%eax common_while_1[13] 5.04 : 60d: mov %eax,-0x4(%rbp) common_while_1[16] 19.01 : 610: mov -0x4(%rbp),%eax common_while_1[19] 4.52 : 613: cmp $0xfffffff,%eax 0.00 : 618: jle 607 : for (i = 0; i < 0x10000000; i++); ... After fix: liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ sudo ./perf record ./common_while_1 [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.488 MB perf.data (12500 samples) ] liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ sudo ./perf annotate -l -s hotspot_1 --stdio Sorted summary for file /home/liwei/main_code/hulk_work/hulk/tools/perf/common_while_1 ---------------------------------------------- 33.34 common_while_1.c:5 33.34 common_while_1.c:6 33.32 common_while_1.c:7 Percent | Source code & Disassembly of common_while_1 for cycles:ppp (12482 samples, percent: local period) ----------------------------------------------------------------------------------------------------------------- : : : : Disassembly of section .text: : : 00000000000005fa : : hotspot_1(): : void hotspot_1(void) : { 0.00 : 5fa: push %rbp 0.00 : 5fb: mov %rsp,%rbp : volatile int i; : : for (i = 0; i < 0x10000000; i++); 0.00 : 5fe: movl $0x0,-0x4(%rbp) 0.00 : 605: jmp 610 0.00 : 607: mov -0x4(%rbp),%eax common_while_1.c:5 4.70 : 60a: add $0x1,%eax 4.89 : 60d: mov %eax,-0x4(%rbp) common_while_1.c:5 19.03 : 610: mov -0x4(%rbp),%eax common_while_1.c:5 4.72 : 613: cmp $0xfffffff,%eax 0.00 : 618: jle 607 : for (i = 0; i < 0x10000000; i++); 0.00 : 61a: movl $0x0,-0x4(%rbp) 0.00 : 621: jmp 62c 0.00 : 623: mov -0x4(%rbp),%eax common_while_1.c:6 4.54 : 626: add $0x1,%eax 4.73 : 629: mov %eax,-0x4(%rbp) common_while_1.c:6 19.54 : 62c: mov -0x4(%rbp),%eax common_while_1.c:6 4.54 : 62f: cmp $0xfffffff,%eax ... Signed-off-by: Wei Li Acked-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Jin Yao Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: 425859ff0de33 ("perf annotate: No need to calculate notes->start twice") Link: http://lkml.kernel.org/r/20190221095716.39529-1-liwei391@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 763a895aa49cc93c94c271678d07490632c1adb3 Author: Katsuhiro Suzuki Date: Mon Feb 11 00:38:06 2019 +0900 clk: fractional-divider: check parent rate only if flag is set [ Upstream commit d13501a2bedfbea0983cc868d3f1dc692627f60d ] Custom approximation of fractional-divider may not need parent clock rate checking. For example Rockchip SoCs work fine using grand parent clock rate even if target rate is greater than parent. This patch checks parent clock rate only if CLK_SET_RATE_PARENT flag is set. For detailed example, clock tree of Rockchip I2S audio hardware. - Clock rate of CPLL is 1.2GHz, GPLL is 491.52MHz. - i2s1_div is integer divider can divide N (N is 1~128). Input clock is CPLL or GPLL. Initial divider value is N = 1. Ex) PLL = CPLL, N = 10, i2s1_div output rate is CPLL / 10 = 1.2GHz / 10 = 120MHz - i2s1_frac is fractional divider can divide input to x/y, x and y are 16bit integer. CPLL --> | selector | ---> i2s1_div -+--> | selector | --> I2S1 MCLK GPLL --> | | ,--------------' | | `--> i2s1_frac ---> | | Clock mux system try to choose suitable one from i2s1_div and i2s1_frac for master clock (MCLK) of I2S1. Bad scenario as follows: - Try to set MCLK to 8.192MHz (32kHz audio replay) Candidate setting is - i2s1_div: GPLL / 60 = 8.192MHz i2s1_div candidate is exactly same as target clock rate, so mux choose this clock source. i2s1_div output rate is changed 491.52MHz -> 8.192MHz - After that try to set to 11.2896MHz (44.1kHz audio replay) Candidate settings are - i2s1_div : CPLL / 107 = 11.214945MHz - i2s1_frac: i2s1_div = 8.192MHz This is because clk_fd_round_rate() thinks target rate (11.2896MHz) is higher than parent rate (i2s1_div = 8.192MHz) and returns parent clock rate. Above is current upstreamed behavior. Clock mux system choose i2s1_div, but this clock rate is not acceptable for I2S driver, so users cannot replay audio. Expected behavior is: - Try to set master clock to 11.2896MHz (44.1kHz audio replay) Candidate settings are - i2s1_div : CPLL / 107 = 11.214945MHz - i2s1_frac: i2s1_div * 147/6400 = 11.2896MHz Change i2s1_div to GPLL / 1 = 491.52MHz at same time. If apply this commit, clk_fd_round_rate() calls custom approximate function of Rockchip even if target rate is higher than parent. Custom function changes both grand parent (i2s1_div) and parent (i2s_frac) settings at same time. Clock mux system can choose i2s1_frac and audio works fine. Signed-off-by: Katsuhiro Suzuki Reviewed-by: Heiko Stuebner [sboyd@kernel.org: Make function into a macro instead] Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit d3ec442d609b2476efb5b6556e1c176b543690f4 Author: Håkon Bugge Date: Sun Feb 17 15:45:12 2019 +0100 IB/mlx4: Increase the timeout for CM cache [ Upstream commit 2612d723aadcf8281f9bf8305657129bd9f3cd57 ] Using CX-3 virtual functions, either from a bare-metal machine or pass-through from a VM, MAD packets are proxied through the PF driver. Since the VF drivers have separate name spaces for MAD Transaction Ids (TIDs), the PF driver has to re-map the TIDs and keep the book keeping in a cache. Following the RDMA Connection Manager (CM) protocol, it is clear when an entry has to evicted form the cache. But life is not perfect, remote peers may die or be rebooted. Hence, it's a timeout to wipe out a cache entry, when the PF driver assumes the remote peer has gone. During workloads where a high number of QPs are destroyed concurrently, excessive amount of CM DREQ retries has been observed The problem can be demonstrated in a bare-metal environment, where two nodes have instantiated 8 VFs each. This using dual ported HCAs, so we have 16 vPorts per physical server. 64 processes are associated with each vPort and creates and destroys one QP for each of the remote 64 processes. That is, 1024 QPs per vPort, all in all 16K QPs. The QPs are created/destroyed using the CM. When tearing down these 16K QPs, excessive CM DREQ retries (and duplicates) are observed. With some cat/paste/awk wizardry on the infiniband_cm sysfs, we observe as sum of the 16 vPorts on one of the nodes: cm_rx_duplicates: dreq 2102 cm_rx_msgs: drep 1989 dreq 6195 rep 3968 req 4224 rtu 4224 cm_tx_msgs: drep 4093 dreq 27568 rep 4224 req 3968 rtu 3968 cm_tx_retries: dreq 23469 Note that the active/passive side is equally distributed between the two nodes. Enabling pr_debug in cm.c gives tons of: [171778.814239] mlx4_ib_multiplex_cm_handler: id{slave: 1,sl_cm_id: 0xd393089f} is NULL! By increasing the CM_CLEANUP_CACHE_TIMEOUT from 5 to 30 seconds, the tear-down phase of the application is reduced from approximately 90 to 50 seconds. Retries/duplicates are also significantly reduced: cm_rx_duplicates: dreq 2460 [] cm_tx_retries: dreq 3010 req 47 Increasing the timeout further didn't help, as these duplicates and retries stems from a too short CMA timeout, which was 20 (~4 seconds) on the systems. By increasing the CMA timeout to 22 (~17 seconds), the numbers fell down to about 10 for both of them. Adjustment of the CMA timeout is not part of this commit. Signed-off-by: Håkon Bugge Acked-by: Jack Morgenstein Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 61584032c4d6e0510fe5cd1add7728e1e898be5f Author: Dongli Zhang Date: Fri Feb 22 22:10:20 2019 +0800 loop: set GENHD_FL_NO_PART_SCAN after blkdev_reread_part() [ Upstream commit 758a58d0bc67457f1215321a536226654a830eeb ] Commit 0da03cab87e6 ("loop: Fix deadlock when calling blkdev_reread_part()") moves blkdev_reread_part() out of the loop_ctl_mutex. However, GENHD_FL_NO_PART_SCAN is set before __blkdev_reread_part(). As a result, __blkdev_reread_part() will fail the check of GENHD_FL_NO_PART_SCAN and will not rescan the loop device to delete all partitions. Below are steps to reproduce the issue: step1 # dd if=/dev/zero of=tmp.raw bs=1M count=100 step2 # losetup -P /dev/loop0 tmp.raw step3 # parted /dev/loop0 mklabel gpt step4 # parted -a none -s /dev/loop0 mkpart primary 64s 1 step5 # losetup -d /dev/loop0 Step5 will not be able to delete /dev/loop0p1 (introduced by step4) and there is below kernel warning message: [ 464.414043] __loop_clr_fd: partition scan of loop0 failed (rc=-22) This patch sets GENHD_FL_NO_PART_SCAN after blkdev_reread_part(). Fixes: 0da03cab87e6 ("loop: Fix deadlock when calling blkdev_reread_part()") Signed-off-by: Dongli Zhang Reviewed-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 07a31820b241fff43a9ad5619db8c663f13dd6c0 Author: Vadim Pasternak Date: Sun Feb 17 18:15:30 2019 +0000 platform/mellanox: mlxreg-hotplug: Fix KASAN warning [ Upstream commit e4c275f77624961b56cce397814d9d770a45ac59 ] Fix the following KASAN warning produced when booting a 64-bit kernel: [ 13.334750] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x19/0x70 [ 13.342166] Read of size 8 at addr ffff880235067178 by task kworker/2:1/42 [ 13.342176] CPU: 2 PID: 42 Comm: kworker/2:1 Not tainted 4.20.0-rc1+ #106 [ 13.342179] Hardware name: Mellanox Technologies Ltd. MSN2740/Mellanox x86 SFF board, BIOS 5.6.5 06/07/2016 [ 13.342190] Workqueue: events deferred_probe_work_func [ 13.342194] Call Trace: [ 13.342206] dump_stack+0xc7/0x15b [ 13.342214] ? show_regs_print_info+0x5/0x5 [ 13.342220] ? kmsg_dump_rewind_nolock+0x59/0x59 [ 13.342234] ? _raw_write_lock_irqsave+0x100/0x100 [ 13.351593] print_address_description+0x73/0x260 [ 13.351603] kasan_report+0x260/0x380 [ 13.351611] ? find_first_bit+0x19/0x70 [ 13.351619] find_first_bit+0x19/0x70 [ 13.351630] mlxreg_hotplug_work_handler+0x73c/0x920 [mlxreg_hotplug] [ 13.351639] ? __lock_text_start+0x8/0x8 [ 13.351646] ? _raw_write_lock_irqsave+0x80/0x100 [ 13.351656] ? mlxreg_hotplug_remove+0x1e0/0x1e0 [mlxreg_hotplug] [ 13.351663] ? regmap_volatile+0x40/0xb0 [ 13.351668] ? regcache_write+0x4c/0x90 [ 13.351676] ? mlxplat_mlxcpld_reg_write+0x24/0x30 [mlx_platform] [ 13.351681] ? _regmap_write+0xea/0x220 [ 13.351688] ? __mutex_lock_slowpath+0x10/0x10 [ 13.351696] ? devm_add_action+0x70/0x70 [ 13.351701] ? mutex_unlock+0x1d/0x40 [ 13.351710] mlxreg_hotplug_probe+0x82e/0x989 [mlxreg_hotplug] [ 13.351723] ? mlxreg_hotplug_work_handler+0x920/0x920 [mlxreg_hotplug] [ 13.351731] ? sysfs_do_create_link_sd.isra.2+0xf4/0x190 [ 13.351737] ? sysfs_rename_link_ns+0xf0/0xf0 [ 13.351743] ? devres_close_group+0x2b0/0x2b0 [ 13.351749] ? pinctrl_put+0x20/0x20 [ 13.351755] ? acpi_dev_pm_attach+0x2c/0xd0 [ 13.351763] platform_drv_probe+0x70/0xd0 [ 13.351771] really_probe+0x480/0x6e0 [ 13.351778] ? device_attach+0x10/0x10 [ 13.351784] ? __lock_text_start+0x8/0x8 [ 13.351790] ? _raw_write_lock_irqsave+0x80/0x100 [ 13.351797] ? _raw_write_lock_irqsave+0x80/0x100 [ 13.351806] ? __driver_attach+0x190/0x190 [ 13.351812] driver_probe_device+0x17d/0x1a0 [ 13.351819] ? __driver_attach+0x190/0x190 [ 13.351825] bus_for_each_drv+0xd6/0x130 [ 13.351831] ? bus_rescan_devices+0x20/0x20 [ 13.351837] ? __mutex_lock_slowpath+0x10/0x10 [ 13.351845] __device_attach+0x18c/0x230 [ 13.351852] ? device_bind_driver+0x70/0x70 [ 13.351859] ? __mutex_lock_slowpath+0x10/0x10 [ 13.351866] bus_probe_device+0xea/0x110 [ 13.351874] deferred_probe_work_func+0x1c9/0x290 [ 13.351882] ? driver_deferred_probe_add+0x1d0/0x1d0 [ 13.351889] ? preempt_notifier_dec+0x20/0x20 [ 13.351897] ? read_word_at_a_time+0xe/0x20 [ 13.351904] ? strscpy+0x151/0x290 [ 13.351912] ? set_work_pool_and_clear_pending+0x9c/0xf0 [ 13.351918] ? __switch_to_asm+0x34/0x70 [ 13.351924] ? __switch_to_asm+0x40/0x70 [ 13.351929] ? __switch_to_asm+0x34/0x70 [ 13.351935] ? __switch_to_asm+0x40/0x70 [ 13.351942] process_one_work+0x5cc/0xa00 [ 13.351952] ? pwq_dec_nr_in_flight+0x1e0/0x1e0 [ 13.351960] ? pci_mmcfg_check_reserved+0x80/0xb8 [ 13.351967] ? run_rebalance_domains+0x250/0x250 [ 13.351980] ? stack_access_ok+0x35/0x80 [ 13.351986] ? deref_stack_reg+0xa1/0xe0 [ 13.351994] ? schedule+0xcd/0x250 [ 13.352000] ? worker_enter_idle+0x2d6/0x330 [ 13.352006] ? __schedule+0xeb0/0xeb0 [ 13.352014] ? fork_usermode_blob+0x130/0x130 [ 13.352019] ? mutex_lock+0xa7/0x100 [ 13.352026] ? _raw_spin_lock_irq+0x98/0xf0 [ 13.352032] ? _raw_read_unlock_irqrestore+0x30/0x30 [ 13.352037] i2c i2c-2: Added multiplexed i2c bus 11 [ 13.352043] worker_thread+0x181/0xa80 [ 13.352052] ? __switch_to_asm+0x34/0x70 [ 13.352058] ? __switch_to_asm+0x40/0x70 [ 13.352064] ? process_one_work+0xa00/0xa00 [ 13.352070] ? __switch_to_asm+0x34/0x70 [ 13.352076] ? __switch_to_asm+0x40/0x70 [ 13.352081] ? __switch_to_asm+0x34/0x70 [ 13.352086] ? __switch_to_asm+0x40/0x70 [ 13.352092] ? __switch_to_asm+0x34/0x70 [ 13.352097] ? __switch_to_asm+0x40/0x70 [ 13.352105] ? __schedule+0x3d6/0xeb0 [ 13.352112] ? migrate_swap_stop+0x470/0x470 [ 13.352119] ? save_stack+0x89/0xb0 [ 13.352127] ? kmem_cache_alloc_trace+0xe5/0x570 [ 13.352132] ? kthread+0x59/0x1d0 [ 13.352138] ? ret_from_fork+0x35/0x40 [ 13.352154] ? __schedule+0xeb0/0xeb0 [ 13.352161] ? remove_wait_queue+0x150/0x150 [ 13.352169] ? _raw_write_lock_irqsave+0x80/0x100 [ 13.352175] ? __lock_text_start+0x8/0x8 [ 13.352183] ? process_one_work+0xa00/0xa00 [ 13.352188] kthread+0x1a4/0x1d0 [ 13.352195] ? kthread_create_worker_on_cpu+0xc0/0xc0 [ 13.352202] ret_from_fork+0x35/0x40 [ 13.353879] The buggy address belongs to the page: [ 13.353885] page:ffffea0008d419c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0 [ 13.353890] flags: 0x2ffff8000000000() [ 13.353897] raw: 02ffff8000000000 ffffea0008d419c8 ffffea0008d419c8 0000000000000000 [ 13.353903] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 13.353905] page dumped because: kasan: bad access detected [ 13.353908] Memory state around the buggy address: [ 13.353912] ffff880235067000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 13.353917] ffff880235067080: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 [ 13.353921] >ffff880235067100: f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2 04 [ 13.353923] ^ [ 13.353927] ffff880235067180: f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 00 00 00 00 00 [ 13.353931] ffff880235067200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 13.353933] ================================================================== The warning is caused by the below loop: for_each_set_bit(bit, (unsigned long *)&asserted, 8) { while "asserted" is declared as 'unsigned'. The casting of 32-bit unsigned integer pointer to a 64-bit unsigned long pointer. There are two problems here. It causes the access of four extra byte, which can corrupt memory The 32-bit pointer address may not be 64-bit aligned. The fix changes variable "asserted" to "unsigned long". Fixes: 1f976f6978bf ("platform/x86: Move Mellanox platform hotplug driver to platform/mellanox") Signed-off-by: Vadim Pasternak Signed-off-by: Darren Hart (VMware) Signed-off-by: Sasha Levin commit 0bacfb4adc1be8f8b724ce5bfc5dfb5337d190cf Author: Yang Fan Date: Sat Jan 19 19:16:33 2019 +0800 platform/x86: ideapad-laptop: Fix no_hw_rfkill_list for Lenovo RESCUER R720-15IKBN [ Upstream commit 4d9b2864a415fec39150bc13efc730c7eb88711e ] Commit ae7c8cba3221 ("platform/x86: ideapad-laptop: add lenovo RESCUER R720-15IKBN to no_hw_rfkill_list") added DMI_MATCH(DMI_BOARD_NAME, "80WW") for Lenovo RESCUER R720-15IKBN. But DMI_BOARD_NAME does not match 80WW on Lenovo RESCUER R720-15IKBN, thus cause Wireless LAN still be hard blocked. On Lenovo RESCUER R720-15IKBN: ~$ cat /sys/class/dmi/id/sys_vendor LENOVO ~$ cat /sys/class/dmi/id/board_name Provence-5R3 ~$ cat /sys/class/dmi/id/product_name 80WW ~$ cat /sys/class/dmi/id/product_version Lenovo R720-15IKBN So on Lenovo RESCUER R720-15IKBN: DMI_SYS_VENDOR should match "LENOVO", DMI_BOARD_NAME should match "Provence-5R3", DMI_PRODUCT_NAME should match "80WW", DMI_PRODUCT_VERSION should match "Lenovo R720-15IKBN". Fix it, and in according with other entries in no_hw_rfkill_list, use DMI_PRODUCT_VERSION instead of DMI_BOARD_NAME. Fixes: ae7c8cba3221 ("platform/x86: ideapad-laptop: add lenovo RESCUER R720-15IKBN to no_hw_rfkill_list") Signed-off-by: Yang Fan Signed-off-by: Darren Hart (VMware) Signed-off-by: Sasha Levin commit a64ffbaf7056c1081e007d72012a43e6ec1391d6 Author: Florian Fainelli Date: Thu Feb 21 20:09:26 2019 -0800 mlxsw: spectrum: Avoid -Wformat-truncation warnings [ Upstream commit ab2c4e2581ad32c28627235ff0ae8c5a5ea6899f ] Give precision identifiers to the two snprintf() formatting the priority and TC strings to avoid producing these two warnings: drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function 'mlxsw_sp_port_get_prio_strings': drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:37: warning: '%d' directive output may be truncated writing between 1 and 3 bytes into a region of size between 0 and 31 [-Wformat-truncation=] snprintf(*p, ETH_GSTRING_LEN, "%s_%d", ^~ drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:3: note: 'snprintf' output between 3 and 36 bytes into a destination of size 32 snprintf(*p, ETH_GSTRING_LEN, "%s_%d", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mlxsw_sp_port_hw_prio_stats[i].str, prio); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function 'mlxsw_sp_port_get_tc_strings': drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:37: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=] snprintf(*p, ETH_GSTRING_LEN, "%s_%d", ^~ drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:3: note: 'snprintf' output between 3 and 44 bytes into a destination of size 32 snprintf(*p, ETH_GSTRING_LEN, "%s_%d", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mlxsw_sp_port_hw_tc_stats[i].str, tc); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Florian Fainelli Reviewed-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 49dd86f0f5ece4e7addc0f8db5e75a2fb404ede6 Author: Florian Fainelli Date: Thu Feb 21 20:09:28 2019 -0800 e1000e: Fix -Wformat-truncation warnings [ Upstream commit 135e7245479addc6b1f5d031e3d7e2ddb3d2b109 ] Provide precision hints to snprintf() since we know the destination buffer size of the RX/TX ring names are IFNAMSIZ + 5 - 1. This fixes the following warnings: drivers/net/ethernet/intel/e1000e/netdev.c: In function 'e1000_request_msix': drivers/net/ethernet/intel/e1000e/netdev.c:2109:13: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] "%s-rx-0", netdev->name); ^ drivers/net/ethernet/intel/e1000e/netdev.c:2107:3: note: 'snprintf' output between 6 and 21 bytes into a destination of size 20 snprintf(adapter->rx_ring->name, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(adapter->rx_ring->name) - 1, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%s-rx-0", netdev->name); ~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/intel/e1000e/netdev.c:2125:13: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] "%s-tx-0", netdev->name); ^ drivers/net/ethernet/intel/e1000e/netdev.c:2123:3: note: 'snprintf' output between 6 and 21 bytes into a destination of size 20 snprintf(adapter->tx_ring->name, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(adapter->tx_ring->name) - 1, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%s-tx-0", netdev->name); ~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c6fb45d895e0d5579f2a880429c7b30c9bf593d7 Author: Andrew Lunn Date: Sat Feb 23 17:43:56 2019 +0100 net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat [ Upstream commit f6d9758b12660484b6639364cc406da92a918c96 ] The following false positive lockdep splat has been observed. ====================================================== WARNING: possible circular locking dependency detected 4.20.0+ #302 Not tainted ------------------------------------------------------ systemd-udevd/160 is trying to acquire lock: edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704 but task is already holding lock: edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&desc->request_mutex){+.+.}: mutex_lock_nested+0x1c/0x24 __setup_irq+0xa0/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 -> #0 (&chip->reg_lock){+.+.}: __mutex_lock+0x50/0x8b8 mutex_lock_nested+0x1c/0x24 __setup_irq+0x640/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx] mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&desc->request_mutex); lock(&chip->reg_lock); lock(&desc->request_mutex); lock(&chip->reg_lock); &desc->request_mutex refer to two different mutex. #1 is the GPIO for the chip interrupt. #2 is the chained interrupt between global 1 and global 2. Add lockdep classes to the GPIO interrupt to avoid this. Reported-by: Russell King Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 194b888af85e21852d195f1a70f25a9b851ab97f Author: Aaro Koskinen Date: Sun Feb 3 00:14:33 2019 +0200 mmc: omap: fix the maximum timeout setting [ Upstream commit a6327b5e57fdc679c842588c3be046c0b39cc127 ] When running OMAP1 kernel on QEMU, MMC access is annoyingly noisy: MMC: CTO of 0xff and 0xfe cannot be used! MMC: CTO of 0xff and 0xfe cannot be used! MMC: CTO of 0xff and 0xfe cannot be used! [ad inf.] Emulator warnings appear to be valid. The TI document SPRU680 [1] ("OMAP5910 Dual-Core Processor MultiMedia Card/Secure Data Memory Card (MMC/SD) Reference Guide") page 36 states that the maximum timeout is 253 cycles and "0xff and 0xfe cannot be used". Fix by using 0xfd as the maximum timeout. Tested using QEMU 2.5 (Siemens SX1 machine, OMAP310), and also checked on real hardware using Palm TE (OMAP310), Nokia 770 (OMAP1710) and Nokia N810 (OMAP2420) that MMC works as before. [1] http://www.ti.com/lit/ug/spru680/spru680.pdf Fixes: 730c9b7e6630f ("[MMC] Add OMAP MMC host driver") Signed-off-by: Aaro Koskinen Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit dcedd37957de3e54a194a044befefd7687e023a1 Author: Qu Wenruo Date: Fri Jan 25 07:55:27 2019 +0800 btrfs: qgroup: Make qgroup async transaction commit more aggressive [ Upstream commit f5fef4593653dfa2a865c485bb81415de51d5c99 ] [BUG] Btrfs qgroup will still hit EDQUOT under the following case: $ dev=/dev/test/test $ mnt=/mnt/btrfs $ umount $mnt &> /dev/null $ umount $dev &> /dev/null $ mkfs.btrfs -f $dev $ mount $dev $mnt -o nospace_cache $ btrfs subv create $mnt/subv $ btrfs quota enable $mnt $ btrfs quota rescan -w $mnt $ btrfs qgroup limit -e 1G $mnt/subv $ fallocate -l 900M $mnt/subv/padding $ sync $ rm $mnt/subv/padding # Hit EDQUOT $ xfs_io -f -c "pwrite 0 512M" $mnt/subv/real_file [CAUSE] Since commit a514d63882c3 ("btrfs: qgroup: Commit transaction in advance to reduce early EDQUOT"), btrfs is not forced to commit transaction to reclaim more quota space. Instead, we just check pertrans metadata reservation against some threshold and try to do asynchronously transaction commit. However in above case, the pertrans metadata reservation is pretty small thus it will never trigger asynchronous transaction commit. [FIX] Instead of only accounting pertrans metadata reservation, we calculate how much free space we have, and if there isn't much free space left, commit transaction asynchronously to try to free some space. This may slow down the fs when we have less than 32M free qgroup space, but should reduce a lot of false EDQUOT, so the cost should be acceptable. Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6cf5f631bad0af8b76f6a827c6855518b1259136 Author: Aneesh Kumar K.V Date: Tue Feb 26 10:09:34 2019 +0530 powerpc/hugetlb: Handle mmap_min_addr correctly in get_unmapped_area callback [ Upstream commit 5330367fa300742a97e20e953b1f77f48392faae ] After we ALIGN up the address we need to make sure we didn't overflow and resulted in zero address. In that case, we need to make sure that the returned address is greater than mmap_min_addr. This fixes selftest va_128TBswitch --run-hugetlb reporting failures when run as non root user for mmap(-1, MAP_HUGETLB) The bug is that a non-root user requesting address -1 will be given address 0 which will then fail, whereas they should have been given something else that would have succeeded. We also avoid the first mmap(-1, MAP_HUGETLB) returning NULL address as mmap address with this change. So we think this is not a security issue, because it only affects whether we choose an address below mmap_min_addr, not whether we actually allow that address to be mapped. ie. there are existing capability checks to prevent a user mapping below mmap_min_addr and those will still be honoured even without this fix. Fixes: 484837601d4d ("powerpc/mm: Add radix support for hugetlb") Reviewed-by: Laurent Dufour Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit fc96b44c05c2e7bf3ab94195b429e440c7ac03fd Author: Nicolas Boichat Date: Mon Jan 28 17:43:01 2019 +0800 iommu/io-pgtable-arm-v7s: Only kmemleak_ignore L2 tables [ Upstream commit 032ebd8548c9d05e8d2bdc7a7ec2fe29454b0ad0 ] L1 tables are allocated with __get_dma_pages, and therefore already ignored by kmemleak. Without this, the kernel would print this error message on boot, when the first L1 table is allocated: [ 2.810533] kmemleak: Trying to color unknown object at 0xffffffd652388000 as Black [ 2.818190] CPU: 5 PID: 39 Comm: kworker/5:0 Tainted: G S 4.19.16 #8 [ 2.831227] Workqueue: events deferred_probe_work_func [ 2.836353] Call trace: ... [ 2.852532] paint_ptr+0xa0/0xa8 [ 2.855750] kmemleak_ignore+0x38/0x6c [ 2.859490] __arm_v7s_alloc_table+0x168/0x1f4 [ 2.863922] arm_v7s_alloc_pgtable+0x114/0x17c [ 2.868354] alloc_io_pgtable_ops+0x3c/0x78 ... Fixes: e5fc9753b1a8314 ("iommu/io-pgtable: Add ARMv7 short descriptor support") Signed-off-by: Nicolas Boichat Acked-by: Will Deacon Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit d81bdb3c17f1a2f760f257c60950c176df1e77ef Author: Sebastian Andrzej Siewior Date: Wed Feb 13 17:14:42 2019 +0100 ARM: 8840/1: use a raw_spinlock_t in unwind [ Upstream commit 74ffe79ae538283bbf7c155e62339f1e5c87b55a ] Mostly unwind is done with irqs enabled however SLUB may call it with irqs disabled while creating a new SLUB cache. I had system freeze while loading a module which called kmem_cache_create() on init. That means SLUB's __slab_alloc() disabled interrupts and then ->new_slab_objects() ->new_slab() ->setup_object() ->setup_object_debug() ->init_tracking() ->set_track() ->save_stack_trace() ->save_stack_trace_tsk() ->walk_stackframe() ->unwind_frame() ->unwind_find_idx() =>spin_lock_irqsave(&unwind_lock); Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 951307172652c5acf8bfa4ce994c8f6392e79e40 Author: Lubomir Rintel Date: Sun Feb 24 12:58:02 2019 +0100 serial: 8250_pxa: honor the port number from devicetree [ Upstream commit fe9ed6d2483fda55465f32924fb15bce0fac3fac ] Like the other OF-enabled drivers, use the port number from the firmware if the devicetree specifies an alias: aliases { ... serial2 = &uart2; /* Should be ttyS2 */ } This is how the deprecated pxa.c driver behaved, switching to 8250_pxa messes up the numbering. Signed-off-by: Lubomir Rintel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2636ccec991e520a3f1969a89e2d8ed1d46aa72d Author: Sai Prakash Ranjan Date: Mon Feb 25 10:54:01 2019 -0700 coresight: etm4x: Add support to enable ETMv4.2 [ Upstream commit 5666dfd1d8a45a167f0d8b4ef47ea7f780b1f24a ] SDM845 has ETMv4.2 and can use the existing etm4x driver. But the current etm driver checks only for ETMv4.0 and errors out for other etm4x versions. This patch adds this missing support to enable SoC's with ETMv4x to use same driver by checking only the ETM architecture major version number. Without this change, we get below error during etm probe: / # dmesg | grep etm [ 6.660093] coresight-etm4x: probe of 7040000.etm failed with error -22 [ 6.666902] coresight-etm4x: probe of 7140000.etm failed with error -22 [ 6.673708] coresight-etm4x: probe of 7240000.etm failed with error -22 [ 6.680511] coresight-etm4x: probe of 7340000.etm failed with error -22 [ 6.687313] coresight-etm4x: probe of 7440000.etm failed with error -22 [ 6.694113] coresight-etm4x: probe of 7540000.etm failed with error -22 [ 6.700914] coresight-etm4x: probe of 7640000.etm failed with error -22 [ 6.707717] coresight-etm4x: probe of 7740000.etm failed with error -22 With this change, etm probe is successful: / # dmesg | grep etm [ 6.659198] coresight-etm4x 7040000.etm: CPU0: ETM v4.2 initialized [ 6.665848] coresight-etm4x 7140000.etm: CPU1: ETM v4.2 initialized [ 6.672493] coresight-etm4x 7240000.etm: CPU2: ETM v4.2 initialized [ 6.679129] coresight-etm4x 7340000.etm: CPU3: ETM v4.2 initialized [ 6.685770] coresight-etm4x 7440000.etm: CPU4: ETM v4.2 initialized [ 6.692403] coresight-etm4x 7540000.etm: CPU5: ETM v4.2 initialized [ 6.699024] coresight-etm4x 7640000.etm: CPU6: ETM v4.2 initialized [ 6.705646] coresight-etm4x 7740000.etm: CPU7: ETM v4.2 initialized Signed-off-by: Sai Prakash Ranjan Reviewed-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c70214d519ed83333322c6a39113c1c388f31a79 Author: Nathan Chancellor Date: Mon Feb 25 22:38:55 2019 -0700 powerpc/xmon: Fix opcode being uninitialized in print_insn_powerpc [ Upstream commit e7140639b1de65bba435a6bd772d134901141f86 ] When building with -Wsometimes-uninitialized, Clang warns: arch/powerpc/xmon/ppc-dis.c:157:7: warning: variable 'opcode' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (cpu_has_feature(CPU_FTRS_POWER9)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/xmon/ppc-dis.c:167:7: note: uninitialized use occurs here if (opcode == NULL) ^~~~~~ arch/powerpc/xmon/ppc-dis.c:157:3: note: remove the 'if' if its condition is always true if (cpu_has_feature(CPU_FTRS_POWER9)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/xmon/ppc-dis.c:132:38: note: initialize the variable 'opcode' to silence this warning const struct powerpc_opcode *opcode; ^ = NULL 1 warning generated. This warning seems to make no sense on the surface because opcode is set to NULL right below this statement. However, there is a comma instead of semicolon to end the dialect assignment, meaning that the opcode assignment only happens in the if statement. Properly terminate that line so that Clang no longer warns. Fixes: 5b102782c7f4 ("powerpc/xmon: Enable disassembly files (compilation changes)") Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 638ecaf5836979ad1c6f6c3fdd738ee9e71c0b07 Author: Masahiro Yamada Date: Fri Feb 22 16:40:10 2019 +0900 kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing [ Upstream commit 9390dff66a52d1a60c6e517d8fa6cdbdffc83cb1 ] If include/config/auto.conf.cmd is lost for some reasons, it is not self-healing, so the top Makefile misses to run syncconfig. Move include/config/auto.conf.cmd to the target side. I used a pattern rule instead of a normal rule here although it is a bit gross. If the rule were written with a normal rule like this, include/config/auto.conf \ include/config/auto.conf.cmd \ include/config/tristate.conf: $(KCONFIG_CONFIG) $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig ... syncconfig would be executed per target. Using a pattern rule makes sure that syncconfig is executed just once because Make assumes the recipe will create all of the targets. Here is a quote from the GNU Make manual [1]: "Pattern rules may have more than one target. Unlike normal rules, this does not act as many different rules with the same prerequisites and recipe. If a pattern rule has multiple targets, make knows that the rule's recipe is responsible for making all of the targets. The recipe is executed only once to make all the targets. When searching for a pattern rule to match a target, the target patterns of a rule other than the one that matches the target in need of a rule are incidental: make worries only about giving a recipe and prerequisites to the file presently in question. However, when this file's recipe is run, the other targets are marked as having been updated themselves." [1]: https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 5db107484403e11fd01517485949d25ea2e3c363 Author: Benjamin Block Date: Thu Feb 21 10:18:00 2019 +0100 scsi: core: replace GFP_ATOMIC with GFP_KERNEL in scsi_scan.c [ Upstream commit 1749ef00f7312679f76d5e9104c5d1e22a829038 ] We had a test-report where, under memory pressure, adding LUNs to the systems would fail (the tests add LUNs strictly in sequence): [ 5525.853432] scsi 0:0:1:1088045124: Direct-Access IBM 2107900 .148 PQ: 0 ANSI: 5 [ 5525.853826] scsi 0:0:1:1088045124: alua: supports implicit TPGS [ 5525.853830] scsi 0:0:1:1088045124: alua: device naa.6005076303ffd32700000000000044da port group 0 rel port 43 [ 5525.853931] sd 0:0:1:1088045124: Attached scsi generic sg10 type 0 [ 5525.854075] sd 0:0:1:1088045124: [sdk] Disabling DIF Type 1 protection [ 5525.855495] sd 0:0:1:1088045124: [sdk] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB) [ 5525.855606] sd 0:0:1:1088045124: [sdk] Write Protect is off [ 5525.855609] sd 0:0:1:1088045124: [sdk] Mode Sense: ed 00 00 08 [ 5525.855795] sd 0:0:1:1088045124: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5525.857838] sdk: sdk1 [ 5525.859468] sd 0:0:1:1088045124: [sdk] Attached SCSI disk [ 5525.865073] sd 0:0:1:1088045124: alua: transition timeout set to 60 seconds [ 5525.865078] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA [ 5526.015070] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA [ 5526.015213] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA [ 5526.587439] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured [ 5526.588562] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured Looking at the code of scsi_alloc_sdev(), and all the calling contexts, there seems to be no reason to use GFP_ATMOIC here. All the different call-contexts use a mutex at some point, and nothing in between that requires no sleeping, as far as I could see. Additionally, the code that later allocates the block queue for the device (scsi_mq_alloc_queue()) already uses GFP_KERNEL. There are similar allocations in two other functions: scsi_probe_and_add_lun(), and scsi_add_lun(),; that can also be done with GFP_KERNEL. Here is the contexts for the three functions so far: scsi_alloc_sdev() scsi_probe_and_add_lun() scsi_sequential_lun_scan() __scsi_scan_target() scsi_scan_target() mutex_lock() scsi_scan_channel() scsi_scan_host_selected() mutex_lock() scsi_report_lun_scan() __scsi_scan_target() ... __scsi_add_device() mutex_lock() __scsi_scan_target() ... scsi_report_lun_scan() ... scsi_get_host_dev() mutex_lock() scsi_probe_and_add_lun() ... scsi_add_lun() scsi_probe_and_add_lun() ... So replace all these, and give them a bit of a better chance to succeed, with more chances of reclaim. Signed-off-by: Benjamin Block Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4acf797458ce1f2ffc5304bb2dba85699acf353f Author: Alexey Kardashevskiy Date: Wed Feb 13 14:38:18 2019 +1100 powerpc/powernv/ioda: Fix locked_vm counting for memory used by IOMMU tables [ Upstream commit 11f5acce2fa43b015a8120fa7620fa4efd0a2952 ] We store 2 multilevel tables in iommu_table - one for the hardware and one with the corresponding userspace addresses. Before allocating the tables, the iommu_table_group_ops::get_table_size() hook returns the combined size of the two and VFIO SPAPR TCE IOMMU driver adjusts the locked_vm counter correctly. When the table is actually allocated, the amount of allocated memory is stored in iommu_table::it_allocated_size and used to decrement the locked_vm counter when we release the memory used by the table; .get_table_size() and .create_table() calculate it independently but the result is expected to be the same. However the allocator does not add the userspace table size to .it_allocated_size so when we destroy the table because of VFIO PCI unplug (i.e. VFIO container is gone but the userspace keeps running), we decrement locked_vm by just a half of size of memory we are releasing. To make things worse, since we enabled on-demand allocation of indirect levels, it_allocated_size contains only the amount of memory actually allocated at the table creation time which can just be a fraction. It is not a problem with incrementing locked_vm (as get_table_size() value is used) but it is with decrementing. As the result, we leak locked_vm and may not be able to allocate more IOMMU tables after few iterations of hotplug/unplug. This sets it_allocated_size in the pnv_pci_ioda2_ops::create_table() hook to what pnv_pci_ioda2_get_table_size() returns so from now on we have a single place which calculates the maximum memory a table can occupy. The original meaning of it_allocated_size is somewhat lost now though. We do not ditch it_allocated_size whatsoever here and we do not call get_table_size() from vfio_iommu_spapr_tce.c when decrementing locked_vm as we may have multiple IOMMU groups per container and even though they all are supposed to have the same get_table_size() implementation, there is a small chance for failure or confusion. Fixes: 090bad39b237 ("powerpc/powernv: Add indirect levels to it_userspace") Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 6030bcc04735e4c02f0286f5981e22c4dfa21efa Author: Paul Kocialkowski Date: Wed Feb 27 06:51:36 2019 +0000 usb: chipidea: Grab the (legacy) USB PHY by phandle first [ Upstream commit 68ef236274793066b9ba3154b16c0acc1c891e5c ] According to the chipidea driver bindings, the USB PHY is specified via the "phys" phandle node. However, this only takes effect for USB PHYs that use the common PHY framework. For legacy USB PHYs, a simple lookup based on the USB PHY type is done instead. This does not play out well when more than one USB PHY is registered, since the first registered PHY matching the type will always be returned regardless of what the driver was bound to. Fix this by looking up the PHY based on the "phys" phandle node. Although generic PHYs are rather matched by their "phys-name" and not the "phys" phandle directly, there is no helper for similar lookup on legacy PHYs and it's probably not worth the effort to add it. When no legacy USB PHY is found by phandle, fallback to grabbing any registered USB2 PHY. This ensures backward compatibility if some users were actually relying on this mechanism. Signed-off-by: Paul Kocialkowski Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b142c79733385c7fa502725c24d43b036b499220 Author: Eric Biggers Date: Sat Feb 23 00:23:23 2019 -0800 crypto: cavium/zip - fix collision with generic cra_driver_name [ Upstream commit 41798036430015ad45137db2d4c213cd77fd0251 ] The cavium/zip implementation of the deflate compression algorithm is incorrectly being registered under the generic driver name, which prevents the generic implementation from being registered with the crypto API when CONFIG_CRYPTO_DEV_CAVIUM_ZIP=y. Similarly the lzs algorithm (which does not currently have a generic implementation...) is incorrectly being registered as lzs-generic. Fix the naming collision by adding a suffix "-cavium" to the cra_driver_name of the cavium/zip algorithms. Fixes: 640035a2dc55 ("crypto: zip - Add ThunderX ZIP driver core") Cc: Mahipal Challa Cc: Jan Glauber Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d401d121113e9966804797137b69fb3f56ba33da Author: Julia Lawall Date: Sat Feb 23 14:20:39 2019 +0100 crypto: crypto4xx - add missing of_node_put after of_device_is_available [ Upstream commit 8c2b43d2d85b48a97d2f8279278a4aac5b45f925 ] 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: 5343e674f32fb ("crypto4xx: integrate ppc4xx-rng into crypto4xx") Signed-off-by: Julia Lawall Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 241ebd2ea44bf9c7d39da4926400ba001fa6442a Author: Wen Yang Date: Fri Feb 22 15:15:40 2019 +0800 mt76: fix a leaked reference by adding a missing of_node_put [ Upstream commit 34e022d8b780a03902d82fb3997ba7c7b1f40c81 ] The call to of_find_node_by_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/net/wireless/mediatek/mt76/eeprom.c:58:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function. ./drivers/net/wireless/mediatek/mt76/eeprom.c:61:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function. ./drivers/net/wireless/mediatek/mt76/eeprom.c:67:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function. ./drivers/net/wireless/mediatek/mt76/eeprom.c:70:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function. ./drivers/net/wireless/mediatek/mt76/eeprom.c:72:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: Felix Fietkau Cc: Lorenzo Bianconi Cc: Kalle Valo Cc: "David S. Miller" Cc: Matthias Brugger Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 6115055b4efeee072012e18c206242a7234bf456 Author: Alexei Avshalom Lazar Date: Fri Feb 22 16:21:05 2019 +0200 wil6210: check null pointer in _wil_cfg80211_merge_extra_ies [ Upstream commit de77a53c2d1e8fb3621e63e8e1f0f0c9a1a99ff7 ] ies1 or ies2 might be null when code inside _wil_cfg80211_merge_extra_ies access them. Add explicit check for null and make sure ies1/ies2 are not accessed in such a case. spos might be null and be accessed inside _wil_cfg80211_merge_extra_ies. Add explicit check for null in the while condition statement and make sure spos is not accessed in such a case. Signed-off-by: Alexei Avshalom Lazar Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 9546c3662dc5f8c3f9875c96f589dda2f38049a9 Author: Rafael J. Wysocki Date: Thu Feb 28 13:56:27 2019 -0600 PCI/PME: Fix hotplug/sysfs remove deadlock in pcie_pme_remove() [ Upstream commit 95c80bc6952b6a5badc7b702d23e5bf14d251e7c ] Dongdong reported a deadlock triggered by a hotplug event during a sysfs "remove" operation: pciehp 0000:00:0c.0:pcie004: Slot(0-1): Link Up # echo 1 > 0000:00:0c.0/remove PME and hotplug share an MSI/MSI-X vector. The sysfs "remove" side is: remove_store pci_stop_and_remove_bus_device_locked pci_lock_rescan_remove pci_stop_and_remove_bus_device ... pcie_pme_remove pcie_pme_suspend synchronize_irq # wait for hotplug IRQ handler pci_unlock_rescan_remove The hotplug side is: pciehp_ist pciehp_handle_presence_or_link_change pciehp_configure_device pci_lock_rescan_remove # wait for pci_unlock_rescan_remove() INFO: task bash:10913 blocked for more than 120 seconds. # ps -ax |grep D PID TTY STAT TIME COMMAND 10913 ttyAMA0 Ds+ 0:00 -bash 14022 ? D 0:00 [irq/745-pciehp] # cat /proc/14022/stack __switch_to+0x94/0xd8 pci_lock_rescan_remove+0x20/0x28 pciehp_configure_device+0x30/0x140 pciehp_handle_presence_or_link_change+0x324/0x458 pciehp_ist+0x1dc/0x1e0 # cat /proc/10913/stack __switch_to+0x94/0xd8 synchronize_irq+0x8c/0xc0 pcie_pme_suspend+0xa4/0x118 pcie_pme_remove+0x20/0x40 pcie_port_remove_service+0x3c/0x58 ... pcie_port_device_remove+0x2c/0x48 pcie_portdrv_remove+0x68/0x78 pci_device_remove+0x48/0x120 ... pci_stop_bus_device+0x84/0xc0 pci_stop_and_remove_bus_device_locked+0x24/0x40 remove_store+0xa4/0xb8 dev_attr_store+0x44/0x60 sysfs_kf_write+0x58/0x80 It is incorrect to call pcie_pme_suspend() from pcie_pme_remove() for two reasons. First, pcie_pme_suspend() calls synchronize_irq(), which will wait for the native hotplug interrupt handler as well as for the PME one, because they share one IRQ (as per the spec). That may deadlock if hotplug is signaled while pcie_pme_remove() is running and the latter calls pci_lock_rescan_remove() before the former. Second, if pcie_pme_suspend() figures out that wakeup needs to be enabled for the port, it will return without disabling the interrupt as expected by pcie_pme_remove() which was overlooked by commit c7b5a4e6e8fb ("PCI / PM: Fix native PME handling during system suspend/resume"). To fix that, rework pcie_pme_remove() to disable the PME interrupt, clear its status and prevent the PME worker function from re-enabling it before calling free_irq() on it, which should be sufficient. Fixes: c7b5a4e6e8fb ("PCI / PM: Fix native PME handling during system suspend/resume") Link: https://lore.kernel.org/linux-pci/c7697e7c-e1af-13e4-8491-0a3996e6ab5d@huawei.com Reported-by: Dongdong Liu Signed-off-by: Rafael J. Wysocki [bhelgaas: add URL and deadlock details from Dongdong] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 224c996e48be495d7d5423d996efed309d1fe321 Author: Tony Jones Date: Wed Feb 27 17:55:32 2019 -0800 tools lib traceevent: Fix buffer overflow in arg_eval [ Upstream commit 7c5b019e3a638a5a290b0ec020f6ca83d2ec2aaa ] Fix buffer overflow observed when running perf test. The overflow is when trying to evaluate "1ULL << (64 - 1)" which is resulting in -9223372036854775808 which overflows the 20 character buffer. If is possible this bug has been reported before but I still don't see any fix checked in: See: https://www.spinics.net/lists/linux-perf-users/msg07714.html Reported-by: Michael Sartain Reported-by: Mathias Krause Signed-off-by: Tony Jones Acked-by: Steven Rostedt (VMware) Cc: Frederic Weisbecker Fixes: f7d82350e597 ("tools/events: Add files to create libtraceevent.a") Link: http://lkml.kernel.org/r/20190228015532.8941-1-tonyj@suse.de Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 83c395332fdf0810264c3903dd56d76cde1e083c Author: Carlos Maiolino Date: Tue Feb 26 11:51:50 2019 +0100 fs: fix guard_bio_eod to check for real EOD errors [ Upstream commit dce30ca9e3b676fb288c33c1f4725a0621361185 ] guard_bio_eod() can truncate a segment in bio to allow it to do IO on odd last sectors of a device. It already checks if the IO starts past EOD, but it does not consider the possibility of an IO request starting within device boundaries can contain more than one segment past EOD. In such cases, truncated_bytes can be bigger than PAGE_SIZE, and will underflow bvec->bv_len. Fix this by checking if truncated_bytes is lower than PAGE_SIZE. This situation has been found on filesystems such as isofs and vfat, which doesn't check the device size before mount, if the device is smaller than the filesystem itself, a readahead on such filesystem, which spans EOD, can trigger this situation, leading a call to zero_user() with a wrong size possibly corrupting memory. I didn't see any crash, or didn't let the system run long enough to check if memory corruption will be hit somewhere, but adding instrumentation to guard_bio_end() to check truncated_bytes size, was enough to see the error. The following script can trigger the error. MNT=/mnt IMG=./DISK.img DEV=/dev/loop0 mkfs.vfat $IMG mount $IMG $MNT cp -R /etc $MNT &> /dev/null umount $MNT losetup -D losetup --find --show --sizelimit 16247280 $IMG mount $DEV $MNT find $MNT -type f -exec cat {} + >/dev/null Kudos to Eric Sandeen for coming up with the reproducer above Reviewed-by: Ming Lei Signed-off-by: Carlos Maiolino Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6a817a7aed1c4074274118d6a27f8b094e2fe0dd Author: luojiajun Date: Fri Mar 1 00:30:00 2019 -0500 jbd2: fix invalid descriptor block checksum [ Upstream commit 6e876c3dd205d30b0db6850e97a03d75457df007 ] In jbd2_journal_commit_transaction(), if we are in abort mode, we may flush the buffer without setting descriptor block checksum by goto start_journal_io. Then fs is mounted, jbd2_descriptor_block_csum_verify() failed. [ 271.379811] EXT4-fs (vdd): shut down requested (2) [ 271.381827] Aborting journal on device vdd-8. [ 271.597136] JBD2: Invalid checksum recovering block 22199 in log [ 271.598023] JBD2: recovery failed [ 271.598484] EXT4-fs (vdd): error loading journal Fix this problem by keep setting descriptor block checksum if the descriptor buffer is not NULL. This checksum problem can be reproduced by xfstests generic/388. Signed-off-by: luojiajun Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Signed-off-by: Sasha Levin commit ca66f667189c39b9128c1fba5d0be23d933009d9 Author: Florian Westphal Date: Thu Feb 21 17:09:31 2019 +0100 netfilter: conntrack: tcp: only close if RST matches exact sequence [ Upstream commit be0502a3f2e94211a8809a09ecbc3a017189b8fb ] TCP resets cause instant transition from established to closed state provided the reset is in-window. Endpoints that implement RFC 5961 require resets to match the next expected sequence number. RST segments that are in-window (but that do not match RCV.NXT) are ignored, and a "challenge ACK" is sent back. Main problem for conntrack is that its a middlebox, i.e. whereas an end host might have ACK'd SEQ (and would thus accept an RST with this sequence number), conntrack might not have seen this ACK (yet). Therefore we can't simply flag RSTs with non-exact match as invalid. This updates RST processing as follows: 1. If the connection is in a state other than ESTABLISHED, nothing is changed, RST is subject to normal in-window check. 2. If the RSTs sequence number either matches exactly RCV.NXT, connection state moves to CLOSE. 3. The same applies if the RST sequence number aligns with a previous packet in the same direction. In all other cases, the connection remains in ESTABLISHED state. If the normal-in-window check passes, the timeout will be lowered to that of CLOSE. If the peer sends a challenge ack, connection timeout will be reset. If the challenge ACK triggers another RST (RST was valid after all), this 2nd RST will match expected sequence and conntrack state changes to CLOSE. If no challenge ACK is received, the connection will time out after CLOSE seconds (10 seconds by default), just like without this patch. Packetdrill test case: 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 0.000 bind(3, ..., ...) = 0 0.000 listen(3, 1) = 0 0.100 < S 0:0(0) win 32792 0.100 > S. 0:0(0) ack 1 win 64240 0.200 < . 1:1(0) ack 1 win 257 0.200 accept(3, ..., ...) = 4 // Receive a segment. 0.210 < P. 1:1001(1000) ack 1 win 46 0.210 > . 1:1(0) ack 1001 // Application writes 1000 bytes. 0.250 write(4, ..., 1000) = 1000 0.250 > P. 1:1001(1000) ack 1001 // First reset, old sequence. Conntrack (correctly) considers this // invalid due to failed window validation (regardless of this patch). 0.260 < R 2:2(0) ack 1001 win 260 // 2nd reset, but too far ahead sequence. Same: correctly handled // as invalid. 0.270 < R 99990001:99990001(0) ack 1001 win 260 // in-window, but not exact sequence. // Current Linux kernels might reply with a challenge ack, and do not // remove connection. // Without this patch, conntrack state moves to CLOSE. // With patch, timeout is lowered like CLOSE, but connection stays // in ESTABLISHED state. 0.280 < R 1010:1010(0) ack 1001 win 260 // Expect challenge ACK 0.281 > . 1001:1001(0) ack 1001 win 501 // With or without this patch, RST will cause connection // to move to CLOSE (sequence number matches) // 0.282 < R 1001:1001(0) ack 1001 win 260 // ACK 0.300 < . 1001:1001(0) ack 1001 win 257 // more data could be exchanged here, connection // is still established // Client closes the connection. 0.610 < F. 1001:1001(0) ack 1001 win 260 0.650 > . 1001:1001(0) ack 1002 // Close the connection without reading outstanding data 0.700 close(4) = 0 // so one more reset. Will be deemed acceptable with patch as well: // connection is already closing. 0.701 > R. 1001:1001(0) ack 1002 win 501 // End packetdrill test case. With patch, this generates following conntrack events: [NEW] 120 SYN_SENT src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [UNREPLIED] [UPDATE] 60 SYN_RECV src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [UPDATE] 432000 ESTABLISHED src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [ASSURED] [UPDATE] 120 FIN_WAIT src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [ASSURED] [UPDATE] 60 CLOSE_WAIT src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [ASSURED] [UPDATE] 10 CLOSE src=10.0.2.1 dst=10.0.0.1 sport=5437 dport=80 [ASSURED] Without patch, first RST moves connection to close, whereas socket state does not change until FIN is received. [NEW] 120 SYN_SENT src=10.0.2.1 dst=10.0.0.1 sport=5141 dport=80 [UNREPLIED] [UPDATE] 60 SYN_RECV src=10.0.2.1 dst=10.0.0.1 sport=5141 dport=80 [UPDATE] 432000 ESTABLISHED src=10.0.2.1 dst=10.0.0.1 sport=5141 dport=80 [ASSURED] [UPDATE] 10 CLOSE src=10.0.2.1 dst=10.0.0.1 sport=5141 dport=80 [ASSURED] Cc: Jozsef Kadlecsik Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 709aaa09b200408e1a4b2cf41ce805c7ac9d17cf Author: Li RongQing Date: Tue Feb 26 17:13:56 2019 +0800 netfilter: nf_tables: check the result of dereferencing base_chain->stats [ Upstream commit a9f5e78c403d2d62ade4f4c85040efc85f4049b8 ] Check the result of dereferencing base_chain->stats, instead of result of this_cpu_ptr with NULL. base_chain->stats maybe be changed to NULL when a chain is updated and a new NULL counter can be attached. And we do not need to check returning of this_cpu_ptr since base_chain->stats is from percpu allocator if it is non-NULL, this_cpu_ptr returns a valid value. And fix two sparse error by replacing rcu_access_pointer and rcu_dereference with READ_ONCE under rcu_read_lock. Thanks for Eric's help to finish this patch. Fixes: 009240940e84c1 ("netfilter: nf_tables: don't assume chain stats are set when jumplabel is set") Signed-off-by: Eric Dumazet Signed-off-by: Zhang Yu Signed-off-by: Li RongQing Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 36a3219e617aa4650caf5dff858b98b95efc1d22 Author: Yao Liu Date: Mon Jan 28 19:47:28 2019 +0800 cifs: Fix NULL pointer dereference of devname [ Upstream commit 68e2672f8fbd1e04982b8d2798dd318bf2515dd2 ] There is a NULL pointer dereference of devname in strspn() The oops looks something like: CIFS: Attempting to mount (null) BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 ... RIP: 0010:strspn+0x0/0x50 ... Call Trace: ? cifs_parse_mount_options+0x222/0x1710 [cifs] ? cifs_get_volume_info+0x2f/0x80 [cifs] cifs_setup_volume_info+0x20/0x190 [cifs] cifs_get_volume_info+0x50/0x80 [cifs] cifs_smb3_do_mount+0x59/0x630 [cifs] ? ida_alloc_range+0x34b/0x3d0 cifs_do_mount+0x11/0x20 [cifs] mount_fs+0x52/0x170 vfs_kern_mount+0x6b/0x170 do_mount+0x216/0xdc0 ksys_mount+0x83/0xd0 __x64_sys_mount+0x25/0x30 do_syscall_64+0x65/0x220 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fix this by adding a NULL check on devname in cifs_parse_devname() Signed-off-by: Yao Liu Signed-off-by: Steve French Signed-off-by: Sasha Levin commit d579b4eae836e8f47e28ea373a579fdb9d4e04b5 Author: Namjae Jeon Date: Tue Jan 22 09:46:45 2019 +0900 cifs: Accept validate negotiate if server return NT_STATUS_NOT_SUPPORTED [ Upstream commit 969ae8e8d4ee54c99134d3895f2adf96047f5bee ] Old windows version or Netapp SMB server will return NT_STATUS_NOT_SUPPORTED since they do not allow or implement FSCTL_VALIDATE_NEGOTIATE_INFO. The client should accept the response provided it's properly signed. See https://blogs.msdn.microsoft.com/openspecification/2012/06/28/smb3-secure-dialect-negotiation/ and MS-SMB2 validate negotiate response processing: https://msdn.microsoft.com/en-us/library/hh880630.aspx Samba client had already handled it. https://bugzilla.samba.org/attachment.cgi?id=13285&action=edit Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 4ab78f4d75c644cbe707a6eb858c3737c25c842f Author: Chao Yu Date: Fri Feb 15 00:08:25 2019 +0800 f2fs: fix to check inline_xattr_size boundary correctly [ Upstream commit 500e0b28ecd3c5aade98f3c3a339d18dcb166bb6 ] We use below condition to check inline_xattr_size boundary: if (!F2FS_OPTION(sbi).inline_xattr_size || F2FS_OPTION(sbi).inline_xattr_size >= DEF_ADDRS_PER_INODE - F2FS_TOTAL_EXTRA_ATTR_SIZE - DEF_INLINE_RESERVED_SIZE - DEF_MIN_INLINE_SIZE) There is there problems in that check: - we should allow inline_xattr_size equaling to min size of inline {data,dentry} area. - F2FS_TOTAL_EXTRA_ATTR_SIZE and inline_xattr_size are based on different size unit, previous one is 4 bytes, latter one is 1 bytes. - DEF_MIN_INLINE_SIZE only indicate min size of inline data area, however, we need to consider min size of inline dentry area as well, minimal inline dentry should at least contain two entries: '.' and '..', so that min inline_dentry size is 40 bytes. .bitmap 1 * 1 = 1 .reserved 1 * 1 = 1 .dentry 11 * 2 = 22 .filename 8 * 2 = 16 total 40 Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 8c81fcd3d5c10c0e9518b17286e7f90c1221dd1a Author: Jason Cai (Xiang Feng) Date: Sun Jan 20 22:39:13 2019 +0800 dm thin: add sanity checks to thin-pool and external snapshot creation [ Upstream commit 70de2cbda8a5d788284469e755f8b097d339c240 ] Invoking dm_get_device() twice on the same device path with different modes is dangerous. Because in that case, upgrade_mode() will alloc a new 'dm_dev' and free the old one, which may be referenced by a previous caller. Dereferencing the dangling pointer will trigger kernel NULL pointer dereference. The following two cases can reproduce this issue. Actually, they are invalid setups that must be disallowed, e.g.: 1. Creating a thin-pool with read_only mode, and the same device as both metadata and data. dmsetup create thinp --table \ "0 41943040 thin-pool /dev/vdb /dev/vdb 128 0 1 read_only" BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 ... Call Trace: new_read+0xfb/0x110 [dm_bufio] dm_bm_read_lock+0x43/0x190 [dm_persistent_data] ? kmem_cache_alloc_trace+0x15c/0x1e0 __create_persistent_data_objects+0x65/0x3e0 [dm_thin_pool] dm_pool_metadata_open+0x8c/0xf0 [dm_thin_pool] pool_ctr.cold.79+0x213/0x913 [dm_thin_pool] ? realloc_argv+0x50/0x70 [dm_mod] dm_table_add_target+0x14e/0x330 [dm_mod] table_load+0x122/0x2e0 [dm_mod] ? dev_status+0x40/0x40 [dm_mod] ctl_ioctl+0x1aa/0x3e0 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] do_vfs_ioctl+0xa2/0x600 ? handle_mm_fault+0xda/0x200 ? __do_page_fault+0x26c/0x4f0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x150 entry_SYSCALL_64_after_hwframe+0x44/0xa9 2. Creating a external snapshot using the same thin-pool device. dmsetup create thinp --table \ "0 41943040 thin-pool /dev/vdc /dev/vdb 128 0 2 ignore_discard" dmsetup message /dev/mapper/thinp 0 "create_thin 0" dmsetup create snap --table \ "0 204800 thin /dev/mapper/thinp 0 /dev/mapper/thinp" BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 ... Call Trace: ? __alloc_pages_nodemask+0x13c/0x2e0 retrieve_status+0xa5/0x1f0 [dm_mod] ? dm_get_live_or_inactive_table.isra.7+0x20/0x20 [dm_mod] table_status+0x61/0xa0 [dm_mod] ctl_ioctl+0x1aa/0x3e0 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] do_vfs_ioctl+0xa2/0x600 ksys_ioctl+0x60/0x90 ? ksys_write+0x4f/0xb0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x150 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Jason Cai (Xiang Feng) Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 626d98bbdb30126719921f64dacaa3dc8ddc0c8a Author: Louis Taylor Date: Wed Feb 27 22:25:15 2019 +0000 cifs: use correct format characters [ Upstream commit 259594bea574e515a148171b5cd84ce5cbdc028a ] When compiling with -Wformat, clang emits the following warnings: fs/cifs/smb1ops.c:312:20: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat] tgt_total_cnt, total_in_tgt); ^~~~~~~~~~~~ fs/cifs/cifs_dfs_ref.c:289:4: warning: format specifies type 'short' but the argument has type 'int' [-Wformat] ref->flags, ref->server_type); ^~~~~~~~~~ fs/cifs/cifs_dfs_ref.c:289:16: warning: format specifies type 'short' but the argument has type 'int' [-Wformat] ref->flags, ref->server_type); ^~~~~~~~~~~~~~~~ fs/cifs/cifs_dfs_ref.c:291:4: warning: format specifies type 'short' but the argument has type 'int' [-Wformat] ref->ref_flag, ref->path_consumed); ^~~~~~~~~~~~~ fs/cifs/cifs_dfs_ref.c:291:19: warning: format specifies type 'short' but the argument has type 'int' [-Wformat] ref->ref_flag, ref->path_consumed); ^~~~~~~~~~~~~~~~~~ The types of these arguments are unconditionally defined, so this patch updates the format character to the correct ones for ints and unsigned ints. Link: https://github.com/ClangBuiltLinux/linux/issues/378 Signed-off-by: Louis Taylor Signed-off-by: Steve French Reviewed-by: Nick Desaulniers Signed-off-by: Sasha Levin commit a6c56bf63e875458dde73afde909184e34c99080 Author: Qian Cai Date: Tue Mar 5 15:41:24 2019 -0800 page_poison: play nicely with KASAN [ Upstream commit 4117992df66a26fa33908b4969e04801534baab1 ] KASAN does not play well with the page poisoning (CONFIG_PAGE_POISONING). It triggers false positives in the allocation path: BUG: KASAN: use-after-free in memchr_inv+0x2ea/0x330 Read of size 8 at addr ffff88881f800000 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1+ #54 Call Trace: dump_stack+0xe0/0x19a print_address_description.cold.2+0x9/0x28b kasan_report.cold.3+0x7a/0xb5 __asan_report_load8_noabort+0x19/0x20 memchr_inv+0x2ea/0x330 kernel_poison_pages+0x103/0x3d5 get_page_from_freelist+0x15e7/0x4d90 because KASAN has not yet unpoisoned the shadow page for allocation before it checks memchr_inv() but only found a stale poison pattern. Also, false positives in free path, BUG: KASAN: slab-out-of-bounds in kernel_poison_pages+0x29e/0x3d5 Write of size 4096 at addr ffff8888112cc000 by task swapper/0/1 CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc1+ #55 Call Trace: dump_stack+0xe0/0x19a print_address_description.cold.2+0x9/0x28b kasan_report.cold.3+0x7a/0xb5 check_memory_region+0x22d/0x250 memset+0x28/0x40 kernel_poison_pages+0x29e/0x3d5 __free_pages_ok+0x75f/0x13e0 due to KASAN adds poisoned redzones around slab objects, but the page poisoning needs to poison the whole page. Link: http://lkml.kernel.org/r/20190114233405.67843-1-cai@lca.pw Signed-off-by: Qian Cai Acked-by: Andrey Ryabinin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d609ecd887f8dd8288b9ff58042381a0ce801ec0 Author: Shuriyc Chu Date: Tue Mar 5 15:41:56 2019 -0800 fs/file.c: initialize init_files.resize_wait [ Upstream commit 5704a06810682683355624923547b41540e2801a ] (Taken from https://bugzilla.kernel.org/show_bug.cgi?id=200647) 'get_unused_fd_flags' in kthread cause kernel crash. It works fine on 4.1, but causes crash after get 64 fds. It also cause crash on ubuntu1404/1604/1804, centos7.5, and the crash messages are almost the same. The crash message on centos7.5 shows below: start fd 61 start fd 62 start fd 63 BUG: unable to handle kernel NULL pointer dereference at (null) IP: __wake_up_common+0x2e/0x90 PGD 0 Oops: 0000 [#1] SMP Modules linked in: test(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter devlink sunrpc kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd sg ppdev pcspkr virtio_balloon parport_pc parport i2c_piix4 joydev ip_tables xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi virtio_scsi virtio_console virtio_net cirrus drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crct10dif_pclmul crct10dif_common crc32c_intel drm ata_piix serio_raw libata virtio_pci virtio_ring i2c_core virtio floppy dm_mirror dm_region_hash dm_log dm_mod CPU: 2 PID: 1820 Comm: test_fd Kdump: loaded Tainted: G OE ------------ 3.10.0-862.3.3.el7.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 task: ffff8e92b9431fa0 ti: ffff8e94247a0000 task.ti: ffff8e94247a0000 RIP: 0010:__wake_up_common+0x2e/0x90 RSP: 0018:ffff8e94247a2d18 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffffffff9d09daa0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffff9d09daa0 RBP: ffff8e94247a2d50 R08: 0000000000000000 R09: ffff8e92b95dfda8 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9d09daa8 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8e9434e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000017c686000 CR4: 00000000000207e0 Call Trace: __wake_up+0x39/0x50 expand_files+0x131/0x250 __alloc_fd+0x47/0x170 get_unused_fd_flags+0x30/0x40 test_fd+0x12a/0x1c0 [test] kthread+0xd1/0xe0 ret_from_fork_nospec_begin+0x21/0x21 Code: 66 90 55 48 89 e5 41 57 41 89 f7 41 56 41 89 ce 41 55 41 54 49 89 fc 49 83 c4 08 53 48 83 ec 10 48 8b 47 08 89 55 cc 4c 89 45 d0 <48> 8b 08 49 39 c4 48 8d 78 e8 4c 8d 69 e8 75 08 eb 3b 4c 89 ef RIP __wake_up_common+0x2e/0x90 RSP CR2: 0000000000000000 This issue exists since CentOS 7.5 3.10.0-862 and CentOS 7.4 (3.10.0-693.21.1 ) is ok. Root cause: the item 'resize_wait' is not initialized before being used. Reported-by: Richard Zhang Reviewed-by: Andrew Morton Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9b4f27667402c303de02192a2ce84f4c1823be69 Author: Sahitya Tummala Date: Mon Feb 4 13:36:53 2019 +0530 f2fs: do not use mutex lock in atomic context [ Upstream commit 9083977dabf3833298ddcd40dee28687f1e6b483 ] Fix below warning coming because of using mutex lock in atomic context. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:98 in_atomic(): 1, irqs_disabled(): 0, pid: 585, name: sh Preemption disabled at: __radix_tree_preload+0x28/0x130 Call trace: dump_backtrace+0x0/0x2b4 show_stack+0x20/0x28 dump_stack+0xa8/0xe0 ___might_sleep+0x144/0x194 __might_sleep+0x58/0x8c mutex_lock+0x2c/0x48 f2fs_trace_pid+0x88/0x14c f2fs_set_node_page_dirty+0xd0/0x184 Do not use f2fs_radix_tree_insert() to avoid doing cond_resched() with spin_lock() acquired. Signed-off-by: Sahitya Tummala Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 20141feb9bdec6e7daed7782c1535b31081aeb71 Author: Jia Guo Date: Tue Mar 5 15:41:41 2019 -0800 ocfs2: fix a panic problem caused by o2cb_ctl [ Upstream commit cc725ef3cb202ef2019a3c67c8913efa05c3cce6 ] In the process of creating a node, it will cause NULL pointer dereference in kernel if o2cb_ctl failed in the interval (mkdir, o2cb_set_node_attribute(node_num)] in function o2cb_add_node. The node num is initialized to 0 in function o2nm_node_group_make_item, o2nm_node_group_drop_item will mistake the node number 0 for a valid node number when we delete the node before the node number is set correctly. If the local node number of the current host happens to be 0, cluster->cl_local_node will be set to O2NM_INVALID_NODE_NUM while o2hb_thread still running. The panic stack is generated as follows: o2hb_thread \-o2hb_do_disk_heartbeat \-o2hb_check_own_slot |-slot = ®->hr_slots[o2nm_this_node()]; //o2nm_this_node() return O2NM_INVALID_NODE_NUM We need to check whether the node number is set when we delete the node. Link: http://lkml.kernel.org/r/133d8045-72cc-863e-8eae-5013f9f6bc51@huawei.com Signed-off-by: Jia Guo Reviewed-by: Joseph Qi Acked-by: Jun Piao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f09c424cea9f05990561bb318c1143c833de91cc Author: Qian Cai Date: Tue Mar 5 15:42:03 2019 -0800 mm/slab.c: kmemleak no scan alien caches [ Upstream commit 92d1d07daad65c300c7d0b68bbef8867e9895d54 ] Kmemleak throws endless warnings during boot due to in __alloc_alien_cache(), alc = kmalloc_node(memsize, gfp, node); init_arraycache(&alc->ac, entries, batch); kmemleak_no_scan(ac); Kmemleak does not track the array cache (alc->ac) but the alien cache (alc) instead, so let it track the latter by lifting kmemleak_no_scan() out of init_arraycache(). There is another place that calls init_arraycache(), but alloc_kmem_cache_cpus() uses the percpu allocation where will never be considered as a leak. kmemleak: Found object by alias at 0xffff8007b9aa7e38 CPU: 190 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2+ #2 Call trace: dump_backtrace+0x0/0x168 show_stack+0x24/0x30 dump_stack+0x88/0xb0 lookup_object+0x84/0xac find_and_get_object+0x84/0xe4 kmemleak_no_scan+0x74/0xf4 setup_kmem_cache_node+0x2b4/0x35c __do_tune_cpucache+0x250/0x2d4 do_tune_cpucache+0x4c/0xe4 enable_cpucache+0xc8/0x110 setup_cpu_cache+0x40/0x1b8 __kmem_cache_create+0x240/0x358 create_cache+0xc0/0x198 kmem_cache_create_usercopy+0x158/0x20c kmem_cache_create+0x50/0x64 fsnotify_init+0x58/0x6c do_one_initcall+0x194/0x388 kernel_init_freeable+0x668/0x688 kernel_init+0x18/0x124 ret_from_fork+0x10/0x18 kmemleak: Object 0xffff8007b9aa7e00 (size 256): kmemleak: comm "swapper/0", pid 1, jiffies 4294697137 kmemleak: min_count = 1 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace: kmemleak_alloc+0x84/0xb8 kmem_cache_alloc_node_trace+0x31c/0x3a0 __kmalloc_node+0x58/0x78 setup_kmem_cache_node+0x26c/0x35c __do_tune_cpucache+0x250/0x2d4 do_tune_cpucache+0x4c/0xe4 enable_cpucache+0xc8/0x110 setup_cpu_cache+0x40/0x1b8 __kmem_cache_create+0x240/0x358 create_cache+0xc0/0x198 kmem_cache_create_usercopy+0x158/0x20c kmem_cache_create+0x50/0x64 fsnotify_init+0x58/0x6c do_one_initcall+0x194/0x388 kernel_init_freeable+0x668/0x688 kernel_init+0x18/0x124 kmemleak: Not scanning unknown object at 0xffff8007b9aa7e38 CPU: 190 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2+ #2 Call trace: dump_backtrace+0x0/0x168 show_stack+0x24/0x30 dump_stack+0x88/0xb0 kmemleak_no_scan+0x90/0xf4 setup_kmem_cache_node+0x2b4/0x35c __do_tune_cpucache+0x250/0x2d4 do_tune_cpucache+0x4c/0xe4 enable_cpucache+0xc8/0x110 setup_cpu_cache+0x40/0x1b8 __kmem_cache_create+0x240/0x358 create_cache+0xc0/0x198 kmem_cache_create_usercopy+0x158/0x20c kmem_cache_create+0x50/0x64 fsnotify_init+0x58/0x6c do_one_initcall+0x194/0x388 kernel_init_freeable+0x668/0x688 kernel_init+0x18/0x124 ret_from_fork+0x10/0x18 Link: http://lkml.kernel.org/r/20190129184518.39808-1-cai@lca.pw Fixes: 1fe00d50a9e8 ("slab: factor out initialization of array cache") Signed-off-by: Qian Cai Reviewed-by: Andrew Morton Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Catalin Marinas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8a0fc62e331e15b1fef1b29ed5909da03f4a8cf5 Author: Uladzislau Rezki (Sony) Date: Tue Mar 5 15:45:59 2019 -0800 mm/vmalloc.c: fix kernel BUG at mm/vmalloc.c:512! [ Upstream commit afd07389d3f4933c7f7817a92fb5e053d59a3182 ] One of the vmalloc stress test case triggers the kernel BUG(): [60.562151] ------------[ cut here ]------------ [60.562154] kernel BUG at mm/vmalloc.c:512! [60.562206] invalid opcode: 0000 [#1] PREEMPT SMP PTI [60.562247] CPU: 0 PID: 430 Comm: vmalloc_test/0 Not tainted 4.20.0+ #161 [60.562293] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [60.562351] RIP: 0010:alloc_vmap_area+0x36f/0x390 it can happen due to big align request resulting in overflowing of calculated address, i.e. it becomes 0 after ALIGN()'s fixup. Fix it by checking if calculated address is within vstart/vend range. Link: http://lkml.kernel.org/r/20190124115648.9433-2-urezki@gmail.com Signed-off-by: Uladzislau Rezki (Sony) Reviewed-by: Andrew Morton Cc: Ingo Molnar Cc: Joel Fernandes Cc: Matthew Wilcox Cc: Michal Hocko Cc: Oleksiy Avramchenko Cc: Steven Rostedt Cc: Tejun Heo Cc: Thomas Garnier Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 67abbb9c5422470d8a14394c55c9174756159751 Author: Vlastimil Babka Date: Tue Mar 5 15:46:50 2019 -0800 mm, mempolicy: fix uninit memory access [ Upstream commit 2e25644e8da4ed3a27e7b8315aaae74660be72dc ] Syzbot with KMSAN reports (excerpt): ================================================================== BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 CPU: 1 PID: 17420 Comm: syz-executor4 Not tainted 4.20.0-rc7+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x173/0x1d0 lib/dump_stack.c:113 kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613 __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:295 mpol_rebind_policy mm/mempolicy.c:353 [inline] mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 update_tasks_nodemask+0x608/0xca0 kernel/cgroup/cpuset.c:1120 update_nodemasks_hier kernel/cgroup/cpuset.c:1185 [inline] update_nodemask kernel/cgroup/cpuset.c:1253 [inline] cpuset_write_resmask+0x2a98/0x34b0 kernel/cgroup/cpuset.c:1728 ... Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline] kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158 kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176 kmem_cache_alloc+0x572/0xb90 mm/slub.c:2777 mpol_new mm/mempolicy.c:276 [inline] do_mbind mm/mempolicy.c:1180 [inline] kernel_mbind+0x8a7/0x31a0 mm/mempolicy.c:1347 __do_sys_mbind mm/mempolicy.c:1354 [inline] As it's difficult to report where exactly the uninit value resides in the mempolicy object, we have to guess a bit. mm/mempolicy.c:353 contains this part of mpol_rebind_policy(): if (!mpol_store_user_nodemask(pol) && nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) "mpol_store_user_nodemask(pol)" is testing pol->flags, which I couldn't ever see being uninitialized after leaving mpol_new(). So I'll guess it's actually about accessing pol->w.cpuset_mems_allowed on line 354, but still part of statement starting on line 353. For w.cpuset_mems_allowed to be not initialized, and the nodes_equal() reachable for a mempolicy where mpol_set_nodemask() is called in do_mbind(), it seems the only possibility is a MPOL_PREFERRED policy with empty set of nodes, i.e. MPOL_LOCAL equivalent, with MPOL_F_LOCAL flag. Let's exclude such policies from the nodes_equal() check. Note the uninit access should be benign anyway, as rebinding this kind of policy is always a no-op. Therefore no actual need for stable inclusion. Link: http://lkml.kernel.org/r/a71997c3-e8ae-a787-d5ce-3db05768b27c@suse.cz Link: http://lkml.kernel.org/r/73da3e9c-cc84-509e-17d9-0c434bb9967d@suse.cz Signed-off-by: Vlastimil Babka Reported-by: syzbot+b19c2dc2c990ea657a71@syzkaller.appspotmail.com Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Andrea Arcangeli Cc: "Kirill A. Shutemov" Cc: Michal Hocko Cc: David Rientjes Cc: Yisheng Xie Cc: zhong jiang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9d785b92cf0dcfe5bd20f928a3fef2577c10f1f4 Author: Tetsuo Handa Date: Tue Mar 5 15:46:47 2019 -0800 memcg: killed threads should not invoke memcg OOM killer [ Upstream commit 7775face207922ea62a4e96b9cd45abfdc7b9840 ] If a memory cgroup contains a single process with many threads (including different process group sharing the mm) then it is possible to trigger a race when the oom killer complains that there are no oom elible tasks and complain into the log which is both annoying and confusing because there is no actual problem. The race looks as follows: P1 oom_reaper P2 try_charge try_charge mem_cgroup_out_of_memory mutex_lock(oom_lock) out_of_memory oom_kill_process(P1,P2) wake_oom_reaper mutex_unlock(oom_lock) oom_reap_task mutex_lock(oom_lock) select_bad_process # no victim The problem is more visible with many threads. Fix this by checking for fatal_signal_pending from mem_cgroup_out_of_memory when the oom_lock is already held. The oom bypass is safe because we do the same early in the try_charge path already. The situation migh have changed in the mean time. It should be safe to check for fatal_signal_pending and tsk_is_oom_victim but for a better code readability abstract the current charge bypass condition into should_force_charge and reuse it from that path. " Link: http://lkml.kernel.org/r/01370f70-e1f6-ebe4-b95e-0df21a0bc15e@i-love.sakura.ne.jp Signed-off-by: Tetsuo Handa Acked-by: Michal Hocko Acked-by: Johannes Weiner Cc: David Rientjes Cc: Kirill Tkhai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit eed3ca0a66cfc55cc5a223ad73c029d768e01806 Author: Tetsuo Handa Date: Tue Mar 5 15:48:22 2019 -0800 mm,oom: don't kill global init via memory.oom.group [ Upstream commit d342a0b38674867ea67fde47b0e1e60ffe9f17a2 ] Since setting global init process to some memory cgroup is technically possible, oom_kill_memcg_member() must check it. Tasks in /test1 are going to be killed due to memory.oom.group set Memory cgroup out of memory: Killed process 1 (systemd) total-vm:43400kB, anon-rss:1228kB, file-rss:3992kB, shmem-rss:0kB oom_reaper: reaped process 1 (systemd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000008b #include #include #include #include #include #include int main(int argc, char *argv[]) { static char buffer[10485760]; static int pipe_fd[2] = { EOF, EOF }; unsigned int i; int fd; char buf[64] = { }; if (pipe(pipe_fd)) return 1; if (chdir("/sys/fs/cgroup/")) return 1; fd = open("cgroup.subtree_control", O_WRONLY); write(fd, "+memory", 7); close(fd); mkdir("test1", 0755); fd = open("test1/memory.oom.group", O_WRONLY); write(fd, "1", 1); close(fd); fd = open("test1/cgroup.procs", O_WRONLY); write(fd, "1", 1); snprintf(buf, sizeof(buf) - 1, "%d", getpid()); write(fd, buf, strlen(buf)); close(fd); snprintf(buf, sizeof(buf) - 1, "%lu", sizeof(buffer) * 5); fd = open("test1/memory.max", O_WRONLY); write(fd, buf, strlen(buf)); close(fd); for (i = 0; i < 10; i++) if (fork() == 0) { char c; close(pipe_fd[1]); read(pipe_fd[0], &c, 1); memset(buffer, 0, sizeof(buffer)); sleep(3); _exit(0); } close(pipe_fd[0]); close(pipe_fd[1]); sleep(3); return 0; } [ 37.052923][ T9185] a.out invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0 [ 37.056169][ T9185] CPU: 4 PID: 9185 Comm: a.out Kdump: loaded Not tainted 5.0.0-rc4-next-20190131 #280 [ 37.059205][ T9185] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018 [ 37.062954][ T9185] Call Trace: [ 37.063976][ T9185] dump_stack+0x67/0x95 [ 37.065263][ T9185] dump_header+0x51/0x570 [ 37.066619][ T9185] ? trace_hardirqs_on+0x3f/0x110 [ 37.068171][ T9185] ? _raw_spin_unlock_irqrestore+0x3d/0x70 [ 37.069967][ T9185] oom_kill_process+0x18d/0x210 [ 37.071515][ T9185] out_of_memory+0x11b/0x380 [ 37.072936][ T9185] mem_cgroup_out_of_memory+0xb6/0xd0 [ 37.074601][ T9185] try_charge+0x790/0x820 [ 37.076021][ T9185] mem_cgroup_try_charge+0x42/0x1d0 [ 37.077629][ T9185] mem_cgroup_try_charge_delay+0x11/0x30 [ 37.079370][ T9185] do_anonymous_page+0x105/0x5e0 [ 37.080939][ T9185] __handle_mm_fault+0x9cb/0x1070 [ 37.082485][ T9185] handle_mm_fault+0x1b2/0x3a0 [ 37.083819][ T9185] ? handle_mm_fault+0x47/0x3a0 [ 37.085181][ T9185] __do_page_fault+0x255/0x4c0 [ 37.086529][ T9185] do_page_fault+0x28/0x260 [ 37.087788][ T9185] ? page_fault+0x8/0x30 [ 37.088978][ T9185] page_fault+0x1e/0x30 [ 37.090142][ T9185] RIP: 0033:0x7f8b183aefe0 [ 37.091433][ T9185] Code: 20 f3 44 0f 7f 44 17 d0 f3 44 0f 7f 47 30 f3 44 0f 7f 44 17 c0 48 01 fa 48 83 e2 c0 48 39 d1 74 a3 66 0f 1f 84 00 00 00 00 00 <66> 44 0f 7f 01 66 44 0f 7f 41 10 66 44 0f 7f 41 20 66 44 0f 7f 41 [ 37.096917][ T9185] RSP: 002b:00007fffc5d329e8 EFLAGS: 00010206 [ 37.098615][ T9185] RAX: 00000000006010e0 RBX: 0000000000000008 RCX: 0000000000c30000 [ 37.100905][ T9185] RDX: 00000000010010c0 RSI: 0000000000000000 RDI: 00000000006010e0 [ 37.103349][ T9185] RBP: 0000000000000000 R08: 00007f8b188f4740 R09: 0000000000000000 [ 37.105797][ T9185] R10: 00007fffc5d32420 R11: 00007f8b183aef40 R12: 0000000000000005 [ 37.108228][ T9185] R13: 0000000000000000 R14: ffffffffffffffff R15: 0000000000000000 [ 37.110840][ T9185] memory: usage 51200kB, limit 51200kB, failcnt 125 [ 37.113045][ T9185] memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0 [ 37.115808][ T9185] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0 [ 37.117660][ T9185] Memory cgroup stats for /test1: cache:0KB rss:49484KB rss_huge:30720KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:49700KB inactive_file:0KB active_file:0KB unevictable:0KB [ 37.123371][ T9185] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,oom_memcg=/test1,task_memcg=/test1,task=a.out,pid=9188,uid=0 [ 37.128158][ T9185] Memory cgroup out of memory: Killed process 9188 (a.out) total-vm:14456kB, anon-rss:10324kB, file-rss:504kB, shmem-rss:0kB [ 37.132710][ T9185] Tasks in /test1 are going to be killed due to memory.oom.group set [ 37.132833][ T54] oom_reaper: reaped process 9188 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB [ 37.135498][ T9185] Memory cgroup out of memory: Killed process 1 (systemd) total-vm:43400kB, anon-rss:1228kB, file-rss:3992kB, shmem-rss:0kB [ 37.143434][ T9185] Memory cgroup out of memory: Killed process 9182 (a.out) total-vm:14456kB, anon-rss:76kB, file-rss:588kB, shmem-rss:0kB [ 37.144328][ T54] oom_reaper: reaped process 1 (systemd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB [ 37.147585][ T9185] Memory cgroup out of memory: Killed process 9183 (a.out) total-vm:14456kB, anon-rss:6228kB, file-rss:512kB, shmem-rss:0kB [ 37.157222][ T9185] Memory cgroup out of memory: Killed process 9184 (a.out) total-vm:14456kB, anon-rss:6228kB, file-rss:508kB, shmem-rss:0kB [ 37.157259][ T9185] Memory cgroup out of memory: Killed process 9185 (a.out) total-vm:14456kB, anon-rss:6228kB, file-rss:512kB, shmem-rss:0kB [ 37.157291][ T9185] Memory cgroup out of memory: Killed process 9186 (a.out) total-vm:14456kB, anon-rss:4180kB, file-rss:508kB, shmem-rss:0kB [ 37.157306][ T54] oom_reaper: reaped process 9183 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB [ 37.157328][ T9185] Memory cgroup out of memory: Killed process 9187 (a.out) total-vm:14456kB, anon-rss:4180kB, file-rss:512kB, shmem-rss:0kB [ 37.157452][ T9185] Memory cgroup out of memory: Killed process 9189 (a.out) total-vm:14456kB, anon-rss:6228kB, file-rss:512kB, shmem-rss:0kB [ 37.158733][ T9185] Memory cgroup out of memory: Killed process 9190 (a.out) total-vm:14456kB, anon-rss:552kB, file-rss:512kB, shmem-rss:0kB [ 37.160083][ T54] oom_reaper: reaped process 9186 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB [ 37.160187][ T54] oom_reaper: reaped process 9189 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB [ 37.206941][ T54] oom_reaper: reaped process 9185 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB [ 37.212300][ T9185] Memory cgroup out of memory: Killed process 9191 (a.out) total-vm:14456kB, anon-rss:4180kB, file-rss:512kB, shmem-rss:0kB [ 37.212317][ T54] oom_reaper: reaped process 9190 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB [ 37.218860][ T9185] Memory cgroup out of memory: Killed process 9192 (a.out) total-vm:14456kB, anon-rss:1080kB, file-rss:512kB, shmem-rss:0kB [ 37.227667][ T54] oom_reaper: reaped process 9192 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB [ 37.292323][ T9193] abrt-hook-ccpp (9193) used greatest stack depth: 10480 bytes left [ 37.351843][ T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000008b [ 37.354833][ T1] CPU: 7 PID: 1 Comm: systemd Kdump: loaded Not tainted 5.0.0-rc4-next-20190131 #280 [ 37.357876][ T1] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018 [ 37.361685][ T1] Call Trace: [ 37.363239][ T1] dump_stack+0x67/0x95 [ 37.365010][ T1] panic+0xfc/0x2b0 [ 37.366853][ T1] do_exit+0xd55/0xd60 [ 37.368595][ T1] do_group_exit+0x47/0xc0 [ 37.370415][ T1] get_signal+0x32a/0x920 [ 37.372449][ T1] ? _raw_spin_unlock_irqrestore+0x3d/0x70 [ 37.374596][ T1] do_signal+0x32/0x6e0 [ 37.376430][ T1] ? exit_to_usermode_loop+0x26/0x9b [ 37.378418][ T1] ? prepare_exit_to_usermode+0xa8/0xd0 [ 37.380571][ T1] exit_to_usermode_loop+0x3e/0x9b [ 37.382588][ T1] prepare_exit_to_usermode+0xa8/0xd0 [ 37.384594][ T1] ? page_fault+0x8/0x30 [ 37.386453][ T1] retint_user+0x8/0x18 [ 37.388160][ T1] RIP: 0033:0x7f42c06974a8 [ 37.389922][ T1] Code: Bad RIP value. [ 37.391788][ T1] RSP: 002b:00007ffc3effd388 EFLAGS: 00010213 [ 37.394075][ T1] RAX: 000000000000000e RBX: 00007ffc3effd390 RCX: 0000000000000000 [ 37.396963][ T1] RDX: 000000000000002a RSI: 00007ffc3effd390 RDI: 0000000000000004 [ 37.399550][ T1] RBP: 00007ffc3effd680 R08: 0000000000000000 R09: 0000000000000000 [ 37.402334][ T1] R10: 00000000ffffffff R11: 0000000000000246 R12: 0000000000000001 [ 37.404890][ T1] R13: ffffffffffffffff R14: 0000000000000884 R15: 000056460b1ac3b0 Link: http://lkml.kernel.org/r/201902010336.x113a4EO027170@www262.sakura.ne.jp Fixes: 3d8b38eb81cac813 ("mm, oom: introduce memory.oom.group") Signed-off-by: Tetsuo Handa Acked-by: Michal Hocko Cc: Roman Gushchin Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ed3345a6607b68857b5b1fa082e57c042b08561f Author: Daniel Jordan Date: Tue Mar 5 15:48:19 2019 -0800 mm, swap: bounds check swap_info array accesses to avoid NULL derefs [ Upstream commit c10d38cc8d3e43f946b6c2bf4602c86791587f30 ] Dan Carpenter reports a potential NULL dereference in get_swap_page_of_type: Smatch complains that the NULL checks on "si" aren't consistent. This seems like a real bug because we have not ensured that the type is valid and so "si" can be NULL. Add the missing check for NULL, taking care to use a read barrier to ensure CPU1 observes CPU0's updates in the correct order: CPU0 CPU1 alloc_swap_info() if (type >= nr_swapfiles) swap_info[type] = p /* handle invalid entry */ smp_wmb() smp_rmb() ++nr_swapfiles p = swap_info[type] Without smp_rmb, CPU1 might observe CPU0's write to nr_swapfiles before CPU0's write to swap_info[type] and read NULL from swap_info[type]. Ying Huang noticed other places in swapfile.c don't order these reads properly. Introduce swap_type_to_swap_info to encourage correct usage. Use READ_ONCE and WRITE_ONCE to follow the Linux Kernel Memory Model (see tools/memory-model/Documentation/explanation.txt). This ordering need not be enforced in places where swap_lock is held (e.g. si_swapinfo) because swap_lock serializes updates to nr_swapfiles and the swap_info array. Link: http://lkml.kernel.org/r/20190131024410.29859-1-daniel.m.jordan@oracle.com Fixes: ec8acf20afb8 ("swap: add per-partition lock for swapfile") Signed-off-by: Daniel Jordan Reported-by: Dan Carpenter Suggested-by: "Huang, Ying" Reviewed-by: Andrea Parri Acked-by: Peter Zijlstra (Intel) Cc: Alan Stern Cc: Andi Kleen Cc: Dave Hansen Cc: Omar Sandoval Cc: Paul McKenney Cc: Shaohua Li Cc: Stephen Rothwell Cc: Tejun Heo Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4c6d7dc741cb54cf35fa9775d88785fc79a1ea1e Author: Qian Cai Date: Tue Mar 5 15:49:46 2019 -0800 mm/page_ext.c: fix an imbalance with kmemleak [ Upstream commit 0c81585499601acd1d0e1cbf424cabfaee60628c ] After offlining a memory block, kmemleak scan will trigger a crash, as it encounters a page ext address that has already been freed during memory offlining. At the beginning in alloc_page_ext(), it calls kmemleak_alloc(), but it does not call kmemleak_free() in free_page_ext(). BUG: unable to handle kernel paging request at ffff888453d00000 PGD 128a01067 P4D 128a01067 PUD 128a04067 PMD 47e09e067 PTE 800ffffbac2ff060 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI CPU: 1 PID: 1594 Comm: bash Not tainted 5.0.0-rc8+ #15 Hardware name: HP ProLiant DL180 Gen9/ProLiant DL180 Gen9, BIOS U20 10/25/2017 RIP: 0010:scan_block+0xb5/0x290 Code: 85 6e 01 00 00 48 b8 00 00 30 f5 81 88 ff ff 48 39 c3 0f 84 5b 01 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 0f 85 87 01 00 00 <4c> 8b 3b e8 f3 0c fa ff 4c 39 3d 0c 6b 4c 01 0f 87 08 01 00 00 4c RSP: 0018:ffff8881ec57f8e0 EFLAGS: 00010082 RAX: 0000000000000000 RBX: ffff888453d00000 RCX: ffffffffa61e5a54 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff888453d00000 RBP: ffff8881ec57f920 R08: fffffbfff4ed588d R09: fffffbfff4ed588c R10: fffffbfff4ed588c R11: ffffffffa76ac463 R12: dffffc0000000000 R13: ffff888453d00ff9 R14: ffff8881f80cef48 R15: ffff8881f80cef48 FS: 00007f6c0e3f8740(0000) GS:ffff8881f7680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888453d00000 CR3: 00000001c4244003 CR4: 00000000001606a0 Call Trace: scan_gray_list+0x269/0x430 kmemleak_scan+0x5a8/0x10f0 kmemleak_write+0x541/0x6ca full_proxy_write+0xf8/0x190 __vfs_write+0xeb/0x980 vfs_write+0x15a/0x4f0 ksys_write+0xd2/0x1b0 __x64_sys_write+0x73/0xb0 do_syscall_64+0xeb/0xaaa entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f6c0dad73b8 Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 63 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 RSP: 002b:00007ffd5b863cb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f6c0dad73b8 RDX: 0000000000000005 RSI: 000055a9216e1710 RDI: 0000000000000001 RBP: 000055a9216e1710 R08: 000000000000000a R09: 00007ffd5b863840 R10: 000000000000000a R11: 0000000000000246 R12: 00007f6c0dda9780 R13: 0000000000000005 R14: 00007f6c0dda4740 R15: 0000000000000005 Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm irqbypass efivars ip_tables x_tables xfs sd_mod ahci libahci igb i2c_algo_bit libata i2c_core dm_mirror dm_region_hash dm_log dm_mod efivarfs CR2: ffff888453d00000 ---[ end trace ccf646c7456717c5 ]--- Kernel panic - not syncing: Fatal exception Shutting down cpus with NMI Kernel Offset: 0x24c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- Link: http://lkml.kernel.org/r/20190227173147.75650-1-cai@lca.pw Signed-off-by: Qian Cai Reviewed-by: Catalin Marinas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f555b008c576819c27959a45dc418318fcc20a95 Author: Peng Fan Date: Tue Mar 5 15:49:50 2019 -0800 mm/cma.c: cma_declare_contiguous: correct err handling [ Upstream commit 0d3bd18a5efd66097ef58622b898d3139790aa9d ] In case cma_init_reserved_mem failed, need to free the memblock allocated by memblock_reserve or memblock_alloc_range. Quote Catalin's comments: https://lkml.org/lkml/2019/2/26/482 Kmemleak is supposed to work with the memblock_{alloc,free} pair and it ignores the memblock_reserve() as a memblock_alloc() implementation detail. It is, however, tolerant to memblock_free() being called on a sub-range or just a different range from a previous memblock_alloc(). So the original patch looks fine to me. FWIW: Link: http://lkml.kernel.org/r/20190227144631.16708-1-peng.fan@nxp.com Signed-off-by: Peng Fan Reviewed-by: Catalin Marinas Reviewed-by: Mike Rapoport Cc: Laura Abbott Cc: Joonsoo Kim Cc: Michal Hocko Cc: Vlastimil Babka Cc: Marek Szyprowski Cc: Andrey Konovalov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7b287c47e4524bdc73152d77a68c68a044b9c111 Author: Qian Cai Date: Tue Mar 5 15:50:11 2019 -0800 mm/sparse: fix a bad comparison [ Upstream commit d778015ac95bc036af73342c878ab19250e01fe1 ] next_present_section_nr() could only return an unsigned number -1, so just check it specifically where compilers will convert -1 to unsigned if needed. mm/sparse.c: In function 'sparse_init_nid': mm/sparse.c:200:20: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] ((section_nr >= 0) && \ ^~ mm/sparse.c:478:2: note: in expansion of macro 'for_each_present_section_nr' for_each_present_section_nr(pnum_begin, pnum) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~ mm/sparse.c:200:20: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] ((section_nr >= 0) && \ ^~ mm/sparse.c:497:2: note: in expansion of macro 'for_each_present_section_nr' for_each_present_section_nr(pnum_begin, pnum) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~ mm/sparse.c: In function 'sparse_init': mm/sparse.c:200:20: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] ((section_nr >= 0) && \ ^~ mm/sparse.c:520:2: note: in expansion of macro 'for_each_present_section_nr' for_each_present_section_nr(pnum_begin + 1, pnum_end) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Link: http://lkml.kernel.org/r/20190228181839.86504-1-cai@lca.pw Fixes: c4e1be9ec113 ("mm, sparsemem: break out of loops early") Signed-off-by: Qian Cai Reviewed-by: Andrew Morton Cc: Dave Hansen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit aea8c971b9c5f7567d2f4ea9e932b8a82679a037 Author: Jiri Olsa Date: Tue Mar 5 16:25:29 2019 +0100 perf c2c: Fix c2c report for empty numa node [ Upstream commit e34c940245437f36d2c492edd1f8237eff391064 ] Ravi Bangoria reported that we fail with an empty NUMA node with the following message: $ lscpu NUMA node0 CPU(s): NUMA node1 CPU(s): 0-4 $ sudo ./perf c2c report node/cpu topology bugFailed setup nodes Fix this by detecting the empty node and keeping its CPU set empty. Reported-by: Nageswara R Sastry Signed-off-by: Jiri Olsa Tested-by: Ravi Bangoria Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jonas Rabenstein Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20190305152536.21035-2-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit c3f28d59c1a56f987d4b8210488bb22e9f60695e Author: Kairui Song Date: Wed Mar 6 19:18:27 2019 +0800 x86/hyperv: Fix kernel panic when kexec on HyperV [ Upstream commit 179fb36abb097976997f50733d5b122a29158cba ] After commit 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments"), kexec fails with a kernel panic: kexec_core: Starting new kernel BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v3.0 03/02/2018 RIP: 0010:0xffffc9000001d000 Call Trace: ? __send_ipi_mask+0x1c6/0x2d0 ? hv_send_ipi_mask_allbutself+0x6d/0xb0 ? mp_save_irq+0x70/0x70 ? __ioapic_read_entry+0x32/0x50 ? ioapic_read_entry+0x39/0x50 ? clear_IO_APIC_pin+0xb8/0x110 ? native_stop_other_cpus+0x6e/0x170 ? native_machine_shutdown+0x22/0x40 ? kernel_kexec+0x136/0x156 That happens if hypercall based IPIs are used because the hypercall page is reset very early upon kexec reboot, but kexec sends IPIs to stop CPUs, which invokes the hypercall and dereferences the unusable page. To fix his, reset hv_hypercall_pg to NULL before the page is reset to avoid any misuse, IPI sending will fall back to the non hypercall based method. This only happens on kexec / kdump so just setting the pointer to NULL is good enough. Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments") Signed-off-by: Kairui Song Signed-off-by: Thomas Gleixner Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Sasha Levin Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Vitaly Kuznetsov Cc: Dave Young Cc: devel@linuxdriverproject.org Link: https://lkml.kernel.org/r/20190306111827.14131-1-kasong@redhat.com Signed-off-by: Sasha Levin commit 3e8d62218aa48c7508282390538ff998d5750463 Author: Linus Torvalds Date: Wed Mar 6 15:41:29 2019 -0800 iio: adc: fix warning in Qualcomm PM8xxx HK/XOADC driver [ Upstream commit e0f0ae838a25464179d37f355d763f9ec139fc15 ] The pm8xxx_get_channel() implementation is unclear, and causes gcc to suddenly generate odd warnings. The trigger for the warning (at least for me) was the entirely unrelated commit 79a4e91d1bb2 ("device.h: Add __cold to dev_ logging functions"), which apparently changes gcc code generation in the caller function enough to cause this: drivers/iio/adc/qcom-pm8xxx-xoadc.c: In function ‘pm8xxx_xoadc_probe’: drivers/iio/adc/qcom-pm8xxx-xoadc.c:633:8: warning: ‘ch’ may be used uninitialized in this function [-Wmaybe-uninitialized] ret = pm8xxx_read_channel_rsv(adc, ch, AMUX_RSV4, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ &read_nomux_rsv4, true); ~~~~~~~~~~~~~~~~~~~~~~~ drivers/iio/adc/qcom-pm8xxx-xoadc.c:426:27: note: ‘ch’ was declared here struct pm8xxx_chan_info *ch; ^~ because gcc for some reason then isn't able to see that the termination condition for the "for( )" loop in that function is also the condition for returning NULL. So it's not _actually_ uninitialized, but the function is admittedly just unnecessarily oddly written. Simplify and clarify the function, making gcc also see that it always returns a valid initialized value. Cc: Joe Perches Cc: Greg Kroah-Hartman Cc: Andy Gross Cc: David Brown Cc: Jonathan Cameron Cc: Hartmut Knaack Cc: Lars-Peter Clausen Cc: Peter Meerwald-Stadler Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e27cced35a4b4c4531ab984a23cdd2f9e58ab2a1 Author: Xiang Chen Date: Thu Feb 28 22:50:58 2019 +0800 scsi: hisi_sas: Fix a timeout race of driver internal and SMP IO [ Upstream commit 4790595723d4b833b18c994973d39f9efb842887 ] For internal IO and SMP IO, there is a time-out timer for them. In the timer handler, it checks whether IO is done according to the flag task->task_state_lock. There is an issue which may cause system suspended: internal IO or SMP IO is sent, but at that time because of hardware exception (such as inject 2Bit ECC error), so IO is not completed and also not timeout. But, at that time, the SAS controller reset occurs to recover system. It will release the resource and set the status of IO to be SAS_TASK_STATE_DONE, so when IO timeout, it will never complete the completion of IO and wait for ever. [ 729.123632] Call trace: [ 729.126791] [] __switch_to+0x94/0xa8 [ 729.133106] [] __schedule+0x1e8/0x7fc [ 729.138975] [] schedule+0x34/0x8c [ 729.144401] [] schedule_timeout+0x1d8/0x3cc [ 729.150690] [] wait_for_common+0xdc/0x1a0 [ 729.157101] [] wait_for_completion+0x28/0x34 [ 729.165973] [] hisi_sas_internal_task_abort+0x2a0/0x424 [hisi_sas_test_main] [ 729.176447] [] hisi_sas_abort_task+0x244/0x2d8 [hisi_sas_test_main] [ 729.185258] [] sas_eh_handle_sas_errors+0x1c8/0x7b8 [ 729.192391] [] sas_scsi_recover_host+0x130/0x398 [ 729.199237] [] scsi_error_handler+0x148/0x5c0 [ 729.206009] [] kthread+0x10c/0x138 [ 729.211563] [] ret_from_fork+0x10/0x18 To solve the issue, callback function task_done of those IOs need to be called when on SAS controller reset. Signed-off-by: Xiang Chen Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fce6aeaf913e4a3b0c51e888348fd7c3a0fe6791 Author: John Garry Date: Thu Feb 28 22:51:00 2019 +0800 scsi: hisi_sas: Set PHY linkrate when disconnected [ Upstream commit efdcad62e7b8a02fcccc5ccca57806dce1482ac8 ] When the PHY comes down, we currently do not set the negotiated linkrate: root@(none)$ pwd /sys/class/sas_phy/phy-0:0 root@(none)$ more enable 1 root@(none)$ more negotiated_linkrate 12.0 Gbit root@(none)$ echo 0 > enable root@(none)$ more negotiated_linkrate 12.0 Gbit root@(none)$ This patch fixes the driver code to set it properly when the PHY comes down. If the PHY had been enabled, then set unknown; otherwise, flag as disabled. The logical place to set the negotiated linkrate for this scenario is PHY down routine, which is called from the PHY down ISR. However, it is not possible to know if the PHY comes down due to PHY disable or loss of link, as sas_phy.enabled member is not set until after the transport disable routine is complete, which races with the PHY down ISR. As an imperfect solution, use sas_phy_data.enable as the flag to know if the PHY is down due to disable. It's imperfect, as sas_phy_data is internal to libsas. I can't see another way without adding a new field to hisi_sas_phy and managing it, or changing SCSI SAS transport. Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e21f655c60fa82e1d00c9ecf7ae05665a82c4158 Author: Stanislav Fomichev Date: Wed Mar 6 11:59:27 2019 -0800 libbpf: force fixdep compilation at the start of the build [ Upstream commit 8e2688876c7f7073d925e1f150e86b8ed3338f52 ] libbpf targets don't explicitly depend on fixdep target, so when we do 'make -j$(nproc)', there is a high probability, that some objects will be built before fixdep binary is available. Fix this by running sub-make; this makes sure that fixdep dependency is properly accounted for. For the same issue in perf, see commit abb26210a395 ("perf tools: Force fixdep compilation at the start of the build"). Before: $ rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld -C tools/lib/bpf/ Auto-detecting system features: ... libelf: [ on ] ... bpf: [ on ] HOSTCC /tmp/bld/fixdep.o CC /tmp/bld/libbpf.o CC /tmp/bld/bpf.o CC /tmp/bld/btf.o CC /tmp/bld/nlattr.o CC /tmp/bld/libbpf_errno.o CC /tmp/bld/str_error.o CC /tmp/bld/netlink.o CC /tmp/bld/bpf_prog_linfo.o CC /tmp/bld/libbpf_probes.o CC /tmp/bld/xsk.o HOSTLD /tmp/bld/fixdep-in.o LINK /tmp/bld/fixdep LD /tmp/bld/libbpf-in.o LINK /tmp/bld/libbpf.a LINK /tmp/bld/libbpf.so LINK /tmp/bld/test_libbpf $ head /tmp/bld/.libbpf.o.cmd # cannot find fixdep (/usr/local/google/home/sdf/src/linux/xxx//fixdep) # using basic dep data /tmp/bld/libbpf.o: libbpf.c /usr/include/stdc-predef.h \ /usr/include/stdlib.h /usr/include/features.h \ /usr/include/x86_64-linux-gnu/sys/cdefs.h \ /usr/include/x86_64-linux-gnu/bits/wordsize.h \ /usr/include/x86_64-linux-gnu/gnu/stubs.h \ /usr/include/x86_64-linux-gnu/gnu/stubs-64.h \ /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h \ After: $ rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld -C tools/lib/bpf/ Auto-detecting system features: ... libelf: [ on ] ... bpf: [ on ] HOSTCC /tmp/bld/fixdep.o HOSTLD /tmp/bld/fixdep-in.o LINK /tmp/bld/fixdep CC /tmp/bld/libbpf.o CC /tmp/bld/bpf.o CC /tmp/bld/nlattr.o CC /tmp/bld/btf.o CC /tmp/bld/libbpf_errno.o CC /tmp/bld/str_error.o CC /tmp/bld/netlink.o CC /tmp/bld/bpf_prog_linfo.o CC /tmp/bld/libbpf_probes.o CC /tmp/bld/xsk.o LD /tmp/bld/libbpf-in.o LINK /tmp/bld/libbpf.a LINK /tmp/bld/libbpf.so LINK /tmp/bld/test_libbpf $ head /tmp/bld/.libbpf.o.cmd cmd_/tmp/bld/libbpf.o := gcc -Wp,-MD,/tmp/bld/.libbpf.o.d -Wp,-MT,/tmp/bld/libbpf.o -g -Wall -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Werror -Wall -fPIC -I. -I/usr/local/google/home/sdf/src/linux/tools/include -I/usr/local/google/home/sdf/src/linux/tools/arch/x86/include/uapi -I/usr/local/google/home/sdf/src/linux/tools/include/uapi -fvisibility=hidden -D"BUILD_STR(s)=$(pound)s" -c -o /tmp/bld/libbpf.o libbpf.c source_/tmp/bld/libbpf.o := libbpf.c deps_/tmp/bld/libbpf.o := \ /usr/include/stdc-predef.h \ /usr/include/stdlib.h \ /usr/include/features.h \ /usr/include/x86_64-linux-gnu/sys/cdefs.h \ /usr/include/x86_64-linux-gnu/bits/wordsize.h \ Fixes: 7c422f557266 ("tools build: Build fixdep helper from perf and basic libs") Reported-by: Eric Dumazet Signed-off-by: Stanislav Fomichev Acked-by: Yonghong Song Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 6048330675cc1d2b1dc88d3880c476f0f04157ba Author: Arnd Bergmann Date: Thu Mar 7 16:52:24 2019 +0100 enic: fix build warning without CONFIG_CPUMASK_OFFSTACK [ Upstream commit 43d281662fdb46750d49417559b71069f435298d ] The enic driver relies on the CONFIG_CPUMASK_OFFSTACK feature to dynamically allocate a struct member, but this is normally intended for local variables. Building with clang, I get a warning for a few locations that check the address of the cpumask_var_t: drivers/net/ethernet/cisco/enic/enic_main.c:122:22: error: address of array 'enic->msix[i].affinity_mask' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] As far as I can tell, the code is still correct, as the truth value of the pointer is what we need in this configuration. To get rid of the warning, use cpumask_available() instead of checking the pointer directly. Fixes: 322cf7e3a4e8 ("enic: assign affinity hint to interrupts") Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9ec4860de95afd979feb63da767cb0b78451880c Author: Nathan Chancellor Date: Thu Mar 7 11:00:28 2019 -0700 net: stmmac: Avoid sometimes uninitialized Clang warnings [ Upstream commit df103170854e87124ee7bdd2bca64b178e653f97 ] When building with -Wsometimes-uninitialized, Clang warns: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized] Clang is concerned with the use of stmmac_do_void_callback (which stmmac_get_timestamp and stmmac_config_sub_second_increment wrap), as it may fail to initialize these values if the if condition was ever false (meaning the callbacks don't exist). It's not wrong because the callbacks (get_timestamp and config_sub_second_increment respectively) are the ones that initialize the variables. While it's unlikely that the callbacks are ever going to disappear and make that condition false, we can easily avoid this warning by zero initialize the variables. Link: https://github.com/ClangBuiltLinux/linux/issues/384 Suggested-by: Nick Desaulniers Reviewed-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b227f15712691096027163a4600a7af1c4864320 Author: Christian Brauner Date: Thu Mar 7 16:29:43 2019 -0800 sysctl: handle overflow for file-max [ Upstream commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5 ] Currently, when writing echo 18446744073709551616 > /proc/sys/fs/file-max /proc/sys/fs/file-max will overflow and be set to 0. That quickly crashes the system. This commit sets the max and min value for file-max. The max value is set to long int. Any higher value cannot currently be used as the percpu counters are long ints and not unsigned integers. Note that the file-max value is ultimately parsed via __do_proc_doulongvec_minmax(). This function does not report error when min or max are exceeded. Which means if a value largen that long int is written userspace will not receive an error instead the old value will be kept. There is an argument to be made that this should be changed and __do_proc_doulongvec_minmax() should return an error when a dedicated min or max value are exceeded. However this has the potential to break userspace so let's defer this to an RFC patch. Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@brauner.io Signed-off-by: Christian Brauner Acked-by: Kees Cook Cc: Alexey Dobriyan Cc: Al Viro Cc: Dominik Brodowski Cc: "Eric W. Biederman" Cc: Joe Lawrence Cc: Luis Chamberlain Cc: Waiman Long [christian@brauner.io: v4] Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@brauner.io Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d6ad08aa3467b6cf5480aad6135c803e32891d2b Author: Luc Van Oostenryck Date: Thu Mar 7 16:31:28 2019 -0800 include/linux/relay.h: fix percpu annotation in struct rchan [ Upstream commit 62461ac2e5b6520b6d65fc6d7d7b4b8df4b848d8 ] The percpu member of this structure is declared as: struct ... ** __percpu member; So its type is: __percpu pointer to pointer to struct ... But looking at how it's used, its type should be: pointer to __percpu pointer to struct ... and it should thus be declared as: struct ... * __percpu *member; So fix the placement of '__percpu' in the definition of this structures. This silents a few Sparse's warnings like: warning: incorrect type in initializer (different address spaces) expected void const [noderef] *__vpp_verify got struct sched_domain ** Link: http://lkml.kernel.org/r/20190118144902.79065-1-luc.vanoostenryck@gmail.com Fixes: 017c59c042d01 ("relay: Use per CPU constructs for the relay channel buffer pointers") Signed-off-by: Luc Van Oostenryck Cc: Jens Axboe Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4c96500e3658330ab41135fe5b572634fe0a995c Author: Russell King Date: Fri Mar 1 11:02:52 2019 -0800 gpio: gpio-omap: fix level interrupt idling [ Upstream commit d01849f7deba81f4959fd9e51bf20dbf46987d1c ] Tony notes that the GPIO module does not idle when level interrupts are in use, as the wakeup appears to get stuck. After extensive investigation, it appears that the wakeup will only be cleared if the interrupt status register is cleared while the interrupt is enabled. However, we are currently clearing it with the interrupt disabled for level-based interrupts. It is acknowledged that this observed behaviour conflicts with a statement in the TRM: CAUTION After servicing the interrupt, the status bit in the interrupt status register (GPIOi.GPIO_IRQSTATUS_0 or GPIOi.GPIO_IRQSTATUS_1) must be reset and the interrupt line released (by setting the corresponding bit of the interrupt status register to 1) before enabling an interrupt for the GPIO channel in the interrupt-enable register (GPIOi.GPIO_IRQSTATUS_SET_0 or GPIOi.GPIO_IRQSTATUS_SET_1) to prevent the occurrence of unexpected interrupts when enabling an interrupt for the GPIO channel. However, this does not appear to be a practical problem. Further, as reported by Grygorii Strashko , the TI Android kernel tree has an earlier similar patch as "GPIO: OMAP: Fix the sequence to clear the IRQ status" saying: if the status is cleared after disabling the IRQ then sWAKEUP will not be cleared and gates the module transition When we unmask the level interrupt after the interrupt has been handled, enable the interrupt and only then clear the interrupt. If the interrupt is still pending, the hardware will re-assert the interrupt status. Should the caution note in the TRM prove to be a problem, we could use a clear-enable-clear sequence instead. Cc: Aaro Koskinen Cc: Keerthy Cc: Peter Ujfalusi Signed-off-by: Russell King [tony@atomide.com: updated comments based on an earlier TI patch] Signed-off-by: Tony Lindgren Acked-by: Grygorii Strashko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 8c50ab86e288a6ca49b1c5ae3cd092f46ef9db2e Author: Tonghao Zhang Date: Mon Mar 4 00:27:15 2019 -0800 net/mlx5: Avoid panic when setting vport mac, getting vport config [ Upstream commit 6e77c413e8e73d0f36b5358b601389d75ec4451c ] If we try to set VFs mac address on a VF (not PF) net device, the kernel will be crash. The commands are show as below: $ echo 2 > /sys/class/net/$MLX_PF0/device/sriov_numvfs $ ip link set $MLX_VF0 vf 0 mac 00:11:22:33:44:00 [exception RIP: mlx5_eswitch_set_vport_mac+41] [ffffb8b7079e3688] do_setlink at ffffffff8f67f85b [ffffb8b7079e37a8] __rtnl_newlink at ffffffff8f683778 [ffffb8b7079e3b68] rtnl_newlink at ffffffff8f683a63 [ffffb8b7079e3b90] rtnetlink_rcv_msg at ffffffff8f67d812 [ffffb8b7079e3c10] netlink_rcv_skb at ffffffff8f6b88ab [ffffb8b7079e3c60] netlink_unicast at ffffffff8f6b808f [ffffb8b7079e3ca0] netlink_sendmsg at ffffffff8f6b8412 [ffffb8b7079e3d18] sock_sendmsg at ffffffff8f6452f6 [ffffb8b7079e3d30] ___sys_sendmsg at ffffffff8f645860 [ffffb8b7079e3eb0] __sys_sendmsg at ffffffff8f647a38 [ffffb8b7079e3f38] do_syscall_64 at ffffffff8f00401b [ffffb8b7079e3f50] entry_SYSCALL_64_after_hwframe at ffffffff8f80008c and [exception RIP: mlx5_eswitch_get_vport_config+12] [ffffa70607e57678] mlx5e_get_vf_config at ffffffffc03c7f8f [mlx5_core] [ffffa70607e57688] do_setlink at ffffffffbc67fa59 [ffffa70607e577a8] __rtnl_newlink at ffffffffbc683778 [ffffa70607e57b68] rtnl_newlink at ffffffffbc683a63 [ffffa70607e57b90] rtnetlink_rcv_msg at ffffffffbc67d812 [ffffa70607e57c10] netlink_rcv_skb at ffffffffbc6b88ab [ffffa70607e57c60] netlink_unicast at ffffffffbc6b808f [ffffa70607e57ca0] netlink_sendmsg at ffffffffbc6b8412 [ffffa70607e57d18] sock_sendmsg at ffffffffbc6452f6 [ffffa70607e57d30] ___sys_sendmsg at ffffffffbc645860 [ffffa70607e57eb0] __sys_sendmsg at ffffffffbc647a38 [ffffa70607e57f38] do_syscall_64 at ffffffffbc00401b [ffffa70607e57f50] entry_SYSCALL_64_after_hwframe at ffffffffbc80008c Fixes: a8d70a054a718 ("net/mlx5: E-Switch, Disallow vlan/spoofcheck setup if not being esw manager") Cc: Eli Cohen Signed-off-by: Tonghao Zhang Reviewed-by: Roi Dayan Acked-by: Saeed Mahameed Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 3bddc6149f02ca87ed77b9b315148da98b0fe14f Author: Tonghao Zhang Date: Mon Mar 4 00:27:16 2019 -0800 net/mlx5: Avoid panic when setting vport rate [ Upstream commit 24319258660a84dd77f4be026a55b10a12524919 ] If we try to set VFs rate on a VF (not PF) net device, the kernel will be crash. The commands are show as below: $ echo 2 > /sys/class/net/$MLX_PF0/device/sriov_numvfs $ ip link set $MLX_VF0 vf 0 max_tx_rate 2 min_tx_rate 1 If not applied the first patch ("net/mlx5: Avoid panic when setting vport mac, getting vport config"), the command: $ ip link set $MLX_VF0 vf 0 rate 100 can also crash the kernel. [ 1650.006388] RIP: 0010:mlx5_eswitch_set_vport_rate+0x1f/0x260 [mlx5_core] [ 1650.007092] do_setlink+0x982/0xd20 [ 1650.007129] __rtnl_newlink+0x528/0x7d0 [ 1650.007374] rtnl_newlink+0x43/0x60 [ 1650.007407] rtnetlink_rcv_msg+0x2a2/0x320 [ 1650.007484] netlink_rcv_skb+0xcb/0x100 [ 1650.007519] netlink_unicast+0x17f/0x230 [ 1650.007554] netlink_sendmsg+0x2d2/0x3d0 [ 1650.007592] sock_sendmsg+0x36/0x50 [ 1650.007625] ___sys_sendmsg+0x280/0x2a0 [ 1650.007963] __sys_sendmsg+0x58/0xa0 [ 1650.007998] do_syscall_64+0x5b/0x180 [ 1650.009438] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: c9497c98901c ("net/mlx5: Add support for setting VF min rate") Cc: Mohamad Haj Yahia Signed-off-by: Tonghao Zhang Reviewed-by: Roi Dayan Acked-by: Saeed Mahameed Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit b73c7d0204521a61c64c65794a26e2cb75ff05af Author: Douglas Anderson Date: Fri Mar 8 11:32:04 2019 -0800 tracing: kdb: Fix ftdump to not sleep [ Upstream commit 31b265b3baaf55f209229888b7ffea523ddab366 ] As reported back in 2016-11 [1], the "ftdump" kdb command triggers a BUG for "sleeping function called from invalid context". kdb's "ftdump" command wants to call ring_buffer_read_prepare() in atomic context. A very simple solution for this is to add allocation flags to ring_buffer_read_prepare() so kdb can call it without triggering the allocation error. This patch does that. Note that in the original email thread about this, it was suggested that perhaps the solution for kdb was to either preallocate the buffer ahead of time or create our own iterator. I'm hoping that this alternative of adding allocation flags to ring_buffer_read_prepare() can be considered since it means I don't need to duplicate more of the core trace code into "trace_kdb.c" (for either creating my own iterator or re-preparing a ring allocator whose memory was already allocated). NOTE: another option for kdb is to actually figure out how to make it reuse the existing ftrace_dump() function and totally eliminate the duplication. This sounds very appealing and actually works (the "sr z" command can be seen to properly dump the ftrace buffer). The downside here is that ftrace_dump() fully consumes the trace buffer. Unless that is changed I'd rather not use it because it means "ftdump | grep xyz" won't be very useful to search the ftrace buffer since it will throw away the whole trace on the first grep. A future patch to dump only the last few lines of the buffer will also be hard to implement. [1] https://lkml.kernel.org/r/20161117191605.GA21459@google.com Link: http://lkml.kernel.org/r/20190308193205.213659-1-dianders@chromium.org Reported-by: Brian Norris Signed-off-by: Douglas Anderson Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit d7391962d723c92fbf02d2aa823e9f42413c76a7 Author: Chao Yu Date: Tue Mar 12 15:44:27 2019 +0800 f2fs: fix to avoid deadlock in f2fs_read_inline_dir() [ Upstream commit aadcef64b22f668c1a107b86d3521d9cac915c24 ] As Jiqun Li reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202883 sometimes, dead lock when make system call SYS_getdents64 with fsync() is called by another process. monkey running on android9.0 1. task 9785 held sbi->cp_rwsem and waiting lock_page() 2. task 10349 held mm_sem and waiting sbi->cp_rwsem 3. task 9709 held lock_page() and waiting mm_sem so this is a dead lock scenario. task stack is show by crash tools as following crash_arm64> bt ffffffc03c354080 PID: 9785 TASK: ffffffc03c354080 CPU: 1 COMMAND: "RxIoScheduler-3" >> #7 [ffffffc01b50fac0] __lock_page at ffffff80081b11e8 crash-arm64> bt 10349 PID: 10349 TASK: ffffffc018b83080 CPU: 1 COMMAND: "BUGLY_ASYNC_UPL" >> #3 [ffffffc01f8cfa40] rwsem_down_read_failed at ffffff8008a93afc PC: 00000033 LR: 00000000 SP: 00000000 PSTATE: ffffffffffffffff crash-arm64> bt 9709 PID: 9709 TASK: ffffffc03e7f3080 CPU: 1 COMMAND: "IntentService[A" >> #3 [ffffffc001e67850] rwsem_down_read_failed at ffffff8008a93afc >> #8 [ffffffc001e67b80] el1_ia at ffffff8008084fc4 PC: ffffff8008274114 [compat_filldir64+120] LR: ffffff80083584d4 [f2fs_fill_dentries+448] SP: ffffffc001e67b80 PSTATE: 80400145 X29: ffffffc001e67b80 X28: 0000000000000000 X27: 000000000000001a X26: 00000000000093d7 X25: ffffffc070d52480 X24: 0000000000000008 X23: 0000000000000028 X22: 00000000d43dfd60 X21: ffffffc001e67e90 X20: 0000000000000011 X19: ffffff80093a4000 X18: 0000000000000000 X17: 0000000000000000 X16: 0000000000000000 X15: 0000000000000000 X14: ffffffffffffffff X13: 0000000000000008 X12: 0101010101010101 X11: 7f7f7f7f7f7f7f7f X10: 6a6a6a6a6a6a6a6a X9: 7f7f7f7f7f7f7f7f X8: 0000000080808000 X7: ffffff800827409c X6: 0000000080808000 X5: 0000000000000008 X4: 00000000000093d7 X3: 000000000000001a X2: 0000000000000011 X1: ffffffc070d52480 X0: 0000000000800238 >> #9 [ffffffc001e67be0] f2fs_fill_dentries at ffffff80083584d0 PC: 0000003c LR: 00000000 SP: 00000000 PSTATE: 000000d9 X12: f48a02ff X11: d4678960 X10: d43dfc00 X9: d4678ae4 X8: 00000058 X7: d4678994 X6: d43de800 X5: 000000d9 X4: d43dfc0c X3: d43dfc10 X2: d46799c8 X1: 00000000 X0: 00001068 Below potential deadlock will happen between three threads: Thread A Thread B Thread C - f2fs_do_sync_file - f2fs_write_checkpoint - down_write(&sbi->node_change) -- 1) - do_page_fault - down_write(&mm->mmap_sem) -- 2) - do_wp_page - f2fs_vm_page_mkwrite - getdents64 - f2fs_read_inline_dir - lock_page -- 3) - f2fs_sync_node_pages - lock_page -- 3) - __do_map_lock - down_read(&sbi->node_change) -- 1) - f2fs_fill_dentries - dir_emit - compat_filldir64 - do_page_fault - down_read(&mm->mmap_sem) -- 2) Since f2fs_readdir is protected by inode.i_rwsem, there should not be any updates in inode page, we're safe to lookup dents in inode page without its lock held, so taking off the lock to improve concurrency of readdir and avoid potential deadlock. Reported-by: Jiqun Li Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 198c99857b302ad46a4717dc6351b069fc5ac17f Author: Chao Yu Date: Tue Mar 5 19:32:26 2019 +0800 f2fs: fix to adapt small inline xattr space in __find_inline_xattr() [ Upstream commit 2c28aba8b2e2a51749fa66e01b68e1cd5b53e022 ] With below testcase, we will fail to find existed xattr entry: 1. mkfs.f2fs -O extra_attr -O flexible_inline_xattr /dev/zram0 2. mount -t f2fs -o inline_xattr_size=1 /dev/zram0 /mnt/f2fs/ 3. touch /mnt/f2fs/file 4. setfattr -n "user.name" -v 0 /mnt/f2fs/file 5. getfattr -n "user.name" /mnt/f2fs/file /mnt/f2fs/file: user.name: No such attribute The reason is for inode which has very small inline xattr size, __find_inline_xattr() will fail to traverse any entry due to first entry may not be loaded from xattr node yet, later, we may skip to check entire xattr datas in __find_xattr(), result in such wrong condition. This patch adds condition to check such case to avoid this issue. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 56bb66c50296f9239487ae392e641d2a824d80fb Author: Masahiro Yamada Date: Fri Feb 15 13:04:26 2019 +0900 h8300: use cc-cross-prefix instead of hardcoding h8300-unknown-linux- [ Upstream commit fc2b47b55f17fd996f7a01975ce1c33c2f2513f6 ] It believe it is a bad idea to hardcode a specific compiler prefix that may or may not be installed on a user's system. It is annoying when testing features that should not require compilers at all. For example, mrproper, headers_install, etc. should work without any compiler. They look like follows on my machine. $ make ARCH=h8300 mrproper ./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found ./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found make: h8300-unknown-linux-gcc: Command not found make: h8300-unknown-linux-gcc: Command not found [ a bunch of the same error messages continue ] $ make ARCH=h8300 headers_install ./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found ./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found make: h8300-unknown-linux-gcc: Command not found HOSTCC scripts/basic/fixdep make: h8300-unknown-linux-gcc: Command not found WRAP arch/h8300/include/generated/uapi/asm/kvm_para.h [ snip ] The solution is to delete this line, or to use cc-cross-prefix like some architectures do. I chose the latter as a moderate fixup. I added an alternative 'h8300-linux-' because it is available at: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 2938651d36cae8c22e79d293fe9802cc9d5f97f3 Author: Aurelien Aptel Date: Thu Mar 14 18:44:16 2019 +0100 CIFS: fix POSIX lock leak and invalid ptr deref [ Upstream commit bc31d0cdcfbadb6258b45db97e93b1c83822ba33 ] We have a customer reporting crashes in lock_get_status() with many "Leaked POSIX lock" messages preceeding the crash. Leaked POSIX lock on dev=0x0:0x56 ... Leaked POSIX lock on dev=0x0:0x56 ... Leaked POSIX lock on dev=0x0:0x56 ... Leaked POSIX lock on dev=0x0:0x53 ... Leaked POSIX lock on dev=0x0:0x53 ... Leaked POSIX lock on dev=0x0:0x53 ... Leaked POSIX lock on dev=0x0:0x53 ... POSIX: fl_owner=ffff8900e7b79380 fl_flags=0x1 fl_type=0x1 fl_pid=20709 Leaked POSIX lock on dev=0x0:0x4b ino... Leaked locks on dev=0x0:0x4b ino=0xf911400000029: POSIX: fl_owner=ffff89f41c870e00 fl_flags=0x1 fl_type=0x1 fl_pid=19592 stack segment: 0000 [#1] SMP Modules linked in: binfmt_misc msr tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag rpcsec_gss_krb5 arc4 ecb auth_rpcgss nfsv4 md4 nfs nls_utf8 lockd grace cifs sunrpc ccm dns_resolver fscache af_packet iscsi_ibft iscsi_boot_sysfs vmw_vsock_vmci_transport vsock xfs libcrc32c sb_edac edac_core crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg ansi_cprng vmw_balloon aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev pcspkr vmxnet3 i2c_piix4 vmw_vmci shpchp fjes processor button ac btrfs xor raid6_pq sr_mod cdrom ata_generic sd_mod ata_piix vmwgfx crc32c_intel drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm serio_raw ahci libahci drm libata vmw_pvscsi sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4 Supported: Yes CPU: 6 PID: 28250 Comm: lsof Not tainted 4.4.156-94.64-default #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 task: ffff88a345f28740 ti: ffff88c74005c000 task.ti: ffff88c74005c000 RIP: 0010:[] [] lock_get_status+0x9b/0x3b0 RSP: 0018:ffff88c74005fd90 EFLAGS: 00010202 RAX: ffff89bde83e20ae RBX: ffff89e870003d18 RCX: 0000000049534f50 RDX: ffffffff81a3541f RSI: ffffffff81a3544e RDI: ffff89bde83e20ae RBP: 0026252423222120 R08: 0000000020584953 R09: 000000000000ffff R10: 0000000000000000 R11: ffff88c74005fc70 R12: ffff89e5ca7b1340 R13: 00000000000050e5 R14: ffff89e870003d30 R15: ffff89e5ca7b1340 FS: 00007fafd64be800(0000) GS:ffff89f41fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000001c80018 CR3: 000000a522048000 CR4: 0000000000360670 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: 0000000000000208 ffffffff81a3d6b6 ffff89e870003d30 ffff89e870003d18 ffff89e5ca7b1340 ffff89f41738d7c0 ffff89e870003d30 ffff89e5ca7b1340 ffffffff8125e08f 0000000000000000 ffff89bc22b67d00 ffff88c74005ff28 Call Trace: [] locks_show+0x2f/0x70 [] seq_read+0x251/0x3a0 [] proc_reg_read+0x3c/0x70 [] __vfs_read+0x26/0x140 [] vfs_read+0x7a/0x120 [] SyS_read+0x42/0xa0 [] entry_SYSCALL_64_fastpath+0x1e/0xb7 When Linux closes a FD (close(), close-on-exec, dup2(), ...) it calls filp_close() which also removes all posix locks. The lock struct is initialized like so in filp_close() and passed down to cifs ... lock.fl_type = F_UNLCK; lock.fl_flags = FL_POSIX | FL_CLOSE; lock.fl_start = 0; lock.fl_end = OFFSET_MAX; ... Note the FL_CLOSE flag, which hints the VFS code that this unlocking is done for closing the fd. filp_close() locks_remove_posix(filp, id); vfs_lock_file(filp, F_SETLK, &lock, NULL); return filp->f_op->lock(filp, cmd, fl) => cifs_lock() rc = cifs_setlk(file, flock, type, wait_flag, posix_lck, lock, unlock, xid); rc = server->ops->mand_unlock_range(cfile, flock, xid); if (flock->fl_flags & FL_POSIX && !rc) rc = locks_lock_file_wait(file, flock) Notice how we don't call locks_lock_file_wait() which does the generic VFS lock/unlock/wait work on the inode if rc != 0. If we are closing the handle, the SMB server is supposed to remove any locks associated with it. Similarly, cifs.ko frees and wakes up any lock and lock waiter when closing the file: cifs_close() cifsFileInfo_put(file->private_data) /* * Delete any outstanding lock records. We'll lose them when the file * is closed anyway. */ down_write(&cifsi->lock_sem); list_for_each_entry_safe(li, tmp, &cifs_file->llist->locks, llist) { list_del(&li->llist); cifs_del_lock_waiters(li); kfree(li); } list_del(&cifs_file->llist->llist); kfree(cifs_file->llist); up_write(&cifsi->lock_sem); So we can safely ignore unlocking failures in cifs_lock() if they happen with the FL_CLOSE flag hint set as both the server and the client take care of it during the actual closing. This is not a proper fix for the unlocking failure but it's safe and it seems to prevent the lock leakages and crashes the customer experiences. Signed-off-by: Aurelien Aptel Signed-off-by: NeilBrown Signed-off-by: Steve French Acked-by: Pavel Shilovsky Signed-off-by: Sasha Levin commit 442d5d171cd8280d0c9a79674b5f24c7bfaf3117 Author: Razvan Stefanescu Date: Tue Mar 19 15:20:35 2019 +0200 tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped commit 69646d7a3689fbe1a65ae90397d22ac3f1b8d40f upstream. In half-duplex operation, RX should be started after TX completes. If DMA is used, there is a case when the DMA transfer completes but the TX FIFO is not emptied, so the RX cannot be restarted just yet. Use a boolean variable to store this state and rearm TX interrupt mask to be signaled again that the transfer finished. In interrupt transmit handler this variable is used to start RX. A warning message is generated if RX is activated before TX fifo is cleared. Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done") Signed-off-by: Razvan Stefanescu Acked-by: Richard Genoud Cc: stable Signed-off-by: Greg Kroah-Hartman commit b6b4bcb40be079dd36db63d85e89422441f7d57d Author: Razvan Stefanescu Date: Tue Mar 19 15:20:34 2019 +0200 tty/serial: atmel: Add is_half_duplex helper commit f3040983132bf3477acd45d2452a906e67c2fec9 upstream. Use a helper function to check that a port needs to use half duplex communication, replacing several occurrences of multi-line bit checking. Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done") Cc: stable Signed-off-by: Razvan Stefanescu Acked-by: Richard Genoud Signed-off-by: Greg Kroah-Hartman commit 2dbc7c66d6dafb7781c55d067d8e406d71a34ccc Author: zhangyi (F) Date: Sat Mar 23 11:56:01 2019 -0400 ext4: cleanup bh release code in ext4_ind_remove_space() commit 5e86bdda41534e17621d5a071b294943cae4376e upstream. Currently, we are releasing the indirect buffer where we are done with it in ext4_ind_remove_space(), so we can see the brelse() and BUFFER_TRACE() everywhere. It seems fragile and hard to read, and we may probably forget to release the buffer some day. This patch cleans up the code by putting of the code which releases the buffers to the end of the function. Signed-off-by: zhangyi (F) Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Cc: Jari Ruusu Signed-off-by: Greg Kroah-Hartman commit bd62f1fe736e0638a2010be5d5ed51ac04c105c4 Author: Will Deacon Date: Fri Mar 1 13:28:00 2019 +0000 arm64: debug: Don't propagate UNKNOWN FAR into si_code for debug signals commit b9a4b9d084d978f80eb9210727c81804588b42ff upstream. FAR_EL1 is UNKNOWN for all debug exceptions other than those caused by taking a hardware watchpoint. Unfortunately, if a debug handler returns a non-zero value, then we will propagate the UNKNOWN FAR value to userspace via the si_addr field of the SIGTRAP siginfo_t. Instead, let's set si_addr to take on the PC of the faulting instruction, which we have available in the current pt_regs. Cc: Reviewed-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman