commit f9fb85751506e75ecffaa498896efbb0c886adda Author: Greg Kroah-Hartman Date: Wed Apr 8 09:11:10 2020 +0200 Linux 5.6.3 commit 3c216b36aae719029f0431c67500d4eef9f77dd6 Author: Randy Dunlap Date: Wed Apr 1 21:10:58 2020 -0700 mm: mempolicy: require at least one nodeid for MPOL_PREFERRED commit aa9f7d5172fac9bf1f09e678c35e287a40a7b7dd upstream. Using an empty (malformed) nodelist that is not caught during mount option parsing leads to a stack-out-of-bounds access. The option string that was used was: "mpol=prefer:,". However, MPOL_PREFERRED requires a single node number, which is not being provided here. Add a check that 'nodes' is not empty after parsing for MPOL_PREFERRED's nodeid. Fixes: 095f1fc4ebf3 ("mempolicy: rework shmem mpol parsing and display") Reported-by: Entropy Moe <3ntr0py1337@gmail.com> Reported-by: syzbot+b055b1a6b2b958707a21@syzkaller.appspotmail.com Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Tested-by: syzbot+b055b1a6b2b958707a21@syzkaller.appspotmail.com Cc: Lee Schermerhorn Link: http://lkml.kernel.org/r/89526377-7eb6-b662-e1d8-4430928abde9@infradead.org Signed-off-by: Linus Torvalds Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 333d4e5cca7b8ef1b9e2a348806840726148a6fc Author: Arnaldo Carvalho de Melo Date: Wed Apr 1 09:33:59 2020 -0300 perf python: Fix clang detection to strip out options passed in $CC commit 9ff76cea4e9e6d49a6f764ae114fc0fb8de97816 upstream. The clang check in the python setup.py file expected $CC to be just the name of the compiler, not the compiler + options, i.e. all options were expected to be passed in $CFLAGS, this ends up making it fail in systems where CC is set to, e.g.: "aarch64-linaro-linux-gcc --sysroot=/oe/build/tmp/work/juno-linaro-linux/perf/1.0-r9/recipe-sysroot" Like this: $ python3 >>> from subprocess import Popen >>> a = Popen(["aarch64-linux-gnu-gcc --sysroot=/oe/build/tmp/work/juno-linaro-linux/perf/1.0-r9/recipe-sysroot", "-v"]) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.6/subprocess.py", line 729, in __init__ restore_signals, start_new_session) File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: 'aarch64-linux-gnu-gcc --sysroot=/oe/build/tmp/work/juno-linaro-linux/perf/1.0-r9/recipe-sysroot': 'aarch64-linux-gnu-gcc --sysroot=/oe/build/tmp/work/juno-linaro-linux/perf/1.0-r9/recipe-sysroot' >>> Make it more robust, covering this case, by passing cc.split()[0] as the first arg to popen(). Fixes: a7ffd416d804 ("perf python: Fix clang detection when using CC=clang-version") Reported-by: Daniel Díaz Reported-by: Naresh Kamboju Tested-by: Daniel Díaz Cc: Adrian Hunter Cc: Ilie Halip Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/20200401124037.GA12534@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit c78b89e1957b40595083fb6e3f8410add068957b Author: Bibby Hsieh Date: Fri Feb 14 12:35:45 2020 +0800 soc: mediatek: knows_txdone needs to be set in Mediatek CMDQ helper commit ce35e21d82bcac8b3fd5128888f9e233f8444293 upstream. Mediatek CMDQ driver have a mechanism to do TXDONE_BY_ACK, so we should set knows_txdone. Fixes:576f1b4bc802 ("soc: mediatek: Add Mediatek CMDQ helper") Cc: stable@vger.kernel.org # v5.0+ Signed-off-by: Bibby Hsieh Reviewed-by: CK Hu Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman commit 969addf8b9a194591b225bb7feeec3ce97da9673 Author: Geoffrey Allott Date: Thu Mar 19 14:00:48 2020 +0000 ALSA: hda/ca0132 - Add Recon3Di quirk to handle integrated sound on EVGA X99 Classified motherboard commit e9097e47e349b747dee50f935216de0ffb662962 upstream. I have a system which has an EVGA X99 Classified motherboard. The pin assignments for the HD Audio controller are not correct under Linux. Windows 10 works fine and informs me that it's using the Recon3Di driver, and on Linux, `cat /sys/class/sound/card0/device/subsystem_{vendor,device}` yields 0x3842 0x1038 This patch adds a corresponding entry to the quirk list. Signed-off-by: Geoffrey Allott Cc: Link: https://lore.kernel.org/r/a6cd56b678c00ce2db3685e4278919f2584f8244.camel@allott.email Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 70c6656d5268be837b44b7f77a36706959364280 Author: Mike Snitzer Date: Thu Apr 2 19:36:26 2020 -0400 Revert "dm: always call blk_queue_split() in dm_process_bio()" commit 120c9257f5f19e5d1e87efcbb5531b7cd81b7d74 upstream. This reverts commit effd58c95f277744f75d6e08819ac859dbcbd351. blk_queue_split() is causing excessive IO splitting -- because blk_max_size_offset() depends on 'chunk_sectors' limit being set and if it isn't (as is the case for DM targets!) it falls back to splitting on a 'max_sectors' boundary regardless of offset. "Fix" this by reverting back to _not_ using blk_queue_split() in dm_process_bio() for normal IO (reads and writes). Long-term fix is still TBD but it should focus on training blk_max_size_offset() to call into a DM provided hook (to call DM's max_io_len()). Test results from simple misaligned IO test on 4-way dm-striped device with chunksize of 128K and stripesize of 512K: xfs_io -d -c 'pread -b 2m 224s 4072s' /dev/mapper/stripe_dev before this revert: 253,0 21 1 0.000000000 2206 Q R 224 + 4072 [xfs_io] 253,0 21 2 0.000008267 2206 X R 224 / 480 [xfs_io] 253,0 21 3 0.000010530 2206 X R 224 / 256 [xfs_io] 253,0 21 4 0.000027022 2206 X R 480 / 736 [xfs_io] 253,0 21 5 0.000028751 2206 X R 480 / 512 [xfs_io] 253,0 21 6 0.000033323 2206 X R 736 / 992 [xfs_io] 253,0 21 7 0.000035130 2206 X R 736 / 768 [xfs_io] 253,0 21 8 0.000039146 2206 X R 992 / 1248 [xfs_io] 253,0 21 9 0.000040734 2206 X R 992 / 1024 [xfs_io] 253,0 21 10 0.000044694 2206 X R 1248 / 1504 [xfs_io] 253,0 21 11 0.000046422 2206 X R 1248 / 1280 [xfs_io] 253,0 21 12 0.000050376 2206 X R 1504 / 1760 [xfs_io] 253,0 21 13 0.000051974 2206 X R 1504 / 1536 [xfs_io] 253,0 21 14 0.000055881 2206 X R 1760 / 2016 [xfs_io] 253,0 21 15 0.000057462 2206 X R 1760 / 1792 [xfs_io] 253,0 21 16 0.000060999 2206 X R 2016 / 2272 [xfs_io] 253,0 21 17 0.000062489 2206 X R 2016 / 2048 [xfs_io] 253,0 21 18 0.000066133 2206 X R 2272 / 2528 [xfs_io] 253,0 21 19 0.000067507 2206 X R 2272 / 2304 [xfs_io] 253,0 21 20 0.000071136 2206 X R 2528 / 2784 [xfs_io] 253,0 21 21 0.000072764 2206 X R 2528 / 2560 [xfs_io] 253,0 21 22 0.000076185 2206 X R 2784 / 3040 [xfs_io] 253,0 21 23 0.000077486 2206 X R 2784 / 2816 [xfs_io] 253,0 21 24 0.000080885 2206 X R 3040 / 3296 [xfs_io] 253,0 21 25 0.000082316 2206 X R 3040 / 3072 [xfs_io] 253,0 21 26 0.000085788 2206 X R 3296 / 3552 [xfs_io] 253,0 21 27 0.000087096 2206 X R 3296 / 3328 [xfs_io] 253,0 21 28 0.000093469 2206 X R 3552 / 3808 [xfs_io] 253,0 21 29 0.000095186 2206 X R 3552 / 3584 [xfs_io] 253,0 21 30 0.000099228 2206 X R 3808 / 4064 [xfs_io] 253,0 21 31 0.000101062 2206 X R 3808 / 3840 [xfs_io] 253,0 21 32 0.000104956 2206 X R 4064 / 4096 [xfs_io] 253,0 21 33 0.001138823 0 C R 4096 + 200 [0] after this revert: 253,0 18 1 0.000000000 4430 Q R 224 + 3896 [xfs_io] 253,0 18 2 0.000018359 4430 X R 224 / 256 [xfs_io] 253,0 18 3 0.000028898 4430 X R 256 / 512 [xfs_io] 253,0 18 4 0.000033535 4430 X R 512 / 768 [xfs_io] 253,0 18 5 0.000065684 4430 X R 768 / 1024 [xfs_io] 253,0 18 6 0.000091695 4430 X R 1024 / 1280 [xfs_io] 253,0 18 7 0.000098494 4430 X R 1280 / 1536 [xfs_io] 253,0 18 8 0.000114069 4430 X R 1536 / 1792 [xfs_io] 253,0 18 9 0.000129483 4430 X R 1792 / 2048 [xfs_io] 253,0 18 10 0.000136759 4430 X R 2048 / 2304 [xfs_io] 253,0 18 11 0.000152412 4430 X R 2304 / 2560 [xfs_io] 253,0 18 12 0.000160758 4430 X R 2560 / 2816 [xfs_io] 253,0 18 13 0.000183385 4430 X R 2816 / 3072 [xfs_io] 253,0 18 14 0.000190797 4430 X R 3072 / 3328 [xfs_io] 253,0 18 15 0.000197667 4430 X R 3328 / 3584 [xfs_io] 253,0 18 16 0.000218751 4430 X R 3584 / 3840 [xfs_io] 253,0 18 17 0.000226005 4430 X R 3840 / 4096 [xfs_io] 253,0 18 18 0.000250404 4430 Q R 4120 + 176 [xfs_io] 253,0 18 19 0.000847708 0 C R 4096 + 24 [0] 253,0 18 20 0.000855783 0 C R 4120 + 176 [0] Fixes: effd58c95f27774 ("dm: always call blk_queue_split() in dm_process_bio()") Cc: stable@vger.kernel.org Reported-by: Andreas Gruenbacher Tested-by: Barry Marson Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 3b258ac8673325d9a8051b53e3e3ef358ef7500b Author: Takashi Iwai Date: Tue Mar 31 11:00:23 2020 +0200 Revert "ALSA: uapi: Drop asound.h inclusion from asoc.h" commit b6f69c795547f59ddf1db17cddbd2b9a15c656ed upstream. This reverts commit 645c08f17f477915f6d900b767e789852f150054 which was reported to break the build a program using this header. The original issue was addressed in the alsa-lib side recently, so we can make the header more self-contained again. Reported-by: Dmitry V. Levin Fixes: 645c08f17f47 ("ALSA: uapi: Drop asound.h inclusion from asoc.h") Cc: Link: https://lore.kernel.org/r/20200331090023.8112-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 00082d7aaf8fbc2aef3a5979b8413325bbae1e27 Author: Hans de Goede Date: Sun Feb 23 16:32:08 2020 +0100 power: supply: axp288_charger: Add special handling for HP Pavilion x2 10 commit 9c80662a74cd2a5d1113f5c69d027face963a556 upstream. Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge. We use a native power_supply / PMIC driver in this case, because on most models with an AXP288 the ACPI AC / Battery code is either completely missing or relies on custom / proprietary ACPI OpRegions which Linux does not implement. The native drivers mostly work fine, but there are 2 problems: 1. These model uses a Type-C connector for charging which the AXP288 does not support. As long as a Type-A charger (which uses the USB data pins for charger type detection) is used everything is fine. But if a Type-C charger is used (such as the charger shipped with the device) then the charger is not recognized. So we end up slowly discharging the device even though a charger is connected, because we are limiting the current from the charger to 500mA. To make things worse this happens with the device's official charger. Looking at the ACPI tables HP has "solved" the problem of the AXP288 not being able to recognize Type-C chargers by simply always programming the input-current-limit at 3000mA and relying on a Vhold setting of 4.7V (normally 4.4V) to limit the current intake if the charger cannot handle this. 2. If no charger is connected when the machine boots then it boots with the vbus-path disabled. On other devices this is done when a 5V boost converter is active to avoid the PMIC trying to charge from the 5V boost output. This is done when an OTG host cable is inserted and the ID pin on the micro-B receptacle is pulled low, the ID pin has an ACPI event handler associated with it which re-enables the vbus-path when the ID pin is pulled high when the OTG cable is removed. The Type-C connector has no ID pin, there is no ID pin handler and there appears to be no 5V boost converter, so we end up not charging because the vbus-path is disabled, until we unplug the charger which automatically clears the vbus-path disable bit and then on the second plug-in of the adapter we start charging. The HP Pavilion x2 10 models with an AXP288 do have mostly working ACPI AC / Battery code which does not rely on custom / proprietary ACPI OpRegions. So one possible solution would be to blacklist the AXP288 native power_supply drivers and add the HP Pavilion x2 10 with AXP288 DMI ids to the list of devices which should use the ACPI AC / Battery code even though they have an AXP288 PMIC. This would require changes to 4 files: drivers/acpi/ac.c, drivers/power/supply/axp288_charger.c, drivers/acpi/battery.c and drivers/power/supply/axp288_fuel_gauge.c. Beside needing adding the same DMI matches to 4 different files, this approach also triggers problem 2. from above, but then when suspended, during suspend the machine will not wakeup because the vbus path is disabled by the AML code when not charging, so the Vbus low-to-high IRQ is not triggered, the CPU never wakes up and the device does not charge even though the user likely things it is charging, esp. since the charge status LED is directly coupled to an adapter being plugged in and does not reflect actual charging. This could be worked by enabling vbus-path explicitly from say the axp288_charger driver's suspend handler. So neither situation is ideal, in both cased we need to explicitly enable the vbus-path to work around different variants of problem 2 above, this requires a quirk in the axp288_charger code. If we go the route of using the ACPI AC / Battery drivers then we need modifications to 3 other drivers; and we need to partially disable the axp288_charger code, while at the same time keeping it around to enable vbus-path on suspend. OTOH we can copy the hardcoding of 3A input-current-limit (we never touch Vhold, so that would stay at 4.7V) to the axp288_charger code, which needs changes regardless, then we concentrate all special handling of this interesting device model in the axp288_charger code. That is what this commit does. Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1791098 Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 83ca627eccee2ebb8de72c24822106226e62cb32 Author: Hans de Goede Date: Mon Mar 23 22:59:39 2020 +0100 extcon: axp288: Add wakeup support commit 9c94553099efb2ba873cbdddfd416a8a09d0e5f1 upstream. On devices with an AXP288, we need to wakeup from suspend when a charger is plugged in, so that we can do charger-type detection and so that the axp288-charger driver, which listens for our extcon events, can configure the input-current-limit accordingly. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 5698100982a192f0505c64e6a975d22008110fc7 Author: Freeman Liu Date: Mon Mar 23 15:00:03 2020 +0000 nvmem: sprd: Fix the block lock operation commit c66ebde4d988b592e8f0008e04c47cc4950a49d3 upstream. According to the Spreadtrum eFuse specification, we should write 0 to the block to trigger the lock operation. Fixes: 096030e7f449 ("nvmem: sprd: Add Spreadtrum SoCs eFuse support") Cc: stable Signed-off-by: Freeman Liu Signed-off-by: Baolin Wang Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200323150007.7487-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman commit 2f3146b86c03c9fead718e9b0c4f22c0b98c62da Author: Nicholas Johnson Date: Tue Mar 10 13:22:52 2020 +0000 nvmem: check for NULL reg_read and reg_write before dereferencing commit 3c91ef69a3e94f78546b246225ed573fbf1735b4 upstream. Return -EPERM if reg_read is NULL in bin_attr_nvmem_read() or if reg_write is NULL in bin_attr_nvmem_write(). This prevents NULL dereferences such as the one described in 03cd45d2e219 ("thunderbolt: Prevent crash if non-active NVMem file is read") Signed-off-by: Nicholas Johnson Cc: stable Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200310132257.23358-10-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman commit ede3d1cd27afc4a0381bfff1660fc89c598c982f Author: Khouloud Touil Date: Tue Mar 10 13:22:50 2020 +0000 nvmem: release the write-protect pin commit a9c3766cb19cdadf2776aba41b64470002645894 upstream. Put the write-protect GPIO descriptor in nvmem_release() so that it can be automatically released when the associated device's reference count drops to 0. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Reported-by: Geert Uytterhoeven Signed-off-by: Khouloud Touil Cc: stable [Bartosz: tweak the commit message] Signed-off-by: Bartosz Golaszewski Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200310132257.23358-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman commit c9f816ed6ae5e552bd3810db95e35af853bc38c4 Author: Alexander Usyskin Date: Tue Mar 24 23:07:30 2020 +0200 mei: me: add cedar fork device ids commit 99397d33b763dc554d118aaa38cc5abc6ce985de upstream. Add Cedar Fork (CDF) device ids, those belongs to the cannon point family. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20200324210730.17672-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit c33696a50819cd2bd2cf43d4ef701f16a21b09ea Author: Eugene Syromiatnikov Date: Tue Mar 24 05:22:13 2020 +0100 coresight: do not use the BIT() macro in the UAPI header commit 9b6eaaf3db5e5888df7bca7fed7752a90f7fd871 upstream. The BIT() macro definition is not available for the UAPI headers (moreover, it can be defined differently in the user space); replace its usage with the _BITUL() macro that is defined in . Fixes: 237483aa5cf4 ("coresight: stm: adding driver for CoreSight STM component") Signed-off-by: Eugene Syromiatnikov Cc: stable Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200324042213.GA10452@asgard.redhat.com Signed-off-by: Greg Kroah-Hartman commit 1083a54da4effc707c8188d14306e8fbbaf755d6 Author: Kelsey Skunberg Date: Wed Mar 25 09:17:08 2020 -0600 PCI: sysfs: Revert "rescan" file renames commit bd641fd8303a371e789e924291086268256766b0 upstream. We changed these sysfs filenames: .../pci_bus//rescan -> .../pci_bus//bus_rescan ...//rescan -> ...//dev_rescan and Ruslan reported [1] that this broke a userspace application. Revert these name changes so both files are named "rescan" again. Note that we have to use __ATTR() to assign custom C symbols, i.e., "struct device_attribute ". [1] https://lore.kernel.org/r/CAB=otbSYozS-ZfxB0nCiNnxcbqxwrHOSYxJJtDKa63KzXbXgpw@mail.gmail.com [bhelgaas: commit log, use __ATTR() both places so we don't have to rename the attributes] Fixes: 8bdfa145f582 ("PCI: sysfs: Define device attributes with DEVICE_ATTR*()") Fixes: 4e2b79436e4f ("PCI: sysfs: Change DEVICE_ATTR() to DEVICE_ATTR_WO()") Link: https://lore.kernel.org/r/20200325151708.32612-1-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg Signed-off-by: Bjorn Helgaas Reviewed-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Greg Kroah-Hartman commit 08c4c49b435eef17acbc94db1efffa4c07565b27 Author: Kishon Vijay Abraham I Date: Tue Mar 17 15:31:54 2020 +0530 misc: pci_endpoint_test: Avoid using module parameter to determine irqtype commit b2ba9225e0313b1de631a44b7b48c109032bffec upstream. commit e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands") uses module parameter 'irqtype' in pci_endpoint_test_set_irq() to check if IRQ vectors of a particular type (MSI or MSI-X or LEGACY) is already allocated. However with multi-function devices, 'irqtype' will not correctly reflect the IRQ type of the PCI device. Fix it here by adding 'irqtype' for each PCI device to show the IRQ type of a particular PCI device. Fixes: e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman commit a68d25212c58963954addf99dd2735fbd54e7fb8 Author: Kishon Vijay Abraham I Date: Tue Mar 17 15:31:57 2020 +0530 misc: pci_endpoint_test: Fix to support > 10 pci-endpoint-test devices commit 6b443e5c80b67a7b8a85b33d052d655ef9064e90 upstream. Adding more than 10 pci-endpoint-test devices results in "kobject_add_internal failed for pci-endpoint-test.1 with -EEXIST, don't try to register things with the same name in the same directory". This is because commit 2c156ac71c6b ("misc: Add host side PCI driver for PCI test function device") limited the length of the "name" to 20 characters. Change the length of the name to 24 in order to support upto 10000 pci-endpoint-test devices. Fixes: 2c156ac71c6b ("misc: Add host side PCI driver for PCI test function device") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Greg Kroah-Hartman commit e6306ca83c11d6e569dcf7c773e0c5d65ebc1439 Author: YueHaibing Date: Thu Mar 26 11:26:18 2020 +0800 misc: rtsx: set correct pcr_ops for rts522A commit 10cea23b6aae15e8324f4101d785687f2c514fe5 upstream. rts522a should use rts522a_pcr_ops, which is diffrent with rts5227 in phy/hw init setting. Fixes: ce6a5acc9387 ("mfd: rtsx: Add support for rts522A") Signed-off-by: YueHaibing Cc: stable Link: https://lore.kernel.org/r/20200326032618.20472-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman commit f9c56c0d613dd8d188ba6c5164bdd7197cb53d9f Author: Uma Shankar Date: Thu Mar 26 18:21:11 2020 +0530 drm/i915/display: Fix mode private_flags comparison at atomic_check commit 2bdd4c28baff29163808677a70942de2b45f17dc upstream. This patch fixes the private_flags of mode to be checked and compared against uapi.mode and not from hw.mode. This helps properly trigger modeset at boot if desired by driver. It helps resolve audio_codec initialization issues if display is connected at boot. Initial discussion on this issue has happened on below thread: https://patchwork.freedesktop.org/series/74828/ v2: No functional change. Fixed the Closes tag and added Maarten's RB. v3: Added Fixes tag. Cc: Ville Syrjä Cc: Maarten Lankhorst Cc: Kai Vehmanen Cc: Souza, Jose Fixes: 58d124ea2739 ("drm/i915: Complete crtc hw/uapi split, v6.") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1363 Suggested-by: Ville Syrjä Signed-off-by: Uma Shankar Signed-off-by: SweeAun Khor Reviewed-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20200326125111.11081-1-uma.shankar@intel.com (cherry picked from commit d5e56705927e00f703b2eb5a98299dd6622d16e5) Signed-off-by: Rodrigo Vivi Cc: Giacomo Comes Signed-off-by: Greg Kroah-Hartman commit a90e89bb42e9b6a1d8962bcff6a99e53de4f6c05 Author: Torsten Duwe Date: Tue Feb 18 16:54:40 2020 +0100 drm/bridge: analogix-anx6345: Avoid duplicate -supply suffix commit 6726ca1a2d531f5a6efc1f785b15606ce837c4dc upstream. of_get_regulator() will unconditionally add "-supply" to form the property name. This is documented in commit 69511a452e6dc ("map consumer regulator based on device tree"). Remove the suffix from the requests. Signed-off-by: Torsten Duwe Reviewed-by: Mark Brown Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20200218155440.BEFB968C65@verein.lst.de Signed-off-by: Greg Kroah-Hartman commit a8ab253bced6a3a6227f8aa7cfc2856292d0c203 Author: Matthew Wilcox (Oracle) Date: Fri Jan 31 05:07:55 2020 -0500 XArray: Fix xa_find_next for large multi-index entries [ Upstream commit bd40b17ca49d7d110adf456e647701ce74de2241 ] Coverity pointed out that xas_sibling() was shifting xa_offset without promoting it to an unsigned long first, so the shift could cause an overflow and we'd get the wrong answer. The fix is obvious, and the new test-case provokes UBSAN to report an error: runtime error: shift exponent 60 is too large for 32-bit type 'int' Fixes: 19c30f4dd092 ("XArray: Fix xa_find_after with multi-index entries") Reported-by: Bjorn Helgaas Reported-by: Kees Cook Signed-off-by: Matthew Wilcox (Oracle) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit dcee23e3dc68ad23bb4871e9740d45985d56c1da Author: Guenter Roeck Date: Tue Jan 28 14:14:57 2020 -0800 brcmfmac: abort and release host after error [ Upstream commit 863844ee3bd38219c88e82966d1df36a77716f3e ] With commit 216b44000ada ("brcmfmac: Fix use after free in brcmf_sdio_readframes()") applied, we see locking timeouts in brcmf_sdio_watchdog_thread(). brcmfmac: brcmf_escan_timeout: timer expired INFO: task brcmf_wdog/mmc1:621 blocked for more than 120 seconds. Not tainted 4.19.94-07984-g24ff99a0f713 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. brcmf_wdog/mmc1 D 0 621 2 0x00000000 last_sleep: 2440793077. last_runnable: 2440766827 [] (__schedule) from [] (schedule+0x98/0xc4) [] (schedule) from [] (__mmc_claim_host+0x154/0x274) [] (__mmc_claim_host) from [] (brcmf_sdio_watchdog_thread+0x1b0/0x1f8 [brcmfmac]) [] (brcmf_sdio_watchdog_thread [brcmfmac]) from [] (kthread+0x178/0x180) In addition to restarting or exiting the loop, it is also necessary to abort the command and to release the host. Fixes: 216b44000ada ("brcmfmac: Fix use after free in brcmf_sdio_readframes()") Cc: Dan Carpenter Cc: Matthias Kaehlcke Cc: Brian Norris Cc: Douglas Anderson Signed-off-by: Guenter Roeck Reviewed-by: Douglas Anderson Acked-by: franky.lin@broadcom.com Acked-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 62d2bdf96b3c0df3e22c57b1e1552e2f929181e7 Author: Daniel Jordan Date: Mon Feb 10 13:11:00 2020 -0500 padata: fix uninitialized return value in padata_replace() [ Upstream commit 41ccdbfd5427bbbf3ed58b16750113b38fad1780 ] According to Geert's report[0], kernel/padata.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]: => 539:2 Warning is seen only with older compilers on certain archs. The runtime effect is potentially returning garbage down the stack when padata's cpumasks are modified before any pcrypt requests have run. Simplest fix is to initialize err to the success value. [0] http://lkml.kernel.org/r/20200210135506.11536-1-geert@linux-m68k.org Reported-by: Geert Uytterhoeven Fixes: bbefa1dd6a6d ("crypto: pcrypt - Avoid deadlock by using per-instance padata queues") Signed-off-by: Daniel Jordan Cc: Herbert Xu Cc: Steffen Klassert Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c0ff187f26f3b890b4c63c4b399e716deeff8969 Author: Xin Long Date: Mon Mar 30 23:31:45 2020 +0800 udp: initialize is_flist with 0 in udp_gro_receive [ Upstream commit bde1b56f898ca8112912d7b36e55e1543b3be0cf ] Without NAPI_GRO_CB(skb)->is_flist initialized, when the dev doesn't support NETIF_F_GRO_FRAGLIST, is_flist can still be set and fraglist will be used in udp_gro_receive(). So fix it by initializing is_flist with 0 in udp_gro_receive. Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") Signed-off-by: Xin Long Acked-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cf16912ae93e615ae17f69e0ff36ed93990c467d Author: Florian Westphal Date: Mon Mar 30 18:51:29 2020 +0200 net: fix fraglist segmentation reference count leak [ Upstream commit cf673ed0e057a2dd68d930c6d7e30d53c70c5789 ] Xin Long says: On udp rx path udp_rcv_segment() may do segment where the frag skbs will get the header copied from the head skb in skb_segment_list() by calling __copy_skb_header(), which could overwrite the frag skbs' extensions by __skb_ext_copy() and cause a leak. This issue was found after loading esp_offload where a sec path ext is set in the skb. Fix this by discarding head state of the fraglist skb before replacing its contents. Fixes: 3a1296a38d0cf62 ("net: Support GRO/GSO fraglist chaining.") Cc: Steffen Klassert Reported-by: Xiumei Mu Tested-by: Xin Long Signed-off-by: Florian Westphal Acked-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 905a7f86bea541e5e46b082c70edbb5937d59cd0 Author: Codrin Ciubotariu Date: Tue Mar 31 12:39:35 2020 +0300 net: macb: Fix handling of fixed-link node [ Upstream commit 79540d133ed6f65a37dacb54b7a704cc8a24c52d ] fixed-link nodes are treated as PHY nodes by of_mdiobus_child_is_phy(). We must check if the interface is a fixed-link before looking up for PHY nodes. Fixes: 7897b071ac3b ("net: macb: convert to phylink") Tested-by: Cristian Birsan Signed-off-by: Codrin Ciubotariu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 85dca5f03c3a6b79a479d94176e49b2e7c9b460e Author: Qiujun Huang Date: Fri Mar 27 11:07:51 2020 +0800 sctp: fix refcount bug in sctp_wfree [ Upstream commit 5c3e82fe159622e46e91458c1a6509c321a62820 ] We should iterate over the datamsgs to move all chunks(skbs) to newsk. The following case cause the bug: for the trouble SKB, it was in outq->transmitted list sctp_outq_sack sctp_check_transmitted SKB was moved to outq->sacked list then throw away the sack queue SKB was deleted from outq->sacked (but it was held by datamsg at sctp_datamsg_to_asoc So, sctp_wfree was not called here) then migrate happened sctp_for_each_tx_datachunk( sctp_clear_owner_w); sctp_assoc_migrate(); sctp_for_each_tx_datachunk( sctp_set_owner_w); SKB was not in the outq, and was not changed to newsk finally __sctp_outq_teardown sctp_chunk_put (for another skb) sctp_datamsg_put __kfree_skb(msg->frag_list) sctp_wfree (for SKB) SKB->sk was still oldsk (skb->sk != asoc->base.sk). Reported-and-tested-by: syzbot+cea71eec5d6de256d54d@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5eb36f765c34175ed031c88a8d823d24b17ab40f Author: Marcelo Ricardo Leitner Date: Thu Mar 26 20:47:46 2020 -0300 sctp: fix possibly using a bad saddr with a given dst [ Upstream commit 582eea230536a6f104097dd46205822005d5fe3a ] Under certain circumstances, depending on the order of addresses on the interfaces, it could be that sctp_v[46]_get_dst() would return a dst with a mismatched struct flowi. For example, if when walking through the bind addresses and the first one is not a match, it saves the dst as a fallback (added in 410f03831c07), but not the flowi. Then if the next one is also not a match, the previous dst will be returned but with the flowi information for the 2nd address, which is wrong. The fix is to use a locally stored flowi that can be used for such attempts, and copy it to the parameter only in case it is a possible match, together with the corresponding dst entry. The patch updates IPv6 code mostly just to be in sync. Even though the issue is also present there, it fallback is not expected to work with IPv6. Fixes: 410f03831c07 ("sctp: add routing output fallback") Reported-by: Jin Meng Signed-off-by: Marcelo Ricardo Leitner Tested-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3ec530690aa4fe5fd1e7fa0f928a363a9ed35b05 Author: William Dauchy Date: Fri Mar 27 19:56:39 2020 +0100 net, ip_tunnel: fix interface lookup with no key [ Upstream commit 25629fdaff2ff509dd0b3f5ff93d70a75e79e0a1 ] when creating a new ipip interface with no local/remote configuration, the lookup is done with TUNNEL_NO_KEY flag, making it impossible to match the new interface (only possible match being fallback or metada case interface); e.g: `ip link add tunl1 type ipip dev eth0` To fix this case, adding a flag check before the key comparison so we permit to match an interface with no local/remote config; it also avoids breaking possible userland tools relying on TUNNEL_NO_KEY flag and uninitialised key. context being on my side, I'm creating an extra ipip interface attached to the physical one, and moving it to a dedicated namespace. Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Signed-off-by: William Dauchy Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1c66f3b28146f60a6a1e87f119e361c9d3e429de Author: Codrin Ciubotariu Date: Tue Mar 31 12:36:51 2020 +0300 net: dsa: ksz: Select KSZ protocol tag [ Upstream commit f772148eb757b0823fbfdc2fe592d5e06c7f19b0 ] KSZ protocol tag is needed by the KSZ DSA drivers. Fixes: 0b9f9dfbfab4 ("dsa: Allow tag drivers to be built as modules") Tested-by: Cristian Birsan Signed-off-by: Codrin Ciubotariu Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 861e27914e726bdbbe5bcc18820450b71a5a4603 Author: Qian Cai Date: Wed Mar 25 18:01:00 2020 -0400 ipv4: fix a RCU-list lock in fib_triestat_seq_show [ Upstream commit fbe4e0c1b298b4665ee6915266c9d6c5b934ef4a ] fib_triestat_seq_show() calls hlist_for_each_entry_rcu(tb, head, tb_hlist) without rcu_read_lock() will trigger a warning, net/ipv4/fib_trie.c:2579 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by proc01/115277: #0: c0000014507acf00 (&p->lock){+.+.}-{3:3}, at: seq_read+0x58/0x670 Call Trace: dump_stack+0xf4/0x164 (unreliable) lockdep_rcu_suspicious+0x140/0x164 fib_triestat_seq_show+0x750/0x880 seq_read+0x1a0/0x670 proc_reg_read+0x10c/0x1b0 __vfs_read+0x3c/0x70 vfs_read+0xac/0x170 ksys_read+0x7c/0x140 system_call+0x5c/0x68 Fix it by adding a pair of rcu_read_lock/unlock() and use cond_resched_rcu() to avoid the situation where walking of a large number of items may prevent scheduling for a long time. Signed-off-by: Qian Cai Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman