commit b3a99fd385fab59d0b8b4fdfb449c1e979accab8 Author: Greg Kroah-Hartman Date: Mon Jun 22 09:05:30 2020 +0200 Linux 4.19.129 commit 7e8c391e56d294ecea9abff1dd25a99b8af3576c Author: Adrian Hunter Date: Tue May 26 18:52:07 2020 +0300 perf symbols: Fix debuginfo search for Ubuntu commit 85afd35575a3c1a3a905722dde5ee70b49282e70 upstream. Reportedly, from 19.10 Ubuntu has begun mixing up the location of some debug symbol files, putting files expected to be in /usr/lib/debug/usr/lib into /usr/lib/debug/lib instead. Fix by adding another dso_binary_type. Example on Ubuntu 20.04 Before: $ perf record -e intel_pt//u uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.030 MB perf.data ] $ perf script --call-trace | head -5 uname 14003 [005] 15321.764958566: cbr: 42 freq: 4219 MHz (156%) uname 14003 [005] 15321.764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc4100 uname 14003 [005] 15321.764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc4df0 uname 14003 [005] 15321.764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc4e18 uname 14003 [005] 15321.764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) 7f1e71cc5128 After: $ perf script --call-trace | head -5 uname 14003 [005] 15321.764958566: cbr: 42 freq: 4219 MHz (156%) uname 14003 [005] 15321.764958566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _start uname 14003 [005] 15321.764961566: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start uname 14003 [005] 15321.764961900: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start uname 14003 [005] 15321.764963233: (/usr/lib/x86_64-linux-gnu/ld-2.31.so ) _dl_start Reported-by: Travis Downs Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20200526155207.9172-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit c7006692a86cead66bdcfb7e897d61750bf5c6c4 Author: Masami Hiramatsu Date: Thu Apr 23 20:01:13 2020 +0900 perf probe: Check address correctness by map instead of _etext commit 2ae5d0d7d8868df7c05c2013c0b9cddd4d40610e upstream. Since commit 03db8b583d1c ("perf tools: Fix maps__find_symbol_by_name()") introduced map address range check in maps__find_symbol_by_name(), we can not get "_etext" from kernel map because _etext is placed on the edge of the kernel .text section (= kernel map in perf.) To fix this issue, this checks the address correctness by map address range information (map->start and map->end) instead of using _etext address. This can cause an error if the target inlined function is embedded in both __init function and normal function. For exaample, request_resource() is a normal function but also embedded in __init reserve_setup(). In this case, the probe point in reserve_setup() must be skipped. However, without this fix, it failes to setup all probe points: # ./perf probe -v request_resource probe-definition(0): request_resource symbol:request_resource file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /usr/lib/debug/lib/modules/5.5.17-200.fc31.x86_64/vmlinux for symbols Open Debuginfo file: /usr/lib/debug/lib/modules/5.5.17-200.fc31.x86_64/vmlinux Try to find probe point from debuginfo. Matched function: request_resource [15e29ad] found inline addr: 0xffffffff82fbf892 Probe point found: reserve_setup+204 found inline addr: 0xffffffff810e9790 Probe point found: request_resource+0 Found 2 probe_trace_events. Opening /sys/kernel/debug/tracing//kprobe_events write=1 Opening /sys/kernel/debug/tracing//README write=0 Writing event: p:probe/request_resource _text+33290386 Failed to write event: Invalid argument Error: Failed to add events. Reason: Invalid argument (Code: -22) # With this fix, # ./perf probe request_resource reserve_setup is out of .text, skip it. Added new events: (null):(null) (on request_resource) probe:request_resource (on request_resource) You can now use it in all perf tools, such as: perf record -e probe:request_resource -aR sleep 1 # Fixes: 03db8b583d1c ("perf tools: Fix maps__find_symbol_by_name()") Reported-by: Arnaldo Carvalho de Melo Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/158763967332.30755.4922496724365529088.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 3a19dcd41fc91c1a8432c812d3a6221f67ddeb93 Author: Masami Hiramatsu Date: Thu Apr 23 20:01:04 2020 +0900 perf probe: Fix to check blacklist address correctly commit 80526491c2ca6abc028c0f0dbb0707a1f35fb18a upstream. Fix to check kprobe blacklist address correctly with relocated address by adjusting debuginfo address. Since the address in the debuginfo is same as objdump, it is different from relocated kernel address with KASLR. Thus, 'perf probe' always misses to catch the blacklisted addresses. Without this patch, 'perf probe' can not detect the blacklist addresses on a KASLR enabled kernel. # perf probe kprobe_dispatcher Failed to write event: Invalid argument Error: Failed to add events. # With this patch, it correctly shows the error message. # perf probe kprobe_dispatcher kprobe_dispatcher is blacklisted function, skip it. Probe point 'kprobe_dispatcher' not found. Error: Failed to add events. # Fixes: 9aaf5a5f479b ("perf probe: Check kprobes blacklist when adding new events") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/158763966411.30755.5882376357738273695.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 10846d824ecefedc6706ac53dbbc02ffc1f1f78c Author: Masami Hiramatsu Date: Thu Apr 23 20:01:22 2020 +0900 perf probe: Do not show the skipped events commit f41ebe9defacddeae96a872a33f0f22ced0bfcef upstream. When a probe point is expanded to several places (like inlined) and if some of them are skipped because of blacklisted or __init function, those trace_events has no event name. It must be skipped while showing results. Without this fix, you can see "(null):(null)" on the list, # ./perf probe request_resource reserve_setup is out of .text, skip it. Added new events: (null):(null) (on request_resource) probe:request_resource (on request_resource) You can now use it in all perf tools, such as: perf record -e probe:request_resource -aR sleep 1 # With this fix, it is ignored: # ./perf probe request_resource reserve_setup is out of .text, skip it. Added new events: probe:request_resource (on request_resource) You can now use it in all perf tools, such as: perf record -e probe:request_resource -aR sleep 1 # Fixes: 5a51fcd1f30c ("perf probe: Skip kernel symbols which is out of .text") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/158763968263.30755.12800484151476026340.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 783b437a4b22644af3777260c160b3913d594602 Author: H. Nikolaus Schaller Date: Sat May 23 19:32:54 2020 +0200 w1: omap-hdq: cleanup to add missing newline for some dev_dbg commit 5e02f3b31704e24537697bce54f8156bdb72b7a6 upstream. Otherwise it will corrupt the console log during debugging. Fixes: 7b5362a603a1 ("w1: omap_hdq: Fix some error/debug handling.") Cc: stable@vger.kernel.org Acked-by: Tony Lindgren Signed-off-by: H. Nikolaus Schaller Link: https://lore.kernel.org/r/cd0d55749a091214106575f6e1d363c6db56622f.1590255176.git.hns@goldelico.com Signed-off-by: Greg Kroah-Hartman commit 49f44baf4eeafe4491569bd751e5e92c4c0d35bc Author: Miquel Raynal Date: Tue May 19 15:00:13 2020 +0200 mtd: rawnand: pasemi: Fix the probe error path commit f51466901c07e6930435d30b02a21f0841174f61 upstream. nand_cleanup() is supposed to be called on error after a successful call to nand_scan() to free all NAND resources. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible, hence pointing it as the commit to fix for backporting purposes, even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-41-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 3c74d45debcec8def5651097f074e990ed8ac66d Author: Álvaro Fernández Rojas Date: Tue May 12 09:57:32 2020 +0200 mtd: rawnand: brcmnand: fix hamming oob layout commit 130bbde4809b011faf64f99dddc14b4b01f440c3 upstream. First 2 bytes are used in large-page nand. Fixes: ef5eeea6e911 ("mtd: nand: brcm: switch to mtd_ooblayout_ops") Cc: stable@vger.kernel.org Signed-off-by: Álvaro Fernández Rojas Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200512075733.745374-2-noltari@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8f2c1ab11e97f163bcd5dec8f9afba3ffeaddf50 Author: NeilBrown Date: Fri May 22 12:01:33 2020 +1000 sunrpc: clean up properly in gss_mech_unregister() commit 24c5efe41c29ee3e55bcf5a1c9f61ca8709622e8 upstream. gss_mech_register() calls svcauth_gss_register_pseudoflavor() for each flavour, but gss_mech_unregister() does not call auth_domain_put(). This is unbalanced and makes it impossible to reload the module. Change svcauth_gss_register_pseudoflavor() to return the registered auth_domain, and save it for later release. Cc: stable@vger.kernel.org (v2.6.12+) Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651 Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit c894f31a876ff7e93b3584691771c402887e7644 Author: NeilBrown Date: Fri May 22 12:01:33 2020 +1000 sunrpc: svcauth_gss_register_pseudoflavor must reject duplicate registrations. commit d47a5dc2888fd1b94adf1553068b8dad76cec96c upstream. There is no valid case for supporting duplicate pseudoflavor registrations. Currently the silent acceptance of such registrations is hiding a bug. The rpcsec_gss_krb5 module registers 2 flavours but does not unregister them, so if you load, unload, reload the module, it will happily continue to use the old registration which now has pointers to the memory were the module was originally loaded. This could lead to unexpected results. So disallow duplicate registrations. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651 Cc: stable@vger.kernel.org (v2.6.12+) Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 5ec83ff4886f05ee53712e64017df0c45ad1d200 Author: Masahiro Yamada Date: Sun May 31 17:47:06 2020 +0900 kbuild: force to build vmlinux if CONFIG_MODVERSION=y commit 4b50c8c4eaf06a825d1c005c0b1b4a8307087b83 upstream. This code does not work as stated in the comment. $(CONFIG_MODVERSIONS) is always empty because it is expanded before include/config/auto.conf is included. Hence, 'make modules' with CONFIG_MODVERSION=y cannot record the version CRCs. This has been broken since 2003, commit ("kbuild: Enable modules to be build using the "make dir/" syntax"). [1] [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=15c6240cdc44bbeef3c4797ec860f9765ef4f1a7 Cc: linux-stable # v2.5.71+ Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 2c5757aa0c5fd325900dae682742a2101aa88bcf Author: Michael Ellerman Date: Thu May 28 00:58:42 2020 +1000 powerpc/64s: Save FSCR to init_task.thread.fscr after feature init commit 912c0a7f2b5daa3cbb2bc10f303981e493de73bd upstream. At boot the FSCR is initialised via one of two paths. On most systems it's set to a hard coded value in __init_FSCR(). On newer skiboot systems we use the device tree CPU features binding, where firmware can tell Linux what bits to set in FSCR (and HFSCR). In both cases the value that's configured at boot is not propagated into the init_task.thread.fscr value prior to the initial fork of init (pid 1), which means the value is not used by any processes other than swapper (the idle task). For the __init_FSCR() case this is OK, because the value in init_task.thread.fscr is initialised to something sensible. However it does mean that the value set in __init_FSCR() is not used other than for swapper, which is odd and confusing. The bigger problem is for the device tree CPU features case it prevents firmware from setting (or clearing) FSCR bits for use by user space. This means all existing kernels can not have features enabled/disabled by firmware if those features require setting/clearing FSCR bits. We can handle both cases by saving the FSCR value into init_task.thread.fscr after we have initialised it at boot. This fixes the bug for device tree CPU features, and will allow us to simplify the initialisation for the __init_FSCR() case in a future patch. Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200527145843.2761782-3-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 0d1d7b9f5e76c43557e164d61011bd78ca6d8f29 Author: Michael Ellerman Date: Thu May 28 00:58:41 2020 +1000 powerpc/64s: Don't let DT CPU features set FSCR_DSCR commit 993e3d96fd08c3ebf7566e43be9b8cd622063e6d upstream. The device tree CPU features binding includes FSCR bit numbers which Linux is instructed to set by firmware. Whether that's a good idea or not, in the case of the DSCR the Linux implementation has a hard requirement that the FSCR_DSCR bit not be set by default. We use it to track when a process reads/writes to DSCR, so it must be clear to begin with. So if firmware tells us to set FSCR_DSCR we must ignore it. Currently this does not cause a bug in our DSCR handling because the value of FSCR that the device tree CPU features code establishes is only used by swapper. All other tasks use the value hard coded in init_task.thread.fscr. However we'd like to fix that in a future commit, at which point this will become necessary. Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200527145843.2761782-2-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit e37a469827c378afd13dae1ed3a3221ed9ff976b Author: Michael Ellerman Date: Thu Apr 23 16:00:38 2020 +1000 drivers/macintosh: Fix memleak in windfarm_pm112 driver commit 93900337b9ac2f4eca427eff6d187be2dc3b5551 upstream. create_cpu_loop() calls smu_sat_get_sdb_partition() which does kmalloc() and returns the allocated buffer. In fact it's called twice, and neither buffer is freed. This results in a memory leak as reported by Erhard: unreferenced object 0xc00000047081f840 (size 32): comm "kwindfarm", pid 203, jiffies 4294880630 (age 5552.877s) hex dump (first 32 bytes): c8 06 02 7f ff 02 ff 01 fb bf 00 41 00 20 00 00 ...........A. .. 00 07 89 37 00 a0 00 00 00 00 00 00 00 00 00 00 ...7............ backtrace: [<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat] [<000000003010fcb7>] .pm112_wf_notify+0x104c/0x13bc [windfarm_pm112] [<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180 [<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90 [<00000000131d8149>] .wf_thread_func+0x114/0x1a0 [<000000000d54838d>] .kthread+0x13c/0x190 [<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64 unreferenced object 0xc0000004737089f0 (size 16): comm "kwindfarm", pid 203, jiffies 4294880879 (age 5552.050s) hex dump (first 16 bytes): c4 04 01 7f 22 11 e0 e6 ff 55 7b 12 ec 11 00 00 ...."....U{..... backtrace: [<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat] [<00000000b94ef7e1>] .pm112_wf_notify+0x1294/0x13bc [windfarm_pm112] [<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180 [<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90 [<00000000131d8149>] .wf_thread_func+0x114/0x1a0 [<000000000d54838d>] .kthread+0x13c/0x190 [<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64 Fix it by rearranging the logic so we deal with each buffer separately, which then makes it easy to free the buffer once we're done with it. Fixes: ac171c46667c ("[PATCH] powerpc: Thermal control for dual core G5s") Cc: stable@vger.kernel.org # v2.6.16+ Reported-by: Erhard F. Signed-off-by: Michael Ellerman Tested-by: Erhard F. Link: https://lore.kernel.org/r/20200423060038.3308530-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit a607e2e29c7502501991a8807087a267cc42e4c3 Author: Jonathan Bakker Date: Fri May 1 16:50:05 2020 -0700 ARM: dts: s5pv210: Set keep-power-in-suspend for SDHCI1 on Aries commit 869d42e6eba821905e1a0950623aadafe1a6e6d3 upstream. SDHCI1 is connected to a BCM4329 WiFi/BT chip which requires power to be kept over suspend. As the surrounding hardware supports this, mark it as such. This fixes WiFi after a suspend/resume cycle. Fixes: 170642468a51 ("ARM: dts: s5pv210: Add initial DTS for Samsung Aries based phones") Cc: Signed-off-by: Jonathan Bakker Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 203c1c4c9a32033bb516e864964513e1ae129b85 Author: Ludovic Desroches Date: Thu Apr 2 00:19:47 2020 +0200 ARM: dts: at91: sama5d2_ptc_ek: fix vbus pin commit baa998aecb75c04d62be0a4ab6b724af6d73a0f9 upstream. The gpio property for the vbus pin doesn't match the pinctrl and is not correct. Signed-off-by: Ludovic Desroches Fixes: 42ed535595ec "ARM: dts: at91: introduce the sama5d2 ptc ek board" Cc: stable@vger.kernel.org # 4.19 and later Link: https://lore.kernel.org/r/20200401221947.41502-1-ludovic.desroches@microchip.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 3e2a98fc2f08e46936c4fe97201740118271c71f Author: Marek Szyprowski Date: Thu Mar 26 15:20:37 2020 +0100 ARM: dts: exynos: Fix GPIO polarity for thr GalaxyS3 CM36651 sensor's bus commit 8807d356bfea92b0a8f04ce421800ed83400cd22 upstream. GPIO lines for the CM36651 sensor I2C bus use the normal not the inverted polarity. This bug has been there since adding the CM36651 sensor by commit 85cb4e0bd229 ("ARM: dts: add cm36651 light/proximity sensor node for exynos4412-trats2"), but went unnoticed because the "i2c-gpio" driver ignored the GPIO polarity specified in the device-tree. The recent conversion of "i2c-gpio" driver to the new, descriptor based GPIO API, automatically made it the DT-specified polarity aware, what broke the CM36651 sensor operation. Fixes: 85cb4e0bd229 ("ARM: dts: add cm36651 light/proximity sensor node for exynos4412-trats2") CC: stable@vger.kernel.org # 4.16+ Signed-off-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 10f0446f737efd41ea3d8479855a60b4ba222b9a Author: Dmitry Osipenko Date: Fri Mar 13 12:01:04 2020 +0300 ARM: tegra: Correct PL310 Auxiliary Control Register initialization commit 35509737c8f958944e059d501255a0bf18361ba0 upstream. The PL310 Auxiliary Control Register shouldn't have the "Full line of zero" optimization bit being set before L2 cache is enabled. The L2X0 driver takes care of enabling the optimization by itself. This patch fixes a noisy error message on Tegra20 and Tegra30 telling that cache optimization is erroneously enabled without enabling it for the CPU: L2C-310: enabling full line of zeros but not enabled in Cortex-A9 Cc: Signed-off-by: Dmitry Osipenko Tested-by: Nicolas Chauvet Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 262c6e883e057ea186186f80f2e6e3fd614f7bd0 Author: Douglas Anderson Date: Mon May 4 10:50:17 2020 -0700 kernel/cpu_pm: Fix uninitted local in cpu_pm commit b5945214b76a1f22929481724ffd448000ede914 upstream. cpu_pm_notify() is basically a wrapper of notifier_call_chain(). notifier_call_chain() doesn't initialize *nr_calls to 0 before it starts incrementing it--presumably it's up to the callers to do this. Unfortunately the callers of cpu_pm_notify() don't init *nr_calls. This potentially means you could get too many or two few calls to CPU_PM_ENTER_FAILED or CPU_CLUSTER_PM_ENTER_FAILED depending on the luck of the stack. Let's fix this. Fixes: ab10023e0088 ("cpu_pm: Add cpu power management notifiers") Cc: stable@vger.kernel.org Cc: Rafael J. Wysocki Reviewed-by: Stephen Boyd Reviewed-by: Greg Kroah-Hartman Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20200504104917.v6.3.I2d44fc0053d019f239527a4e5829416714b7e299@changeid Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit dd7a73802876f86845ef679b118d8b2de0c27330 Author: Mikulas Patocka Date: Tue May 26 10:47:49 2020 -0400 alpha: fix memory barriers so that they conform to the specification commit 54505a1e2083fc54cbe8779b97479f969cd30a00 upstream. The commits cd0e00c10672 and 92d7223a7423 broke boot on the Alpha Avanti platform. The patches move memory barriers after a write before the write. The result is that if there's iowrite followed by ioread, there is no barrier between them. The Alpha architecture allows reordering of the accesses to the I/O space, and the missing barrier between write and read causes hang with serial port and real time clock. This patch makes barriers confiorm to the specification. 1. We add mb() before readX_relaxed and writeX_relaxed - memory-barriers.txt claims that these functions must be ordered w.r.t. each other. Alpha doesn't order them, so we need an explicit barrier. 2. We add mb() before reads from the I/O space - so that if there's a write followed by a read, there should be a barrier between them. Signed-off-by: Mikulas Patocka Fixes: cd0e00c10672 ("alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering") Fixes: 92d7223a7423 ("alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering #2") Cc: stable@vger.kernel.org # v4.17+ Acked-by: Ivan Kokshaysky Reviewed-by: Maciej W. Rozycki Signed-off-by: Matt Turner Signed-off-by: Greg Kroah-Hartman commit 4c386e28943721d8c0659e846302c45b78414a3b Author: Eric Biggers Date: Thu Jun 4 12:01:26 2020 -0700 dm crypt: avoid truncating the logical block size commit 64611a15ca9da91ff532982429c44686f4593b5f upstream. queue_limits::logical_block_size got changed from unsigned short to unsigned int, but it was forgotten to update crypt_io_hints() to use the new type. Fix it. Fixes: ad6bf88a6c19 ("block: fix an integer overflow in logical block size") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 81130a47b26e70e23b9288c72ba2705ee4ec7554 Author: Al Viro Date: Sun May 17 15:37:50 2020 -0400 sparc64: fix misuses of access_process_vm() in genregs32_[sg]et() commit 142cd25293f6a7ecbdff4fb0af17de6438d46433 upstream. We do need access_process_vm() to access the target's reg_window. However, access to caller's memory (storing the result in genregs32_get(), fetching the new values in case of genregs32_set()) should be done by normal uaccess primitives. Fixes: ad4f95764040 ([SPARC64]: Fix user accesses in regset code.) Cc: stable@kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 3721d5dcac2a4d89b200f93b235252cc896e9d6d Author: Al Viro Date: Sun May 17 12:20:40 2020 -0400 sparc32: fix register window handling in genregs32_[gs]et() commit cf51e129b96847f969bfb8af1ee1516a01a70b39 upstream. It needs access_process_vm() if the traced process does not share mm with the caller. Solution is similar to what sparc64 does. Note that genregs32_set() is only ever called with pos being 0 or 32 * sizeof(u32) (the latter - as part of PTRACE_SETREGS handling). Cc: stable@kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 621dbec36ba1dacbc17a5b067ed6531e52ad57e2 Author: Wei Yongjun Date: Thu May 7 09:42:52 2020 +0000 gnss: sirf: fix error return code in sirf_probe() commit 43d7ce70ae43dd8523754b17f567417e0e75dbce upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. This avoids a use-after-free in case the driver is later unbound. Fixes: d2efbbd18b1e ("gnss: add driver for sirfstar-based receivers") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun [ johan: amend commit message; mention potential use-after-free ] Cc: stable # 4.19 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit cb345e7f3eaabbcaa915cafe0952a1d1afbdb07f Author: Jonathan Bakker Date: Sat Apr 25 16:10:46 2020 -0700 pinctrl: samsung: Save/restore eint_mask over suspend for EINT_TYPE GPIOs commit f354157a7d184db430c1a564c506434e33b1bec5 upstream. Currently, for EINT_TYPE GPIOs, the CON and FLTCON registers are saved and restored over a suspend/resume cycle. However, the EINT_MASK registers are not. On S5PV210 at the very least, these registers are not retained over suspend, leading to the interrupts remaining masked upon resume and therefore no interrupts being triggered for the device. There should be no effect on any SoCs that do retain these registers as theoretically we would just be re-writing what was already there. Fixes: 7ccbc60cd9c2 ("pinctrl: exynos: Handle suspend/resume of GPIO EINT registers") Cc: Signed-off-by: Jonathan Bakker Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 28e2860d5ac3802d77a9f34f3aa6106e0397e8ef Author: Jonathan Bakker Date: Sat Apr 4 10:08:49 2020 -0700 pinctrl: samsung: Correct setting of eint wakeup mask on s5pv210 commit b577a279914085c6b657c33e9f39ef56d96a3302 upstream. Commit a8be2af0218c ("pinctrl: samsung: Write external wakeup interrupt mask") started writing the eint wakeup mask from the pinctrl driver. Unfortunately, it made the assumption that the private retention data was always a regmap while in the case of s5pv210 it is a raw pointer to the clock base (as the eint wakeup mask not in the PMU as with newer Exynos platforms). Fixes: a8be2af0218c ("pinctrl: samsung: Write external wakeup interrupt mask") Cc: Signed-off-by: Jonathan Bakker Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 162dfa38bb42ee7c2023e2ca433ec9cf32fc5309 Author: Anders Roxell Date: Wed May 27 13:26:04 2020 +0200 power: vexpress: add suppress_bind_attrs to true commit 73174acc9c75960af2daa7dcbdb9781fc0d135cb upstream. Make sure that the POWER_RESET_VEXPRESS driver won't have bind/unbind attributes available via the sysfs, so lets be explicit here and use ".suppress_bind_attrs = true" to prevent userspace from doing something silly. Link: https://lore.kernel.org/r/20200527112608.3886105-2-anders.roxell@linaro.org Cc: stable@vger.kernel.org Signed-off-by: Anders Roxell Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 9fb0eb3d31c06d8dd550f0452979c3c3e9787759 Author: Kai-Heng Feng Date: Tue May 5 12:01:54 2020 +0800 igb: Report speed and duplex as unknown when device is runtime suspended commit 165ae7a8feb53dc47fb041357e4b253bfc927cf9 upstream. igb device gets runtime suspended when there's no link partner. We can't get correct speed under that state: $ cat /sys/class/net/enp3s0/speed 1000 In addition to that, an error can also be spotted in dmesg: [ 385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost Since device can only be runtime suspended when there's no link partner, we can skip reading register and let the following logic set speed and duplex with correct status. The more generic approach will be wrap get_link_ksettings() with begin() and complete() callbacks. However, for this particular issue, begin() calls igb_runtime_resume() , which tries to rtnl_lock() while the lock is already hold by upper ethtool layer. So let's take this approach until the igb_runtime_resume() no longer needs to hold rtnl_lock. CC: stable Suggested-by: Alexander Duyck Signed-off-by: Kai-Heng Feng Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit d40e4505834c55d7ae2e28ff959f6ce053d54a35 Author: Tomi Valkeinen Date: Wed Mar 25 13:20:00 2020 +0100 media: ov5640: fix use of destroyed mutex commit bfcba38d95a0aed146a958a84a2177af1459eddc upstream. v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting in the use of the destroyed mutex. Fix this by calling moving the mutex_destroy() to the end of the cleanup sequence, as there's no need to destroy the mutex as early as possible. Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart Cc: stable@vger.kernel.org # v4.14+ Reviewed-by: Benoit Parrot Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit fdf30818f43c3fe0990020dcc287caa89ccc3152 Author: Larry Finger Date: Tue May 26 10:59:09 2020 -0500 b43_legacy: Fix connection problem with WPA3 commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream. Since the driver was first introduced into the kernel, it has only handled the ciphers associated with WEP, WPA, and WPA2. It fails with WPA3 even though mac80211 can handle those additional ciphers in software, b43legacy did not report that it could handle them. By setting MFP_CAPABLE using ieee80211_set_hw(), the problem is fixed. With this change, b43legacy will handle the ciphers it knows in hardware, and let mac80211 handle the others in software. It is not necessary to use the module parameter NOHWCRYPT to turn hardware encryption off. Although this change essentially eliminates that module parameter, I am choosing to keep it for cases where the hardware is broken, and software encryption is required for all ciphers. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200526155909.5807-3-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman commit f2bde7856b3fc0481150905d109e437f6fe45b7f Author: Larry Finger Date: Tue May 26 10:59:08 2020 -0500 b43: Fix connection problem with WPA3 commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream. Since the driver was first introduced into the kernel, it has only handled the ciphers associated with WEP, WPA, and WPA2. It fails with WPA3 even though mac80211 can handle those additional ciphers in software, b43 did not report that it could handle them. By setting MFP_CAPABLE using ieee80211_set_hw(), the problem is fixed. With this change, b43 will handle the ciphers it knows in hardware, and let mac80211 handle the others in software. It is not necessary to use the module parameter NOHWCRYPT to turn hardware encryption off. Although this change essentially eliminates that module parameter, I am choosing to keep it for cases where the hardware is broken, and software encryption is required for all ciphers. Reported-and-tested-by: Rui Salvaterra Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200526155909.5807-2-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman commit 20437a7c0ff268109bfc2bf2d4c0f1dcc0216326 Author: Larry Finger Date: Tue Apr 7 14:00:43 2020 -0500 b43legacy: Fix case where channel status is corrupted commit ec4d3e3a054578de34cd0b587ab8a1ac36f629d9 upstream. This patch fixes commit 75388acd0cd8 ("add mac80211-based driver for legacy BCM43xx devices") In https://bugzilla.kernel.org/show_bug.cgi?id=207093, a defect in b43legacy is reported. Upon testing, thus problem exists on PPC and X86 platforms, is present in the oldest kernel tested (3.2), and has been present in the driver since it was first added to the kernel. The problem is a corrupted channel status received from the device. Both the internal card in a PowerBook G4 and the PCMCIA version (Broadcom BCM4306 with PCI ID 14e4:4320) have the problem. Only Rev, 2 (revision 4 of the 802.11 core) of the chip has been tested. No other devices using b43legacy are available for testing. Various sources of the problem were considered. Buffer overrun and other sources of corruption within the driver were rejected because the faulty channel status is always the same, not a random value. It was concluded that the faulty data is coming from the device, probably due to a firmware bug. As that source is not available, the driver must take appropriate action to recover. At present, the driver reports the error, and them continues to process the bad packet. This is believed that to be a mistake, and the correct action is to drop the correpted packet. Fixes: 75388acd0cd8 ("add mac80211-based driver for legacy BCM43xx devices") Cc: Stable Signed-off-by: Larry Finger Reported-and-tested by: F. Erhard Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200407190043.1686-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman commit 207dffe6bc91bce125d578b8d9a09e2ec45edc79 Author: Michał Mirosław Date: Thu Apr 2 14:55:20 2020 +0200 Bluetooth: hci_bcm: fix freeing not-requested IRQ commit 81bd5d0c62437c02caac6b3f942fcda874063cb0 upstream. When BT module can't be initialized, but it has an IRQ, unloading the driver WARNs when trying to free not-yet-requested IRQ. Fix it by noting whether the IRQ was requested. WARNING: CPU: 2 PID: 214 at kernel/irq/devres.c:144 devm_free_irq+0x49/0x4ca [...] WARNING: CPU: 2 PID: 214 at kernel/irq/manage.c:1746 __free_irq+0x8b/0x27c Trying to free already-free IRQ 264 Modules linked in: hci_uart(-) btbcm bluetooth ecdh_generic ecc libaes CPU: 2 PID: 214 Comm: rmmod Tainted: G W 5.6.1mq-00044-ga5f9ea098318-dirty #928 [...] [] (devm_free_irq) from [] (bcm_close+0x97/0x118 [hci_uart]) [] (bcm_close [hci_uart]) from [] (hci_uart_unregister_device+0x33/0x3c [hci_uart]) [] (hci_uart_unregister_device [hci_uart]) from [] (serdev_drv_remove+0x13/0x20) [] (serdev_drv_remove) from [] (device_release_driver_internal+0x97/0x118) [] (device_release_driver_internal) from [] (driver_detach+0x2f/0x58) [] (driver_detach) from [] (bus_remove_driver+0x41/0x94) [] (bus_remove_driver) from [] (bcm_deinit+0x1b/0x740 [hci_uart]) [] (bcm_deinit [hci_uart]) from [] (hci_uart_exit+0x13/0x30 [hci_uart]) [] (hci_uart_exit [hci_uart]) from [] (sys_delete_module+0x109/0x1d0) [] (sys_delete_module) from [] (ret_fast_syscall+0x1/0x5a) [...] Cc: stable@vger.kernel.org Fixes: 6cc4396c8829 ("Bluetooth: hci_bcm: Add wake-up capability") Signed-off-by: Michał Mirosław Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 95b58c96a28e6174661dcd5bc543618973fc43d3 Author: Chuhong Yuan Date: Tue Dec 10 04:15:48 2019 +0100 media: go7007: fix a miss of snd_card_free commit 9453264ef58638ce8976121ac44c07a3ef375983 upstream. go7007_snd_init() misses a snd_card_free() in an error path. Add the missed call to fix it. Signed-off-by: Chuhong Yuan Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab [Salvatore Bonaccorso: Adjust context for backport to versions which do not contain c0decac19da3 ("media: use strscpy() instead of strlcpy()") and ba78170ef153 ("media: go7007: Fix misuse of strscpy")] Signed-off-by: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 64f0e8479fa64367eb7131a02bb8d7aa168eeacb Author: Christian Lamparter Date: Tue May 5 10:42:09 2020 +0300 carl9170: remove P2P_GO support commit b14fba7ebd04082f7767a11daea7f12f3593de22 upstream. This patch follows up on a bug-report by Frank Schäfer that discovered P2P GO wasn't working with wpa_supplicant. This patch removes part of the broken P2P GO support but keeps the vif switchover code in place. Cc: Link: Reported-by: Frank Schäfer Signed-off-by: Christian Lamparter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200425092811.9494-1-chunkeey@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2add83624d2b331991a3ec64287b3964c06b4aba Author: Punit Agrawal Date: Fri May 15 13:31:27 2020 +0900 e1000e: Relax condition to trigger reset for ME workaround commit d601afcae2febc49665008e9a79e701248d56c50 upstream. It's an error if the value of the RX/TX tail descriptor does not match what was written. The error condition is true regardless the duration of the interference from ME. But the driver only performs the reset if E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have transpired. The extra condition can lead to inconsistency between the state of hardware as expected by the driver. Fix this by dropping the check for number of delay iterations. While at it, also make __ew32_prepare() static as it's not used anywhere else. CC: stable Signed-off-by: Punit Agrawal Reviewed-by: Alexander Duyck Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit b3f9b505138269a1ddeaedc03c2f612e48ea6786 Author: Kai-Heng Feng Date: Thu May 7 22:21:07 2020 +0800 e1000e: Disable TSO for buffer overrun workaround commit f29801030ac67bf98b7a65d3aea67b30769d4f7c upstream. Commit b10effb92e27 ("e1000e: fix buffer overrun while the I219 is processing DMA transactions") imposes roughly 30% performance penalty. The commit log states that "Disabling TSO eliminates performance loss for TCP traffic without a noticeable impact on CPU performance", so let's disable TSO by default to regain the loss. CC: stable Fixes: b10effb92e27 ("e1000e: fix buffer overrun while the I219 is processing DMA transactions") BugLink: https://bugs.launchpad.net/bugs/1802691 Signed-off-by: Kai-Heng Feng Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit acda91ee93382416e97fb64684701daf19777a0b Author: Ashok Raj Date: Fri Mar 27 14:16:15 2020 -0700 PCI: Program MPS for RCiEP devices commit aa0ce96d72dd2e1b0dfd0fb868f82876e7790878 upstream. Root Complex Integrated Endpoints (RCiEPs) do not have an upstream bridge, so pci_configure_mps() previously ignored them, which may result in reduced performance. Instead, program the Max_Payload_Size of RCiEPs to the maximum supported value (unless it is limited for the PCIE_BUS_PEER2PEER case). This also affects the subsequent programming of Max_Read_Request_Size because Linux programs MRRS based on the MPS value. Fixes: 9dae3a97297f ("PCI: Move MPS configuration check to pci_configure_device()") Link: https://lore.kernel.org/r/1585343775-4019-1-git-send-email-ashok.raj@intel.com Tested-by: Dave Jiang Signed-off-by: Ashok Raj Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fcb067cb457e2326c6d759e346f5f5dfef351d50 Author: Roberto Sassu Date: Wed Jun 3 17:08:21 2020 +0200 ima: Call ima_calc_boot_aggregate() in ima_eventdigest_init() [ Upstream commit 6cc7c266e5b47d3cd2b5bb7fd3aac4e6bb2dd1d2 ] If the template field 'd' is chosen and the digest to be added to the measurement entry was not calculated with SHA1 or MD5, it is recalculated with SHA1, by using the passed file descriptor. However, this cannot be done for boot_aggregate, because there is no file descriptor. This patch adds a call to ima_calc_boot_aggregate() in ima_eventdigest_init(), so that the digest can be recalculated also for the boot_aggregate entry. Cc: stable@vger.kernel.org # 3.13.x Fixes: 3ce1217d6cd5d ("ima: define template fields library and new helpers") Reported-by: Takashi Iwai Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 789555b22ba2e62fd197a17be075ec8314d0c0b2 Author: Filipe Manana Date: Wed May 27 11:15:53 2020 +0100 btrfs: fix wrong file range cleanup after an error filling dealloc range [ Upstream commit e2c8e92d1140754073ad3799eb6620c76bab2078 ] If an error happens while running dellaloc in COW mode for a range, we can end up calling extent_clear_unlock_delalloc() for a range that goes beyond our range's end offset by 1 byte, which affects 1 extra page. This results in clearing bits and doing page operations (such as a page unlock) outside our target range. Fix that by calling extent_clear_unlock_delalloc() with an inclusive end offset, instead of an exclusive end offset, at cow_file_range(). Fixes: a315e68f6e8b30 ("Btrfs: fix invalid attempt to free reserved space on failure to cow range") CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 74bee8344b7defb5dd41de37290df51bc9e12f5e Author: Omar Sandoval Date: Thu Apr 16 14:46:12 2020 -0700 btrfs: fix error handling when submitting direct I/O bio [ Upstream commit 6d3113a193e3385c72240096fe397618ecab6e43 ] In btrfs_submit_direct_hook(), if a direct I/O write doesn't span a RAID stripe or chunk, we submit orig_bio without cloning it. In this case, we don't increment pending_bios. Then, if btrfs_submit_dio_bio() fails, we decrement pending_bios to -1, and we never complete orig_bio. Fix it by initializing pending_bios to 1 instead of incrementing later. Fixing this exposes another bug: we put orig_bio prematurely and then put it again from end_io. Fix it by not putting orig_bio. After this change, pending_bios is really more of a reference count, but I'll leave that cleanup separate to keep the fix small. Fixes: e65e15355429 ("btrfs: fix panic caused by direct IO") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Nikolay Borisov Reviewed-by: Josef Bacik Reviewed-by: Johannes Thumshirn Signed-off-by: Omar Sandoval Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 3bd1e2596ba3c97cb183380284566ea52716ae8a Author: Abhishek Sahu Date: Thu Jun 6 14:52:24 2019 +0530 PCI: Generalize multi-function power dependency device links [ Upstream commit a17beb1a0882a544523dcb5d0da4801272dfd43a ] Although not allowed by the PCI specs, some multi-function devices have power dependencies between the functions. For example, function 1 may not work unless function 0 is in the D0 power state. The existing quirk_gpu_hda() adds a device link to express this dependency for GPU and HDA devices, but it really is not specific to those device types. Generalize it and rename it to pci_create_device_link() so we can create dependencies between any "consumer" and "producer" functions of a multi-function device, where the consumer is only functional if the producer is in D0. This reorganization should not affect any functionality. Link: https://lore.kernel.org/lkml/20190606092225.17960-2-abhsahu@nvidia.com Signed-off-by: Abhishek Sahu [bhelgaas: commit log, reword diagnostic] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit ee527f4e11a631ba4230bbcc5ec1493c8de2593d Author: Bjorn Helgaas Date: Fri Sep 6 18:36:06 2019 -0500 PCI: Unify ACS quirk desired vs provided checking [ Upstream commit 7cf2cba43f15c74bac46dc5f0326805d25ef514d ] Most of the ACS quirks have a similar pattern of: acs_flags &= ~( ); return acs_flags ? 0 : 1; Pull this out into a helper function to simplify the quirks slightly. The helper function is also a convenient place for comments about what the list of ACS controls means. No functional change intended. Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Reviewed-by: Alex Williamson Signed-off-by: Sasha Levin commit 7cf431ab8338cac68a047ecb999d7bac70ee0fb8 Author: Bjorn Helgaas Date: Thu Sep 5 17:54:42 2019 -0500 PCI: Make ACS quirk implementations more uniform [ Upstream commit c8de8ed2dcaac82e5d76d467dc0b02e0ee79809b ] The ACS quirks differ in needless ways, which makes them look more different than they really are. Reorder the ACS flags in order of definitions in the spec: PCI_ACS_SV Source Validation PCI_ACS_TB Translation Blocking PCI_ACS_RR P2P Request Redirect PCI_ACS_CR P2P Completion Redirect PCI_ACS_UF Upstream Forwarding PCI_ACS_EC P2P Egress Control PCI_ACS_DT Direct Translated P2P (PCIe r5.0, sec 7.7.8.2) and use similar code structure in all. No functional change intended. Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Reviewed-by: Alex Williamson Signed-off-by: Sasha Levin commit 94e876782d21078ced14090e0ab2a2831e771589 Author: Kai-Heng Feng Date: Fri May 8 14:53:40 2020 +0800 serial: 8250_pci: Move Pericom IDs to pci_ids.h [ Upstream commit 62a7f3009a460001eb46984395280dd900bc4ef4 ] Move the IDs to pci_ids.h so it can be used by next patch. Link: https://lore.kernel.org/r/20200508065343.32751-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Acked-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 608c86123be655555796bf5997610d63fe35e752 Author: Tiezhu Yang Date: Tue Mar 10 20:50:07 2020 +0800 PCI: Add Loongson vendor ID [ Upstream commit 9acb9fe18d863aacc99948963f8d5d447dc311be ] Add the Loongson vendor ID to pci_ids.h to be used by the controller driver in the future. The Loongson vendor ID can be found at the following link: https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/tree/pci.ids Signed-off-by: Tiezhu Yang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7810f97f0f67b4e8398aaad21f01537d6f6ae12c Author: Yazen Ghannam Date: Fri Jan 10 01:56:49 2020 +0000 x86/amd_nb: Add Family 19h PCI IDs [ Upstream commit b3f79ae45904ae987a7c06a9e8d6084d7b73e67f ] Add the new PCI Device 18h IDs for AMD Family 19h systems. Note that Family 19h systems will not have a new PCI root device ID. Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200110015651.14887-4-Yazen.Ghannam@amd.com Signed-off-by: Sasha Levin commit c34013a57aa3ef6de4540105087dc065730061ec Author: Jon Derrick Date: Tue Nov 12 05:47:53 2019 -0700 PCI: vmd: Add device id for VMD device 8086:9A0B [ Upstream commit ec11e5c213cc20cac5e8310728b06793448b9f6d ] This patch adds support for this VMD device which supports the bus restriction mode. Signed-off-by: Jon Derrick Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit e5bd53ed0c266669e0f41499b2f6d6d290d2daa0 Author: Jonathan Chocron Date: Thu Sep 12 16:00:39 2019 +0300 PCI: Add Amazon's Annapurna Labs vendor ID [ Upstream commit 4a36a60c34f42f75e8b4f8cd24fcfade26111334 ] Add Amazon's Annapurna Labs vendor ID to pci_ids.h. Signed-off-by: Jonathan Chocron Signed-off-by: Lorenzo Pieralisi Reviewed-by: Andrew Murray Acked-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 18b48b760e035b06c8b4e0d90906aab9bc994839 Author: Ben Chuang Date: Tue Aug 27 08:33:09 2019 +0800 PCI: Add Genesys Logic, Inc. Vendor ID [ Upstream commit 4460d68f0b2f9092273531fbc65613e1855c2e07 ] Add the Genesys Logic, Inc. vendor ID to pci_ids.h. Signed-off-by: Ben Chuang Co-developed-by: Michael K Johnson Signed-off-by: Michael K Johnson Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9f32cadf10d55b2db8fdf279abe8c8638ffbebda Author: Tim Blechmann Date: Fri Sep 6 16:21:19 2019 +0800 ALSA: lx6464es - add support for LX6464ESe pci express variant [ Upstream commit 789492f0c86505e63369907bcb1afdf52dec9366 ] The pci express variant of the digigram lx6464es card has a different device ID, but works without changes to the driver. Thanks to Nikolas Slottke for reporting and testing. Signed-off-by: Tim Blechmann Link: https://lore.kernel.org/r/20190906082119.40971-1-tim@klingt.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c89c3a5a02e7ce776881f92a8787282d10db843b Author: Marcel Bocu Date: Mon Jul 22 20:45:10 2019 +0300 x86/amd_nb: Add PCI device IDs for family 17h, model 70h [ Upstream commit af4e1c5eca95bed1192d8dc45c8ed63aea2209e8 ] The AMD Ryzen gen 3 processors came with a different PCI IDs for the function 3 & 4 which are used to access the SMN interface. The root PCI address however remained at the same address as the model 30h. Adding the F3/F4 PCI IDs respectively to the misc and link ids appear to be sufficient for k10temp, so let's add them and follow up on the patch if other functions need more tweaking. Vicki Pfau sent an identical patch after I checked that no-one had written this patch. I would have been happy about dropping my patch but unlike for his patch series, I had already Cc:ed the x86 people and they already reviewed the changes. Since Vicki has not answered to any email after his initial series, let's assume she is on vacation and let's avoid duplication of reviews from the maintainers and merge my series. To acknowledge Vicki's anteriority, I added her S-o-b to the patch. v2, suggested by Guenter Roeck and Brian Woods: - rename from 71h to 70h Signed-off-by: Vicki Pfau Signed-off-by: Marcel Bocu Tested-by: Marcel Bocu Acked-by: Thomas Gleixner Acked-by: Brian Woods Acked-by: Bjorn Helgaas # pci_ids.h Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: "Woods, Brian" Cc: Clemens Ladisch Cc: Jean Delvare Cc: Guenter Roeck Cc: linux-hwmon@vger.kernel.org Link: https://lore.kernel.org/r/20190722174510.2179-1-marcel.p.bocu@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 4183021a300962addd16561b3c3c605673acc276 Author: Jianjun Wang Date: Fri Jun 28 15:34:25 2019 +0800 PCI: mediatek: Add controller support for MT7629 [ Upstream commit 0cccd42e6193e168cbecc271dae464e4a53fd7b3 ] MT7629 is an ARM platform SoC which has the same PCIe IP as MT7622. The HW default value of its PCI host controller Device ID is invalid, fix it to match the hardware implementation. Signed-off-by: Jianjun Wang [lorenzo.pieralisi@arm.com: commit log/minor spelling update] Signed-off-by: Lorenzo Pieralisi Reviewed-by: Andrew Murray Acked-by: Ryder Lee Signed-off-by: Sasha Levin commit a33436f47281c8340cd93238de00ed13c7fde594 Author: Lukas Wunner Date: Mon Jul 8 13:17:44 2019 +0800 PCI: Enable NVIDIA HDA controllers [ Upstream commit b516ea586d717472178e6ef1c152e85608b0ce32 ] Many NVIDIA GPUs can be configured as either a single-function video device or a multi-function device with video at function 0 and an HDA audio controller at function 1. The HDA controller can be enabled or disabled by a bit in the function 0 config space. Some BIOSes leave the HDA disabled, which means the HDMI connector from the NVIDIA GPU may not work. Sometimes the BIOS enables the HDA if an HDMI cable is connected at boot time, but that doesn't handle hotplug cases. Enable the HDA controller on device enumeration and resume and re-read the header type, which tells us whether the GPU is a multi-function device. This quirk is limited to NVIDIA PCI devices with the VGA Controller device class. This is expected to correspond to product configurations where the NVIDIA GPU has connectors attached. Other products where the device class is 3D Controller are expected to correspond to configurations where the NVIDIA GPU is dedicated (dGPU) and has no connectors. See original post (URL below) for more details. This commit takes inspiration from an earlier patch by Daniel Drake. Link: https://lore.kernel.org/r/20190708051744.24039-1-drake@endlessm.com v2 Link: https://lore.kernel.org/r/20190613063514.15317-1-drake@endlessm.com v1 Link: https://devtalk.nvidia.com/default/topic/1024022 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75985 Signed-off-by: Lukas Wunner Signed-off-by: Daniel Drake [bhelgaas: commit log, log message, return early if already enabled] Signed-off-by: Bjorn Helgaas Cc: Aaron Plattner Cc: Peter Wu Cc: Ilia Mirkin Cc: Karol Herbst Cc: Maik Freudenberg Signed-off-by: Sasha Levin commit 616bce61108b944170db6e085d1390583c3e7d42 Author: Abhishek Sahu Date: Thu Jun 6 14:52:25 2019 +0530 PCI: Add NVIDIA GPU multi-function power dependencies [ Upstream commit 6d2e369f0d4c3e6125c886847c04106b03d2609e ] The NVIDIA Turing GPU is a multi-function PCI device with the following functions: - Function 0: VGA display controller - Function 1: Audio controller - Function 2: USB xHCI Host controller - Function 3: USB Type-C UCSI controller Function 0 is tightly coupled with other functions in the hardware. When function 0 is in D3, it gates power for hardware blocks used by other functions, which means those functions only work when function 0 is in D0. If any of these functions (1/2/3) are in D0, then function 0 should also be in D0. Commit 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller") already creates a device link to show the dependency of function 1 on function 0 of this GPU. Create additional device links to express the dependencies of functions 2 and 3 on function 0. This means function 0 will be in D0 if any other function is in D0. [bhelgaas: I think the PCI spec expectation is that functions can be power-managed independently, so I don't think this device is technically compliant. For example, the PCIe r5.0 spec, sec 1.4, says "the PCI/PCIe hardware/software model includes architectural constructs necessary to discover, configure, and use a Function, without needing Function-specific knowledge" and sec 5.1 says "D states are associated with a particular Function" and "PM provides ... a mechanism to identify power management capabilities of a given Function [and] the ability to transition a Function into a certain power management state."] Link: https://lore.kernel.org/lkml/20190606092225.17960-3-abhsahu@nvidia.com Signed-off-by: Abhishek Sahu [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 2493cfda07ef38ca74db149e3a265e5d8edbd01d Author: Gustavo Pimentel Date: Tue Jun 4 15:29:25 2019 +0200 PCI: Add Synopsys endpoint EDDA Device ID [ Upstream commit 1f418f46503d72594bbe6407d97fd2ae1ce15ee6 ] Create and add Synopsys Endpoint EDDA Device ID to PCI ID list, since this ID is now being use on two different drivers (pci_endpoint_test.ko and dw-edma-pcie.ko). Signed-off-by: Gustavo Pimentel Acked-by: Bjorn Helgaas Cc: Kishon Vijay Abraham I Cc: Bjorn Helgaas Cc: Lorenzo Pieralisi Cc: Joao Pinto Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4b66ab91c0355732cf3e531f6dcf6ed2c4ff7479 Author: Kishon Vijay Abraham I Date: Mon Mar 25 15:09:46 2019 +0530 misc: pci_endpoint_test: Add support to test PCI EP in AM654x [ Upstream commit 5bb04b19230c02cc1b450b029856cbe093e09908 ] TI's AM654x PCIe EP has a restriction that BAR_0 is mapped to application registers. "PCIe Inbound Address Translation" section in AM65x Sitara Processors TRM (SPRUID7 – April 2018) describes BAR0 as reserved. Configure pci_endpoint_test to use BAR_2 instead. Also set alignment to 64K since "PCIe Subsystem Address Translation" section in TRM indicates minimum ATU window size is 64K. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 72892982d3e764cef689f636312826b0c0c6c1f8 Author: Xiaowei Bao Date: Thu Feb 21 11:16:20 2019 +0800 misc: pci_endpoint_test: Add the layerscape EP device support [ Upstream commit 85cef374d0ba93b8a2bd24850b97c1b34c666ccb ] Add the layerscape EP device support in pci_endpoint_test driver. Signed-off-by: Xiaowei Bao Signed-off-by: Lorenzo Pieralisi Reviewed-by: Minghuan Lian Reviewed-by: Zhiqiang Hou Reviewed-by: Greg KH Signed-off-by: Sasha Levin commit ea2d98477536e07f6a3676543efc86e6b5c43d7c Author: Andy Shevchenko Date: Fri Feb 1 17:24:52 2019 -0600 PCI: Move Rohm Vendor ID to generic list [ Upstream commit 0ce26a1c31ca928df4dfc7504c8898b71ff9f5d5 ] Move the Rohm Vendor ID to pci_ids.h instead of defining it in several drivers. Signed-off-by: Andy Shevchenko Signed-off-by: Bjorn Helgaas Acked-by: Mark Brown Acked-by: Linus Walleij Signed-off-by: Sasha Levin commit 3027c58b74fefe43d9b2d63f19668a6b2d04cec8 Author: Thinh Nguyen Date: Mon Dec 10 14:07:54 2018 -0800 PCI: Move Synopsys HAPS platform device IDs [ Upstream commit b6061b1e566d70c7686d194a6c47dc6ffa665c77 ] Move Synopsys HAPS platform device IDs to pci_ids.h so that both drivers/pci/quirks.c and dwc3-haps driver can reference these IDs. Signed-off-by: Thinh Nguyen Signed-off-by: Bjorn Helgaas Acked-by: Felipe Balbi Signed-off-by: Sasha Levin commit d1d93a58521c0ba2a251c1f7fc879bad6a25f8f0 Author: Heiner Kallweit Date: Sun Nov 11 20:31:21 2018 +0100 PCI: add USR vendor id and use it in r8169 and w6692 driver [ Upstream commit 9206eb0bc5679d06d2f54b9db86fe2b9a55e07e4 ] The PCI vendor id of U.S. Robotics isn't defined in pci_ids.h so far, only ISDN driver w6692 has a private definition. Move the definition to pci_ids.h and use it in the r8169 driver too. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1b94ac684bb2d905235d1b4d49f6b77a26e11248 Author: Woods, Brian Date: Tue Nov 6 20:08:18 2018 +0000 x86/amd_nb: Add PCI device IDs for family 17h, model 30h [ Upstream commit be3518a16ef270e3b030a6ae96055f83f51bd3dd ] Add the PCI device IDs for family 17h model 30h, since they are needed for accessing various registers via the data fabric/SMN interface. Signed-off-by: Brian Woods Signed-off-by: Borislav Petkov CC: Bjorn Helgaas CC: Clemens Ladisch CC: Guenter Roeck CC: "H. Peter Anvin" CC: Ingo Molnar CC: Jean Delvare CC: Jia Zhang CC: CC: CC: Pu Wen CC: Thomas Gleixner CC: x86-ml Link: http://lkml.kernel.org/r/20181106200754.60722-4-brian.woods@amd.com Signed-off-by: Sasha Levin commit d6d1f77e49ea368bbd9d03ac3fd058bde5d0446c Author: Woods, Brian Date: Tue Nov 6 20:08:14 2018 +0000 hwmon/k10temp, x86/amd_nb: Consolidate shared device IDs [ Upstream commit dedf7dce4cec5c0abe69f4fa6938d5100398220b ] Consolidate shared PCI_DEVICE_IDs that were scattered through k10temp and amd_nb, and move them into pci_ids. Signed-off-by: Brian Woods Signed-off-by: Borislav Petkov Acked-by: Guenter Roeck CC: Bjorn Helgaas CC: Clemens Ladisch CC: "H. Peter Anvin" CC: Ingo Molnar CC: Jean Delvare CC: Jia Zhang CC: CC: CC: Pu Wen CC: Thomas Gleixner CC: x86-ml Link: http://lkml.kernel.org/r/20181106200754.60722-2-brian.woods@amd.com Signed-off-by: Sasha Levin commit 07e51af181bec288287e8c244998f94fd23087ad Author: Corey Minyard Date: Mon Feb 26 12:49:16 2018 -0600 pci:ipmi: Move IPMI PCI class id defines to pci_ids.h [ Upstream commit 05c3d056086a6217a77937b7fa0df35ec75715e6 ] Signed-off-by: Corey Minyard Acked-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 7b9fc2ff31a6c1c6c5bc1e63a54953816fb74776 Author: Jakub Kicinski Date: Tue Aug 14 17:14:30 2018 -0700 PCI: Remove unused NFP32xx IDs [ Upstream commit 1ccce46c5e8b8a0d2606fb8bb72bff069ffdc3ab ] Defines for NFP32xx are no longer used anywhere, remove them. Signed-off-by: Jakub Kicinski Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 41e887f347d4f3492d1f698010310aa5335d3fb2 Author: Ashok Raj Date: Thu May 28 13:57:42 2020 -0700 PCI: Add ACS quirk for Intel Root Complex Integrated Endpoints [ Upstream commit 3247bd10a4502a3075ce8e1c3c7d31ef76f193ce ] All Intel platforms guarantee that all root complex implementations must send transactions up to IOMMU for address translations. Hence for Intel RCiEP devices, we can assume some ACS-type isolation even without an ACS capability. From the Intel VT-d spec, r3.1, sec 3.16 ("Root-Complex Peer to Peer Considerations"): When DMA remapping is enabled, peer-to-peer requests through the Root-Complex must be handled as follows: - The input address in the request is translated (through first-level, second-level or nested translation) to a host physical address (HPA). The address decoding for peer addresses must be done only on the translated HPA. Hardware implementations are free to further limit peer-to-peer accesses to specific host physical address regions (or to completely disallow peer-forwarding of translated requests). - Since address translation changes the contents (address field) of the PCI Express Transaction Layer Packet (TLP), for PCI Express peer-to-peer requests with ECRC, the Root-Complex hardware must use the new ECRC (re-computed with the translated address) if it decides to forward the TLP as a peer request. - Root-ports, and multi-function root-complex integrated endpoints, may support additional peer-to-peer control features by supporting PCI Express Access Control Services (ACS) capability. Refer to ACS capability in PCI Express specifications for details. Since Linux didn't give special treatment to allow this exception, certain RCiEP MFD devices were grouped in a single IOMMU group. This doesn't permit a single device to be assigned to a guest for instance. In one vendor system: Device 14.x were grouped in a single IOMMU group. /sys/kernel/iommu_groups/5/devices/0000:00:14.0 /sys/kernel/iommu_groups/5/devices/0000:00:14.2 /sys/kernel/iommu_groups/5/devices/0000:00:14.3 After this patch: /sys/kernel/iommu_groups/5/devices/0000:00:14.0 /sys/kernel/iommu_groups/5/devices/0000:00:14.2 /sys/kernel/iommu_groups/6/devices/0000:00:14.3 <<< new group 14.0 and 14.2 are integrated devices, but legacy end points, whereas 14.3 was a PCIe-compliant RCiEP. 00:14.3 Network controller: Intel Corporation Device 9df0 (rev 30) Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00 This permits assigning this device to a guest VM. [bhelgaas: drop "Fixes" tag since this doesn't fix a bug in that commit] Link: https://lore.kernel.org/r/1590699462-7131-1-git-send-email-ashok.raj@intel.com Tested-by: Darrel Goeddel Signed-off-by: Ashok Raj Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Williamson Cc: stable@vger.kernel.org Cc: Lu Baolu Cc: Mark Scott , Cc: Romil Sharma Signed-off-by: Sasha Levin commit 6663038890fd7d274017b51bb3c7b07f309680a3 Author: Abhinav Ratna Date: Tue Aug 20 10:09:45 2019 +0530 PCI: Add ACS quirk for iProc PAXB [ Upstream commit 46b2c32df7a462d0e64b68c513e5c4c1b2a399a7 ] iProc PAXB Root Ports don't advertise an ACS capability, but they do not allow peer-to-peer transactions between Root Ports. Add an ACS quirk so each Root Port can be in a separate IOMMU group. [bhelgaas: commit log, comment, use common implementation style] Link: https://lore.kernel.org/r/1566275985-25670-1-git-send-email-srinath.mannam@broadcom.com Signed-off-by: Abhinav Ratna Signed-off-by: Srinath Mannam Signed-off-by: Bjorn Helgaas Acked-by: Scott Branden Signed-off-by: Sasha Levin commit a77e92f05b90d4e845900dcc63ee26c45f058a78 Author: Kevin Buettner Date: Sun May 24 00:35:29 2020 -0700 PCI: Avoid FLR for AMD Starship USB 3.0 [ Upstream commit 5727043c73fdfe04597971b5f3f4850d879c1f4f ] The AMD Starship USB 3.0 host controller advertises Function Level Reset support, but it apparently doesn't work. Add a quirk to prevent use of FLR on this device. Without this quirk, when attempting to assign (pass through) an AMD Starship USB 3.0 host controller to a guest OS, the system becomes increasingly unresponsive over the course of several minutes, eventually requiring a hard reset. Shortly after attempting to start the guest, I see these messages: vfio-pci 0000:05:00.3: not ready 1023ms after FLR; waiting vfio-pci 0000:05:00.3: not ready 2047ms after FLR; waiting vfio-pci 0000:05:00.3: not ready 4095ms after FLR; waiting vfio-pci 0000:05:00.3: not ready 8191ms after FLR; waiting And then eventually: vfio-pci 0000:05:00.3: not ready 65535ms after FLR; giving up INFO: NMI handler (perf_event_nmi_handler) took too long to run: 0.000 msecs perf: interrupt took too long (642744 > 2500), lowering kernel.perf_event_max_sample_rate to 1000 INFO: NMI handler (perf_event_nmi_handler) took too long to run: 82.270 msecs INFO: NMI handler (perf_event_nmi_handler) took too long to run: 680.608 msecs INFO: NMI handler (perf_event_nmi_handler) took too long to run: 100.952 msecs ... watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [qemu-system-x86:7487] Tested on a Micro-Star International Co., Ltd. MS-7C59/Creator TRX40 motherboard with an AMD Ryzen Threadripper 3970X. Link: https://lore.kernel.org/r/20200524003529.598434ff@f31-4.lan Signed-off-by: Kevin Buettner Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 389b5fd1340b0c8c634617d354f3083ca222a7a1 Author: Marcos Scriven Date: Wed May 20 18:23:30 2020 -0500 PCI: Avoid FLR for AMD Matisse HD Audio & USB 3.0 [ Upstream commit 0d14f06cd6657ba3446a5eb780672da487b068e7 ] The AMD Matisse HD Audio & USB 3.0 devices advertise Function Level Reset support, but hang when an FLR is triggered. To reproduce the problem, attach the device to a VM, then detach and try to attach again. Rename the existing quirk_intel_no_flr(), which was not Intel-specific, to quirk_no_flr(), and apply it to prevent the use of FLR on these AMD devices. Link: https://lore.kernel.org/r/CAAri2DpkcuQZYbT6XsALhx2e6vRqPHwtbjHYeiH7MNp4zmt1RA@mail.gmail.com Signed-off-by: Marcos Scriven Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 36460fae6bc3f4b213be5a3077f7ec630e76bae6 Author: Kai-Heng Feng Date: Fri May 8 14:53:41 2020 +0800 PCI: Avoid Pericom USB controller OHCI/EHCI PME# defect [ Upstream commit 68f5fc4ea9ddf9f77720d568144219c4e6452cde ] Both Pericom OHCI and EHCI devices advertise PME# support from all power states: 06:00.0 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e] (rev 01) (prog-if 10 [OHCI]) Subsystem: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) 06:00.2 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f] (rev 01) (prog-if 20 [EHCI]) Subsystem: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) But testing shows that it's unreliable: there is a 20% chance PME# won't be asserted when a USB device is plugged. Remove PME support for both devices to make USB plugging work reliably. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205981 Link: https://lore.kernel.org/r/20200508065343.32751-2-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 8f3f5ba25e2b811be915c1d86cf8d7847287339d Author: Eric Biggers Date: Wed May 6 11:31:40 2020 -0700 ext4: fix race between ext4_sync_parent() and rename() commit 08adf452e628b0e2ce9a01048cfbec52353703d7 upstream. 'igrab(d_inode(dentry->d_parent))' without holding dentry->d_lock is broken because without d_lock, d_parent can be concurrently changed due to a rename(). Then if the old directory is immediately deleted, old d_parent->inode can be NULL. That causes a NULL dereference in igrab(). To fix this, use dget_parent() to safely grab a reference to the parent dentry, which pins the inode. This also eliminates the need to use d_find_any_alias() other than for the initial inode, as we no longer throw away the dentry at each step. This is an extremely hard race to hit, but it is possible. Adding a udelay() in between the reads of ->d_parent and its ->d_inode makes it reproducible on a no-journal filesystem using the following program: #include #include int main() { if (fork()) { for (;;) { mkdir("dir1", 0700); int fd = open("dir1/file", O_RDWR|O_CREAT|O_SYNC); write(fd, "X", 1); close(fd); } } else { mkdir("dir2", 0700); for (;;) { rename("dir1/file", "dir2/file"); rmdir("dir1"); } } } Fixes: d59729f4e794 ("ext4: fix races in ext4_sync_parent()") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20200506183140.541194-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit aab1eab04a1e085bd6549c6d2799b260182d2e31 Author: Jeffle Xu Date: Thu Apr 23 15:46:44 2020 +0800 ext4: fix error pointer dereference commit 8418897f1bf87da0cb6936489d57a4320c32c0af upstream. Don't pass error pointers to brelse(). commit 7159a986b420 ("ext4: fix some error pointer dereferences") has fixed some cases, fix the remaining one case. Once ext4_xattr_block_find()->ext4_sb_bread() failed, error pointer is stored in @bs->bh, which will be passed to brelse() in the cleanup routine of ext4_xattr_set_handle(). This will then cause a NULL panic crash in __brelse(). BUG: unable to handle kernel NULL pointer dereference at 000000000000005b RIP: 0010:__brelse+0x1b/0x50 Call Trace: ext4_xattr_set_handle+0x163/0x5d0 ext4_xattr_set+0x95/0x110 __vfs_setxattr+0x6b/0x80 __vfs_setxattr_noperm+0x68/0x1b0 vfs_setxattr+0xa0/0xb0 setxattr+0x12c/0x1a0 path_setxattr+0x8d/0xc0 __x64_sys_setxattr+0x27/0x30 do_syscall_64+0x60/0x250 entry_SYSCALL_64_after_hwframe+0x49/0xbe In this case, @bs->bh stores '-EIO' actually. Fixes: fb265c9cb49e ("ext4: add ext4_sb_bread() to disambiguate ENOMEM cases") Signed-off-by: Jeffle Xu Reviewed-by: Joseph Qi Cc: stable@kernel.org # 2.6.19 Reviewed-by: Ritesh Harjani Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/1587628004-95123-1-git-send-email-jefflexu@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit acbec3dd4586d271a0248453d2810712439ded1b Author: Harshad Shirwadkar Date: Mon Apr 20 19:39:59 2020 -0700 ext4: fix EXT_MAX_EXTENT/INDEX to check for zeroed eh_max commit c36a71b4e35ab35340facdd6964a00956b9fef0a upstream. If eh->eh_max is 0, EXT_MAX_EXTENT/INDEX would evaluate to unsigned (-1) resulting in illegal memory accesses. Although there is no consistent repro, we see that generic/019 sometimes crashes because of this bug. Ran gce-xfstests smoke and verified that there were no regressions. Signed-off-by: Harshad Shirwadkar Link: https://lore.kernel.org/r/20200421023959.20879-2-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3815f6508d90a7e7c86719a0009fd4bb6b89ad2b Author: Roberto Sassu Date: Tue Apr 14 10:01:31 2020 +0200 evm: Fix possible memory leak in evm_calc_hmac_or_hash() commit 0c4395fb2aa77341269ea619c5419ea48171883f upstream. Don't immediately return if the signature is portable and security.ima is not present. Just set error so that memory allocated is freed before returning from evm_calc_hmac_or_hash(). Fixes: 50b977481fce9 ("EVM: Add support for portable signature format") Signed-off-by: Roberto Sassu Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit d52a190318f0901965f200f76eb28dd8426bbb25 Author: Roberto Sassu Date: Wed Jun 3 17:08:20 2020 +0200 ima: Directly assign the ima_default_policy pointer to ima_rules commit 067a436b1b0aafa593344fddd711a755a58afb3b upstream. This patch prevents the following oops: [ 10.771813] BUG: kernel NULL pointer dereference, address: 0000000000000 [...] [ 10.779790] RIP: 0010:ima_match_policy+0xf7/0xb80 [...] [ 10.798576] Call Trace: [ 10.798993] ? ima_lsm_policy_change+0x2b0/0x2b0 [ 10.799753] ? inode_init_owner+0x1a0/0x1a0 [ 10.800484] ? _raw_spin_lock+0x7a/0xd0 [ 10.801592] ima_must_appraise.part.0+0xb6/0xf0 [ 10.802313] ? ima_fix_xattr.isra.0+0xd0/0xd0 [ 10.803167] ima_must_appraise+0x4f/0x70 [ 10.804004] ima_post_path_mknod+0x2e/0x80 [ 10.804800] do_mknodat+0x396/0x3c0 It occurs when there is a failure during IMA initialization, and ima_init_policy() is not called. IMA hooks still call ima_match_policy() but ima_rules is NULL. This patch prevents the crash by directly assigning the ima_default_policy pointer to ima_rules when ima_rules is defined. This wouldn't alter the existing behavior, as ima_rules is always set at the end of ima_init_policy(). Cc: stable@vger.kernel.org # 3.7.x Fixes: 07f6a79415d7d ("ima: add appraise action keywords and default rules") Reported-by: Takashi Iwai Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 71381daffeed955d29b40e992bb7eac554e5da23 Author: Krzysztof Struczynski Date: Tue Apr 28 09:30:10 2020 +0200 ima: Fix ima digest hash table key calculation commit 1129d31b55d509f15e72dc68e4b5c3a4d7b4da8d upstream. Function hash_long() accepts unsigned long, while currently only one byte is passed from ima_hash_key(), which calculates a key for ima_htable. Given that hashing the digest does not give clear benefits compared to using the digest itself, remove hash_long() and return the modulus calculated on the first two bytes of the digest with the number of slots. Also reduce the depth of the hash table by doubling the number of slots. Cc: stable@vger.kernel.org Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider") Co-developed-by: Roberto Sassu Signed-off-by: Roberto Sassu Signed-off-by: Krzysztof Struczynski Acked-by: David.Laight@aculab.com (big endian system concerns) Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 88afa532c14135528b905015f1d9a5e740a95136 Author: Pavel Tatashin Date: Wed Jun 3 15:59:24 2020 -0700 mm: initialize deferred pages with interrupts enabled commit 3d060856adfc59afb9d029c233141334cfaba418 upstream. Initializing struct pages is a long task and keeping interrupts disabled for the duration of this operation introduces a number of problems. 1. jiffies are not updated for long period of time, and thus incorrect time is reported. See proposed solution and discussion here: lkml/20200311123848.118638-1-shile.zhang@linux.alibaba.com 2. It prevents farther improving deferred page initialization by allowing intra-node multi-threading. We are keeping interrupts disabled to solve a rather theoretical problem that was never observed in real world (See 3a2d7fa8a3d5). Let's keep interrupts enabled. In case we ever encounter a scenario where an interrupt thread wants to allocate large amount of memory this early in boot we can deal with that by growing zone (see deferred_grow_zone()) by the needed amount before starting deferred_init_memmap() threads. Before: [ 1.232459] node 0 initialised, 12058412 pages in 1ms After: [ 1.632580] node 0 initialised, 12051227 pages in 436ms Fixes: 3a2d7fa8a3d5 ("mm: disable interrupts while initializing deferred pages") Reported-by: Shile Zhang Signed-off-by: Pavel Tatashin Signed-off-by: Andrew Morton Reviewed-by: Daniel Jordan Reviewed-by: David Hildenbrand Acked-by: Michal Hocko Acked-by: Vlastimil Babka Cc: Dan Williams Cc: James Morris Cc: Kirill Tkhai Cc: Sasha Levin Cc: Yiqian Wei Cc: [4.17+] Link: http://lkml.kernel.org/r/20200403140952.17177-3-pasha.tatashin@soleen.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 453d8a481b127edfa7fb76af1bc7586b7a63bdd2 Author: Andrea Arcangeli Date: Wed May 27 19:06:24 2020 -0400 mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked() commit c444eb564fb16645c172d550359cb3d75fe8a040 upstream. Write protect anon page faults require an accurate mapcount to decide if to break the COW or not. This is implemented in the THP path with reuse_swap_page() -> page_trans_huge_map_swapcount()/page_trans_huge_mapcount(). If the COW triggers while the other processes sharing the page are under a huge pmd split, to do an accurate reading, we must ensure the mapcount isn't computed while it's being transferred from the head page to the tail pages. reuse_swap_cache() already runs serialized by the page lock, so it's enough to add the page lock around __split_huge_pmd_locked too, in order to add the missing serialization. Note: the commit in "Fixes" is just to facilitate the backporting, because the code before such commit didn't try to do an accurate THP mapcount calculation and it instead used the page_count() to decide if to COW or not. Both the page_count and the pin_count are THP-wide refcounts, so they're inaccurate if used in reuse_swap_page(). Reverting such commit (besides the unrelated fix to the local anon_vma assignment) would have also opened the window for memory corruption side effects to certain workloads as documented in such commit header. Signed-off-by: Andrea Arcangeli Suggested-by: Jann Horn Reported-by: Jann Horn Acked-by: Kirill A. Shutemov Fixes: 6d0a07edd17c ("mm: thp: calculate the mapcount correctly for THP pages during WP faults") Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e2049349003caaa6d7015d3d621502688d27a4e5 Author: Marcos Paulo de Souza Date: Sun May 10 23:15:07 2020 -0300 btrfs: send: emit file capabilities after chown commit 89efda52e6b6930f80f5adda9c3c9edfb1397191 upstream. Whenever a chown is executed, all capabilities of the file being touched are lost. When doing incremental send with a file with capabilities, there is a situation where the capability can be lost on the receiving side. The sequence of actions bellow shows the problem: $ mount /dev/sda fs1 $ mount /dev/sdb fs2 $ touch fs1/foo.bar $ setcap cap_sys_nice+ep fs1/foo.bar $ btrfs subvolume snapshot -r fs1 fs1/snap_init $ btrfs send fs1/snap_init | btrfs receive fs2 $ chgrp adm fs1/foo.bar $ setcap cap_sys_nice+ep fs1/foo.bar $ btrfs subvolume snapshot -r fs1 fs1/snap_complete $ btrfs subvolume snapshot -r fs1 fs1/snap_incremental $ btrfs send fs1/snap_complete | btrfs receive fs2 $ btrfs send -p fs1/snap_init fs1/snap_incremental | btrfs receive fs2 At this point, only a chown was emitted by "btrfs send" since only the group was changed. This makes the cap_sys_nice capability to be dropped from fs2/snap_incremental/foo.bar To fix that, only emit capabilities after chown is emitted. The current code first checks for xattrs that are new/changed, emits them, and later emit the chown. Now, __process_new_xattr skips capabilities, letting only finish_inode_if_needed to emit them, if they exist, for the inode being processed. This behavior was being worked around in "btrfs receive" side by caching the capability and only applying it after chown. Now, xattrs are only emmited _after_ chown, making that workaround not needed anymore. Link: https://github.com/kdave/btrfs-progs/issues/202 CC: stable@vger.kernel.org # 4.4+ Suggested-by: Filipe Manana Reviewed-by: Filipe Manana Signed-off-by: Marcos Paulo de Souza Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit bcad3df8f2df01db78b6e85812ffad8291602606 Author: Anand Jain Date: Tue May 5 02:58:25 2020 +0800 btrfs: include non-missing as a qualifier for the latest_bdev commit 998a0671961f66e9fad4990ed75f80ba3088c2f1 upstream. btrfs_free_extra_devids() updates fs_devices::latest_bdev to point to the bdev with greatest device::generation number. For a typical-missing device the generation number is zero so fs_devices::latest_bdev will never point to it. But if the missing device is due to alienation [1], then device::generation is not zero and if it is greater or equal to the rest of device generations in the list, then fs_devices::latest_bdev ends up pointing to the missing device and reports the error like [2]. [1] We maintain devices of a fsid (as in fs_device::fsid) in the fs_devices::devices list, a device is considered as an alien device if its fsid does not match with the fs_device::fsid Consider a working filesystem with raid1: $ mkfs.btrfs -f -d raid1 -m raid1 /dev/sda /dev/sdb $ mount /dev/sda /mnt-raid1 $ umount /mnt-raid1 While mnt-raid1 was unmounted the user force-adds one of its devices to another btrfs filesystem: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt-single $ btrfs dev add -f /dev/sda /mnt-single Now the original mnt-raid1 fails to mount in degraded mode, because fs_devices::latest_bdev is pointing to the alien device. $ mount -o degraded /dev/sdb /mnt-raid1 [2] mount: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. kernel: BTRFS warning (device sdb): devid 1 uuid 072a0192-675b-4d5a-8640-a5cf2b2c704d is missing kernel: BTRFS error (device sdb): failed to read devices kernel: BTRFS error (device sdb): open_ctree failed Fix the root cause by checking if the device is not missing before it can be considered for the fs_devices::latest_bdev. CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Josef Bacik Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 6d49d04cd1a92a08af549ea230bb2fd4aee87ba1 Author: Daniel Axtens Date: Wed Jun 3 15:56:46 2020 -0700 string.h: fix incompatibility between FORTIFY_SOURCE and KASAN [ Upstream commit 47227d27e2fcb01a9e8f5958d8997cf47a820afc ] The memcmp KASAN self-test fails on a kernel with both KASAN and FORTIFY_SOURCE. When FORTIFY_SOURCE is on, a number of functions are replaced with fortified versions, which attempt to check the sizes of the operands. However, these functions often directly invoke __builtin_foo() once they have performed the fortify check. Using __builtins may bypass KASAN checks if the compiler decides to inline it's own implementation as sequence of instructions, rather than emit a function call that goes out to a KASAN-instrumented implementation. Why is only memcmp affected? ============================ Of the string and string-like functions that kasan_test tests, only memcmp is replaced by an inline sequence of instructions in my testing on x86 with gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2). I believe this is due to compiler heuristics. For example, if I annotate kmalloc calls with the alloc_size annotation (and disable some fortify compile-time checking!), the compiler will replace every memset except the one in kmalloc_uaf_memset with inline instructions. (I have some WIP patches to add this annotation.) Does this affect other functions in string.h? ============================================= Yes. Anything that uses __builtin_* rather than __real_* could be affected. This looks like: - strncpy - strcat - strlen - strlcpy maybe, under some circumstances? - strncat under some circumstances - memset - memcpy - memmove - memcmp (as noted) - memchr - strcpy Whether a function call is emitted always depends on the compiler. Most bugs should get caught by FORTIFY_SOURCE, but the missed memcmp test shows that this is not always the case. Isn't FORTIFY_SOURCE disabled with KASAN? ========================================- The string headers on all arches supporting KASAN disable fortify with kasan, but only when address sanitisation is _also_ disabled. For example from x86: #if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__) /* * For files that are not instrumented (e.g. mm/slub.c) we * should use not instrumented version of mem* functions. */ #define memcpy(dst, src, len) __memcpy(dst, src, len) #define memmove(dst, src, len) __memmove(dst, src, len) #define memset(s, c, n) __memset(s, c, n) #ifndef __NO_FORTIFY #define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */ #endif #endif This comes from commit 6974f0c4555e ("include/linux/string.h: add the option of fortified string.h functions"), and doesn't work when KASAN is enabled and the file is supposed to be sanitised - as with test_kasan.c I'm pretty sure this is not wrong, but not as expansive it should be: * we shouldn't use __builtin_memcpy etc in files where we don't have instrumentation - it could devolve into a function call to memcpy, which will be instrumented. Rather, we should use __memcpy which by convention is not instrumented. * we also shouldn't be using __builtin_memcpy when we have a KASAN instrumented file, because it could be replaced with inline asm that will not be instrumented. What is correct behaviour? ========================== Firstly, there is some overlap between fortification and KASAN: both provide some level of _runtime_ checking. Only fortify provides compile-time checking. KASAN and fortify can pick up different things at runtime: - Some fortify functions, notably the string functions, could easily be modified to consider sub-object sizes (e.g. members within a struct), and I have some WIP patches to do this. KASAN cannot detect these because it cannot insert poision between members of a struct. - KASAN can detect many over-reads/over-writes when the sizes of both operands are unknown, which fortify cannot. So there are a couple of options: 1) Flip the test: disable fortify in santised files and enable it in unsanitised files. This at least stops us missing KASAN checking, but we lose the fortify checking. 2) Make the fortify code always call out to real versions. Do this only for KASAN, for fear of losing the inlining opportunities we get from __builtin_*. (We can't use kasan_check_{read,write}: because the fortify functions are _extern inline_, you can't include _static_ inline functions without a compiler warning. kasan_check_{read,write} are static inline so we can't use them even when they would otherwise be suitable.) Take approach 2 and call out to real versions when KASAN is enabled. Use __underlying_foo to distinguish from __real_foo: __real_foo always refers to the kernel's implementation of foo, __underlying_foo could be either the kernel implementation or the __builtin_foo implementation. This is sometimes enough to make the memcmp test succeed with FORTIFY_SOURCE enabled. It is at least enough to get the function call into the module. One more fix is needed to make it reliable: see the next patch. Fixes: 6974f0c4555e ("include/linux/string.h: add the option of fortified string.h functions") Signed-off-by: Daniel Axtens Signed-off-by: Andrew Morton Tested-by: David Gow Reviewed-by: Dmitry Vyukov Cc: Daniel Micay Cc: Andrey Ryabinin Cc: Alexander Potapenko Link: http://lkml.kernel.org/r/20200423154503.5103-3-dja@axtens.net Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6e0485531d9fa22053d6fd54888d792f26ece156 Author: Hans de Goede Date: Fri May 15 20:39:16 2020 +0200 platform/x86: intel-vbtn: Only blacklist SW_TABLET_MODE on the 9 / "Laptop" chasis-type [ Upstream commit cfae58ed681c5fe0185db843013ecc71cd265ebf ] The HP Stream x360 11-p000nd no longer report SW_TABLET_MODE state / events with recent kernels. This model reports a chassis-type of 10 / "Notebook" which is not on the recently introduced chassis-type whitelist Commit de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's") added a chassis-type whitelist and only listed 31 / "Convertible" as being capable of generating valid SW_TABLET_MOD events. Commit 1fac39fd0316 ("platform/x86: intel-vbtn: Also handle tablet-mode switch on "Detachable" and "Portable" chassis-types") extended the whitelist with chassis-types 8 / "Portable" and 32 / "Detachable". And now we need to exten the whitelist again with 10 / "Notebook"... The issue original fixed by the whitelist is really a ACPI DSDT bug on the Dell XPS 9360 where it has a VGBS which reports it is in tablet mode even though it is not a 2-in-1 at all, but a regular laptop. So since this is a workaround for a DSDT issue on that specific model, instead of extending the whitelist over and over again, lets switch to a blacklist and only blacklist the chassis-type of the model for which the chassis-type check was added. Note this also fixes the current version of the code no longer checking if dmi_get_system_info(DMI_CHASSIS_TYPE) returns NULL. Fixes: 1fac39fd0316 ("platform/x86: intel-vbtn: Also handle tablet-mode switch on "Detachable" and "Portable" chassis-types") Cc: Mario Limonciello Signed-off-by: Hans de Goede Reviewed-by: Mario Limonciello Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit da725858a2317d474c24e287a2b4d74de6dd7acf Author: Nickolai Kozachenko Date: Sat May 30 22:07:20 2020 +0500 platform/x86: intel-hid: Add a quirk to support HP Spectre X2 (2015) [ Upstream commit 8fe63eb757ac6e661a384cc760792080bdc738dc ] HEBC method reports capabilities of 5 button array but HP Spectre X2 (2015) does not have this control method (the same was for Wacom MobileStudio Pro). Expand previous DMI quirk by Alex Hung to also enable 5 button array for this system. Signed-off-by: Nickolai Kozachenko Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 1a3cee008fe4120384824e439052170b0bf31b1c Author: Andy Shevchenko Date: Fri May 15 16:27:04 2020 +0300 platform/x86: hp-wmi: Convert simple_strtoul() to kstrtou32() [ Upstream commit 5cdc45ed3948042f0d73c6fec5ee9b59e637d0d2 ] First of all, unsigned long can overflow u32 value on 64-bit machine. Second, simple_strtoul() doesn't check for overflow in the input. Convert simple_strtoul() to kstrtou32() to eliminate above issues. Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit fad0431b7e61b750ef798c1a739382dfae85e231 Author: Qiushi Wu Date: Thu May 28 13:20:46 2020 -0500 cpuidle: Fix three reference count leaks [ Upstream commit c343bf1ba5efcbf2266a1fe3baefec9cc82f867f ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb718348b8" fixed a similar problem. Signed-off-by: Qiushi Wu [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6d15fe48f50af2027c3292827c65277285acb9dc Author: Serge Semin Date: Fri May 29 16:11:51 2020 +0300 spi: dw: Return any value retrieved from the dma_transfer callback [ Upstream commit f0410bbf7d0fb80149e3b17d11d31f5b5197873e ] DW APB SSI DMA-part of the driver may need to perform the requested SPI-transfer synchronously. In that case the dma_transfer() callback will return 0 as a marker of the SPI transfer being finished so the SPI core doesn't need to wait and may proceed with the SPI message trasnfers pumping procedure. This will be needed to fix the problem when DMA transactions are finished, but there is still data left in the SPI Tx/Rx FIFOs being sent/received. But for now make dma_transfer to return 1 as the normal dw_spi_transfer_one() method. Signed-off-by: Serge Semin Cc: Georgy Vlasov Cc: Ramil Zaripov Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Arnd Bergmann Cc: Andy Shevchenko Cc: Feng Tang Cc: Rob Herring Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200529131205.31838-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6190bf276a661f5e810a22dbc0e765ca150e882e Author: Haibo Chen Date: Tue May 26 18:22:01 2020 +0800 mmc: sdhci-esdhc-imx: fix the mask for tuning start point [ Upstream commit 1194be8c949b8190b2882ad8335a5d98aa50c735 ] According the RM, the bit[6~0] of register ESDHC_TUNING_CTRL is TUNING_START_TAP, bit[7] of this register is to disable the command CRC check for standard tuning. So fix it here. Fixes: d87fc9663688 ("mmc: sdhci-esdhc-imx: support setting tuning start point") Signed-off-by: Haibo Chen Link: https://lore.kernel.org/r/1590488522-9292-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a7a2e0c22c87ce5048640b8a5c482c43f0845dff Author: Xie XiuQi Date: Tue May 5 10:45:21 2020 +0800 ixgbe: fix signed-integer-overflow warning [ Upstream commit 3b70683fc4d68f5d915d9dc7e5ba72c732c7315c ] ubsan report this warning, fix it by adding a unsigned suffix. UBSAN: signed-integer-overflow in drivers/net/ethernet/intel/ixgbe/ixgbe_common.c:2246:26 65535 * 65537 cannot be represented in type 'int' CPU: 21 PID: 7 Comm: kworker/u256:0 Not tainted 5.7.0-rc3-debug+ #39 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 03/27/2020 Workqueue: ixgbe ixgbe_service_task [ixgbe] Call trace: dump_backtrace+0x0/0x3f0 show_stack+0x28/0x38 dump_stack+0x154/0x1e4 ubsan_epilogue+0x18/0x60 handle_overflow+0xf8/0x148 __ubsan_handle_mul_overflow+0x34/0x48 ixgbe_fc_enable_generic+0x4d0/0x590 [ixgbe] ixgbe_service_task+0xc20/0x1f78 [ixgbe] process_one_work+0x8f0/0xf18 worker_thread+0x430/0x6d0 kthread+0x218/0x238 ret_from_fork+0x10/0x18 Reported-by: Hulk Robot Signed-off-by: Xie XiuQi Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 4fb193a4b4c5804842180eca49b22f5978da6439 Author: Ulf Hansson Date: Tue Apr 14 18:14:10 2020 +0200 mmc: via-sdmmc: Respect the cmd->busy_timeout from the mmc core [ Upstream commit 966244ccd2919e28f25555a77f204cd1c109cad8 ] Using a fixed 1s timeout for all commands (and data transfers) is a bit problematic. For some commands it means waiting longer than needed for the timer to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Bruce Chang Cc: Harald Welte Signed-off-by: Ulf Hansson Link: https://lore.kernel.org/r/20200414161413.3036-17-ulf.hansson@linaro.org Signed-off-by: Sasha Levin commit 2c4db6284be200887a41522968d0fa7c909cab2a Author: Ulf Hansson Date: Tue Apr 14 18:14:13 2020 +0200 staging: greybus: sdio: Respect the cmd->busy_timeout from the mmc core [ Upstream commit a389087ee9f195fcf2f31cd771e9ec5f02c16650 ] Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva Cc: Johan Hovold Cc: Alex Elder Cc: Greg Kroah-Hartman Cc: greybus-dev@lists.linaro.org Signed-off-by: Ulf Hansson Acked-by: Rui Miguel Silva Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 59b87f26f740f12b208fbca2daa956fb60a92669 Author: Veerabhadrarao Badiganti Date: Mon Apr 20 11:50:24 2020 +0530 mmc: sdhci-msm: Set SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 quirk [ Upstream commit d863cb03fb2aac07f017b2a1d923cdbc35021280 ] sdhci-msm can support auto cmd12. So enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 quirk. Signed-off-by: Veerabhadrarao Badiganti Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/1587363626-20413-3-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 63581542724e148e5a82a62d11f859eb6a9a891c Author: Coly Li Date: Wed May 27 12:01:53 2020 +0800 bcache: fix refcount underflow in bcache_device_free() [ Upstream commit 86da9f736740eba602389908574dfbb0f517baa5 ] The problematic code piece in bcache_device_free() is, 785 static void bcache_device_free(struct bcache_device *d) 786 { 787 struct gendisk *disk = d->disk; [snipped] 799 if (disk) { 800 if (disk->flags & GENHD_FL_UP) 801 del_gendisk(disk); 802 803 if (disk->queue) 804 blk_cleanup_queue(disk->queue); 805 806 ida_simple_remove(&bcache_device_idx, 807 first_minor_to_idx(disk->first_minor)); 808 put_disk(disk); 809 } [snipped] 816 } At line 808, put_disk(disk) may encounter kobject refcount of 'disk' being underflow. Here is how to reproduce the issue, - Attche the backing device to a cache device and do random write to make the cache being dirty. - Stop the bcache device while the cache device has dirty data of the backing device. - Only register the backing device back, NOT register cache device. - The bcache device node /dev/bcache0 won't show up, because backing device waits for the cache device shows up for the missing dirty data. - Now echo 1 into /sys/fs/bcache/pendings_cleanup, to stop the pending backing device. - After the pending backing device stopped, use 'dmesg' to check kernel message, a use-after-free warning from KASA reported the refcount of kobject linked to the 'disk' is underflow. The dropping refcount at line 808 in the above code piece is added by add_disk(d->disk) in bch_cached_dev_run(). But in the above condition the cache device is not registered, bch_cached_dev_run() has no chance to be called and the refcount is not added. The put_disk() for a non- added refcount of gendisk kobject triggers a underflow warning. This patch checks whether GENHD_FL_UP is set in disk->flags, if it is not set then the bcache device was not added, don't call put_disk() and the the underflow issue can be avoided. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit dfb3dbf0467ab7de4bd638a92ec17a8e964348d8 Author: YuanJunQing Date: Wed May 27 14:11:30 2020 +0800 MIPS: Fix IRQ tracing when call handle_fpe() and handle_msa_fpe() [ Upstream commit 31e1b3efa802f97a17628dde280006c4cee4ce5e ] Register "a1" is unsaved in this function, when CONFIG_TRACE_IRQFLAGS is enabled, the TRACE_IRQS_OFF macro will call trace_hardirqs_off(), and this may change register "a1". The changed register "a1" as argument will be send to do_fpe() and do_msa_fpe(). Signed-off-by: YuanJunQing Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 40a94a1ac783b878ec083b87242450949ae26eaf Author: Jiaxun Yang Date: Tue May 26 17:21:12 2020 +0800 PCI: Don't disable decoding when mmio_always_on is set [ Upstream commit b6caa1d8c80cb71b6162cb1f1ec13aa655026c9f ] Don't disable MEM/IO decoding when a device have both non_compliant_bars and mmio_always_on. That would allow us quirk devices with junk in BARs but can't disable their decoding. Signed-off-by: Jiaxun Yang Acked-by: Bjorn Helgaas Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 133b3d2401e3b61370362c917018179ef0253e55 Author: Alexander Sverdlin Date: Tue May 26 14:27:51 2020 +0200 macvlan: Skip loopback packets in RX handler [ Upstream commit 81f3dc9349ce0bf7b8447f147f45e70f0a5b36a6 ] Ignore loopback-originatig packets soon enough and don't try to process L2 header where it doesn't exist. The very similar br_handle_frame() in bridge code performs exactly the same check. This is an example of such ICMPv6 packet: skb len=96 headroom=40 headlen=96 tailroom=56 mac=(40,0) net=(40,40) trans=80 shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0)) csum(0xae2e9a2f ip_summed=1 complete_sw=0 valid=0 level=0) hash(0xc97ebd88 sw=1 l4=1) proto=0x86dd pkttype=5 iif=24 dev name=etha01.212 feat=0x0x0000000040005000 skb headroom: 00000000: 00 7c 86 52 84 88 ff ff 00 00 00 00 00 00 08 00 skb headroom: 00000010: 45 00 00 9e 5d 5c 40 00 40 11 33 33 00 00 00 01 skb headroom: 00000020: 02 40 43 80 00 00 86 dd skb linear: 00000000: 60 09 88 bd 00 38 3a ff fe 80 00 00 00 00 00 00 skb linear: 00000010: 00 40 43 ff fe 80 00 00 ff 02 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 00 00 01 86 00 61 00 40 00 00 2d skb linear: 00000030: 00 00 00 00 00 00 00 00 03 04 40 e0 00 00 01 2c skb linear: 00000040: 00 00 00 78 00 00 00 00 fd 5f 42 68 23 87 a8 81 skb linear: 00000050: 00 00 00 00 00 00 00 00 01 01 02 40 43 80 00 00 skb tailroom: 00000000: ... skb tailroom: 00000010: ... skb tailroom: 00000020: ... skb tailroom: 00000030: ... Call Trace, how it happens exactly: ... macvlan_handle_frame+0x321/0x425 [macvlan] ? macvlan_forward_source+0x110/0x110 [macvlan] __netif_receive_skb_core+0x545/0xda0 ? enqueue_task_fair+0xe5/0x8e0 ? __netif_receive_skb_one_core+0x36/0x70 __netif_receive_skb_one_core+0x36/0x70 process_backlog+0x97/0x140 net_rx_action+0x1eb/0x350 ? __hrtimer_run_queues+0x136/0x2e0 __do_softirq+0xe3/0x383 do_softirq_own_stack+0x2a/0x40 do_softirq.part.4+0x4e/0x50 netif_rx_ni+0x60/0xd0 dev_loopback_xmit+0x83/0xf0 ip6_finish_output2+0x575/0x590 [ipv6] ? ip6_cork_release.isra.1+0x64/0x90 [ipv6] ? __ip6_make_skb+0x38d/0x680 [ipv6] ? ip6_output+0x6c/0x140 [ipv6] ip6_output+0x6c/0x140 [ipv6] ip6_send_skb+0x1e/0x60 [ipv6] rawv6_sendmsg+0xc4b/0xe10 [ipv6] ? proc_put_long+0xd0/0xd0 ? rw_copy_check_uvector+0x4e/0x110 ? sock_sendmsg+0x36/0x40 sock_sendmsg+0x36/0x40 ___sys_sendmsg+0x2b6/0x2d0 ? proc_dointvec+0x23/0x30 ? addrconf_sysctl_forward+0x8d/0x250 [ipv6] ? dev_forward_change+0x130/0x130 [ipv6] ? _raw_spin_unlock+0x12/0x30 ? proc_sys_call_handler.isra.14+0x9f/0x110 ? __call_rcu+0x213/0x510 ? get_max_files+0x10/0x10 ? trace_hardirqs_on+0x2c/0xe0 ? __sys_sendmsg+0x63/0xa0 __sys_sendmsg+0x63/0xa0 do_syscall_64+0x6c/0x1e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Signed-off-by: Alexander Sverdlin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4ab6160016b1b470fa5f28a9fee9603bfaaff106 Author: Qu Wenruo Date: Thu Apr 2 14:37:35 2020 +0800 btrfs: qgroup: mark qgroup inconsistent if we're inherting snapshot to a new qgroup [ Upstream commit cbab8ade585a18c4334b085564d9d046e01a3f70 ] [BUG] For the following operation, qgroup is guaranteed to be screwed up due to snapshot adding to a new qgroup: # mkfs.btrfs -f $dev # mount $dev $mnt # btrfs qgroup en $mnt # btrfs subv create $mnt/src # xfs_io -f -c "pwrite 0 1m" $mnt/src/file # sync # btrfs qgroup create 1/0 $mnt/src # btrfs subv snapshot -i 1/0 $mnt/src $mnt/snapshot # btrfs qgroup show -prce $mnt/src qgroupid rfer excl max_rfer max_excl parent child -------- ---- ---- -------- -------- ------ ----- 0/5 16.00KiB 16.00KiB none none --- --- 0/257 1.02MiB 16.00KiB none none --- --- 0/258 1.02MiB 16.00KiB none none 1/0 --- 1/0 0.00B 0.00B none none --- 0/258 ^^^^^^^^^^^^^^^^^^^^ [CAUSE] The problem is in btrfs_qgroup_inherit(), we don't have good enough check to determine if the new relation would break the existing accounting. Unlike btrfs_add_qgroup_relation(), which has proper check to determine if we can do quick update without a rescan, in btrfs_qgroup_inherit() we can even assign a snapshot to multiple qgroups. [FIX] Fix it by manually marking qgroup inconsistent for snapshot inheritance. For subvolume creation, since all its extents are exclusively owned, we don't need to rescan. In theory, we should call relation check like quick_update_accounting() when doing qgroup inheritance and inform user about qgroup accounting inconsistency. But we don't have good mechanism to relay that back to the user in the snapshot creation context, thus we can only silently mark the qgroup inconsistent. Anyway, user shouldn't use qgroup inheritance during snapshot creation, and should add qgroup relationship after snapshot creation by 'btrfs qgroup assign', which has a much better UI to inform user about qgroup inconsistent and kick in rescan automatically. Reviewed-by: Josef Bacik Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 7736adec98a33bae11c4032165dc400293a87dc9 Author: Finn Thain Date: Wed May 20 14:32:02 2020 +1000 m68k: mac: Don't call via_flush_cache() on Mac IIfx [ Upstream commit bcc44f6b74106b31f0b0408b70305a40360d63b7 ] There is no VIA2 chip on the Mac IIfx, so don't call via_flush_cache(). This avoids a boot crash which appeared in v5.4. printk: console [ttyS0] enabled printk: bootconsole [debug0] disabled printk: bootconsole [debug0] disabled Calibrating delay loop... 9.61 BogoMIPS (lpj=48064) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) devtmpfs: initialized random: get_random_u32 called from bucket_table_alloc.isra.27+0x68/0x194 with crng_init=0 clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 256 (order: -1, 3072 bytes, linear) NET: Registered protocol family 16 Data read fault at 0x00000000 in Super Data (pc=0x8a6a) BAD KERNEL BUSERR Oops: 00000000 Modules linked in: PC: [<00008a6a>] via_flush_cache+0x12/0x2c SR: 2700 SP: 01c1fe3c a2: 01c24000 d0: 00001119 d1: 0000000c d2: 00012000 d3: 0000000f d4: 01c06840 d5: 00033b92 a0: 00000000 a1: 00000000 Process swapper (pid: 1, task=01c24000) Frame format=B ssw=0755 isc=0200 isb=fff7 daddr=00000000 dobuf=01c1fed0 baddr=00008a6e dibuf=0000004e ver=f Stack from 01c1fec4: 01c1fed0 00007d7e 00010080 01c1fedc 0000792e 00000001 01c1fef4 00006b40 01c80000 00040000 00000006 00000003 01c1ff1c 004a545e 004ff200 00040000 00000000 00000003 01c06840 00033b92 004a5410 004b6c88 01c1ff84 000021e2 00000073 00000003 01c06840 00033b92 0038507a 004bb094 004b6ca8 004b6c88 004b6ca4 004b6c88 000021ae 00020002 00000000 01c0685d 00000000 01c1ffb4 0049f938 00409c85 01c06840 0045bd40 00000073 00000002 00000002 00000000 Call Trace: [<00007d7e>] mac_cache_card_flush+0x12/0x1c [<00010080>] fix_dnrm+0x2/0x18 [<0000792e>] cache_push+0x46/0x5a [<00006b40>] arch_dma_prep_coherent+0x60/0x6e [<00040000>] switched_to_dl+0x76/0xd0 [<004a545e>] dma_atomic_pool_init+0x4e/0x188 [<00040000>] switched_to_dl+0x76/0xd0 [<00033b92>] parse_args+0x0/0x370 [<004a5410>] dma_atomic_pool_init+0x0/0x188 [<000021e2>] do_one_initcall+0x34/0x1be [<00033b92>] parse_args+0x0/0x370 [<0038507a>] strcpy+0x0/0x1e [<000021ae>] do_one_initcall+0x0/0x1be [<00020002>] do_proc_dointvec_conv+0x54/0x74 [<0049f938>] kernel_init_freeable+0x126/0x190 [<0049f94c>] kernel_init_freeable+0x13a/0x190 [<004a5410>] dma_atomic_pool_init+0x0/0x188 [<00041798>] complete+0x0/0x3c [<000b9b0c>] kfree+0x0/0x20a [<0038df98>] schedule+0x0/0xd0 [<0038d604>] kernel_init+0x0/0xda [<0038d610>] kernel_init+0xc/0xda [<0038d604>] kernel_init+0x0/0xda [<00002d38>] ret_from_kernel_thread+0xc/0x14 Code: 0000 2079 0048 10da 2279 0048 10c8 d3c8 <1011> 0200 fff7 1280 d1f9 0048 10c8 1010 0000 0008 1080 4e5e 4e75 4e56 0000 2039 Disabling lock debugging due to kernel taint Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Thanks to Stan Johnson for capturing the console log and running git bisect. Git bisect said commit 8e3a68fb55e0 ("dma-mapping: make dma_atomic_pool_init self-contained") is the first "bad" commit. I don't know why. Perhaps mach_l2_flush first became reachable with that commit. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: Stan Johnson Signed-off-by: Finn Thain Cc: Joshua Thompson Link: https://lore.kernel.org/r/b8bbeef197d6b3898e82ed0d231ad08f575a4b34.1589949122.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 7fe5e9153dbb804d7732145a8bd8191da919467d Author: Arvind Sankar Date: Sat Feb 29 18:11:20 2020 -0500 x86/mm: Stop printing BRK addresses [ Upstream commit 67d631b7c05eff955ccff4139327f0f92a5117e5 ] This currently leaks kernel physical addresses into userspace. Signed-off-by: Arvind Sankar Signed-off-by: Borislav Petkov Acked-by: Kees Cook Acked-by: Dave Hansen Link: https://lkml.kernel.org/r/20200229231120.1147527-1-nivedita@alum.mit.edu Signed-off-by: Sasha Levin commit 06bd7d87ab25e72a5e9314b5009bd19ae4ca21e0 Author: Nicolas Toromanoff Date: Tue May 12 16:11:11 2020 +0200 crypto: stm32/crc32 - fix multi-instance [ Upstream commit 10b89c43a64eb0d236903b79a3bc9d8f6cbfd9c7 ] Ensure CRC algorithm is registered only once in crypto framework when there are several instances of CRC devices. Update the CRC device list management to avoid that only the first CRC instance is used. Fixes: b51dbe90912a ("crypto: stm32 - Support for STM32 CRC32 crypto module") Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a94c7a08ca56b1cbf01508811071a518b11b28ce Author: Nicolas Toromanoff Date: Tue May 12 16:11:10 2020 +0200 crypto: stm32/crc32 - fix run-time self test issue. [ Upstream commit a8cc3128bf2c01c4d448fe17149e87132113b445 ] Fix wrong crc32 initialisation value: "alg: shash: stm32_crc32 test failed (wrong result) on test vector 0, cfg="init+update+final aligned buffer" cra_name="crc32c" expects an init value of 0XFFFFFFFF, cra_name="crc32" expects an init value of 0. Fixes: b51dbe90912a ("crypto: stm32 - Support for STM32 CRC32 crypto module") Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b5528bda391157006c48fb679e74181d2cf2861b Author: Nicolas Toromanoff Date: Tue May 12 16:11:09 2020 +0200 crypto: stm32/crc32 - fix ext4 chksum BUG_ON() [ Upstream commit 49c2c082e00e0bc4f5cbb7c21c7f0f873b35ab09 ] Allow use of crc_update without prior call to crc_init. And change (and fix) driver to use CRC device even on unaligned buffers. Fixes: b51dbe90912a ("crypto: stm32 - Support for STM32 CRC32 crypto module") Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 240934c2d4646fc4ba4423014f6f42ca864acecd Author: Serge Semin Date: Thu May 21 17:07:22 2020 +0300 mips: Add udelay lpj numbers adjustment [ Upstream commit ed26aacfb5f71eecb20a51c4467da440cb719d66 ] Loops-per-jiffies is a special number which represents a number of noop-loop cycles per CPU-scheduler quantum - jiffies. As you understand aside from CPU-specific implementation it depends on the CPU frequency. So when a platform has the CPU frequency fixed, we have no problem and the current udelay interface will work just fine. But as soon as CPU-freq driver is enabled and the cores frequency changes, we'll end up with distorted udelay's. In order to fix this we have to accordinly adjust the per-CPU udelay_val (the same as the global loops_per_jiffy) number. This can be done in the CPU-freq transition event handler. We subscribe to that event in the MIPS arch time-inititalization method. Co-developed-by: Alexey Malahov Signed-off-by: Alexey Malahov Signed-off-by: Serge Semin Reviewed-by: Jiaxun Yang Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Rob Herring Cc: devicetree@vger.kernel.org Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 909b50e8e90d8cf10695d67c2e4df4cad9415755 Author: Serge Semin Date: Thu May 21 03:34:37 2020 +0300 mips: MAAR: Use more precise address mask [ Upstream commit bbb5946eb545fab8ad8f46bce8a803e1c0c39d47 ] Indeed according to the MIPS32 Privileged Resource Architecgture the MAAR pair register address field either takes [12:31] bits for non-XPA systems and [12:55] otherwise. In any case the current address mask is just wrong for 64-bit and 32-bits XPA chips. So lets extend it to 59-bits of physical address value. This shall cover the 64-bits architecture and systems with XPA enabled, and won't cause any problem for non-XPA 32-bit systems, since address values exceeding the architecture specific MAAR mask will be just truncated with setting zeros in the unsupported upper bits. Co-developed-by: Alexey Malahov Signed-off-by: Alexey Malahov Signed-off-by: Serge Semin Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Rob Herring Cc: devicetree@vger.kernel.org Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 9b7dbeedf864bfb701bd73287f93d5e4af4ef0f7 Author: Arvind Sankar Date: Fri Feb 7 16:49:26 2020 -0500 x86/boot: Correct relocation destination on old linkers [ Upstream commit 5214028dd89e49ba27007c3ee475279e584261f0 ] For the 32-bit kernel, as described in 6d92bc9d483a ("x86/build: Build compressed x86 kernels as PIE"), pre-2.26 binutils generates R_386_32 relocations in PIE mode. Since the startup code does not perform relocation, any reloc entry with R_386_32 will remain as 0 in the executing code. Commit 974f221c84b0 ("x86/boot: Move compressed kernel to the end of the decompression buffer") added a new symbol _end but did not mark it hidden, which doesn't give the correct offset on older linkers. This causes the compressed kernel to be copied beyond the end of the decompression buffer, rather than flush against it. This region of memory may be reserved or already allocated for other purposes by the bootloader. Mark _end as hidden to fix. This changes the relocation from R_386_32 to R_386_RELATIVE even on the pre-2.26 binutils. For 64-bit, this is not strictly necessary, as the 64-bit kernel is only built as PIE if the linker supports -z noreloc-overflow, which implies binutils-2.27+, but for consistency, mark _end as hidden here too. The below illustrates the before/after impact of the patch using binutils-2.25 and gcc-4.6.4 (locally compiled from source) and QEMU. Disassembly before patch: 48: 8b 86 60 02 00 00 mov 0x260(%esi),%eax 4e: 2d 00 00 00 00 sub $0x0,%eax 4f: R_386_32 _end Disassembly after patch: 48: 8b 86 60 02 00 00 mov 0x260(%esi),%eax 4e: 2d 00 f0 76 00 sub $0x76f000,%eax 4f: R_386_RELATIVE *ABS* Dump from extract_kernel before patch: early console in extract_kernel input_data: 0x0207c098 <--- this is at output + init_size input_len: 0x0074fef1 output: 0x01000000 output_len: 0x00fa63d0 kernel_total_size: 0x0107c000 needed_size: 0x0107c000 Dump from extract_kernel after patch: early console in extract_kernel input_data: 0x0190d098 <--- this is at output + init_size - _end input_len: 0x0074fef1 output: 0x01000000 output_len: 0x00fa63d0 kernel_total_size: 0x0107c000 needed_size: 0x0107c000 Fixes: 974f221c84b0 ("x86/boot: Move compressed kernel to the end of the decompression buffer") Signed-off-by: Arvind Sankar Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200207214926.3564079-1-nivedita@alum.mit.edu Signed-off-by: Sasha Levin commit be2ce1274a2fb6a0a65fced2fcf7ce284e5a578b Author: Pali Rohár Date: Fri May 15 09:59:24 2020 +0200 mwifiex: Fix memory corruption in dump_station [ Upstream commit 3aa42bae9c4d1641aeb36f1a8585cd1d506cf471 ] The mwifiex_cfg80211_dump_station() uses static variable for iterating over a linked list of all associated stations (when the driver is in UAP role). This has a race condition if .dump_station is called in parallel for multiple interfaces. This corruption can be triggered by registering multiple SSIDs and calling, in parallel for multiple interfaces iw dev station dump [16750.719775] Unable to handle kernel paging request at virtual address dead000000000110 ... [16750.899173] Call trace: [16750.901696] mwifiex_cfg80211_dump_station+0x94/0x100 [mwifiex] [16750.907824] nl80211_dump_station+0xbc/0x278 [cfg80211] [16750.913160] netlink_dump+0xe8/0x320 [16750.916827] netlink_recvmsg+0x1b4/0x338 [16750.920861] ____sys_recvmsg+0x7c/0x2b0 [16750.924801] ___sys_recvmsg+0x70/0x98 [16750.928564] __sys_recvmsg+0x58/0xa0 [16750.932238] __arm64_sys_recvmsg+0x28/0x30 [16750.936453] el0_svc_common.constprop.3+0x90/0x158 [16750.941378] do_el0_svc+0x74/0x90 [16750.944784] el0_sync_handler+0x12c/0x1a8 [16750.948903] el0_sync+0x114/0x140 [16750.952312] Code: f9400003 f907f423 eb02007f 54fffd60 (b9401060) [16750.958583] ---[ end trace c8ad181c2f4b8576 ]--- This patch drops the use of the static iterator, and instead every time the function is called iterates to the idx-th position of the linked-list. It would be better to convert the code not to use linked list for associated stations storage (since the chip has a limited number of associated stations anyway - it could just be an array). Such a change may be proposed in the future. In the meantime this patch can backported into stable kernels in this simple form. Fixes: 8baca1a34d4c ("mwifiex: dump station support in uap mode") Signed-off-by: Pali Rohár Acked-by: Ganapathi Bhat Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200515075924.13841-1-pali@kernel.org Signed-off-by: Sasha Levin commit 2048a786f5a971452153a488a76f76bfd3a3362e Author: Dan Carpenter Date: Wed May 13 12:39:51 2020 +0300 rtlwifi: Fix a double free in _rtl_usb_tx_urb_setup() [ Upstream commit beb12813bc75d4a23de43b85ad1c7cb28d27631e ] Seven years ago we tried to fix a leak but actually introduced a double free instead. It was an understandable mistake because the code was a bit confusing and the free was done in the wrong place. The "skb" pointer is freed in both _rtl_usb_tx_urb_setup() and _rtl_usb_transmit(). The free belongs _rtl_usb_transmit() instead of _rtl_usb_tx_urb_setup() and I've cleaned the code up a bit to hopefully make it more clear. Fixes: 36ef0b473fbf ("rtlwifi: usb: add missing freeing of skbuff") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200513093951.GD347693@mwanda Signed-off-by: Sasha Levin commit dfca13aa8008acf97875f79064909c167a9774df Author: Erez Shitrit Date: Mon May 4 11:46:25 2020 +0300 net/mlx5e: IPoIB, Drop multicast packets that this interface sent [ Upstream commit 8b46d424a743ddfef8056d5167f13ee7ebd1dcad ] After enabled loopback packets for IPoIB, we need to drop these packets that this HCA has replicated and came back to the same interface that sent them. Fixes: 4c6c615e3f30 ("net/mlx5e: IPoIB, Add PKEY child interface nic profile") Signed-off-by: Erez Shitrit Reviewed-by: Alex Vesker Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit b6c90a7d0a3875fbdc1dac8b4c61a7810cd401c6 Author: Jesper Dangaard Brouer Date: Thu May 14 12:49:43 2020 +0200 veth: Adjust hard_start offset on redirect XDP frames [ Upstream commit 5c8572251fabc5bb49fd623c064e95a9daf6a3e3 ] When native XDP redirect into a veth device, the frame arrives in the xdp_frame structure. It is then processed in veth_xdp_rcv_one(), which can run a new XDP bpf_prog on the packet. Doing so requires converting xdp_frame to xdp_buff, but the tricky part is that xdp_frame memory area is located in the top (data_hard_start) memory area that xdp_buff will point into. The current code tried to protect the xdp_frame area, by assigning xdp_buff.data_hard_start past this memory. This results in 32 bytes less headroom to expand into via BPF-helper bpf_xdp_adjust_head(). This protect step is actually not needed, because BPF-helper bpf_xdp_adjust_head() already reserve this area, and don't allow BPF-prog to expand into it. Thus, it is safe to point data_hard_start directly at xdp_frame memory area. Fixes: 9fc8d518d9d5 ("veth: Handle xdp_frames in xdp napi ring") Reported-by: Mao Wenan Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Acked-by: Toshiaki Makita Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/158945338331.97035.5923525383710752178.stgit@firesoul Signed-off-by: Sasha Levin commit 868b8e43a03d8587900186aa0338809640149d17 Author: Guoqing Jiang Date: Sat Apr 4 23:57:09 2020 +0200 md: don't flush workqueue unconditionally in md_open [ Upstream commit f6766ff6afff70e2aaf39e1511e16d471de7c3ae ] We need to check mddev->del_work before flush workqueu since the purpose of flush is to ensure the previous md is disappeared. Otherwise the similar deadlock appeared if LOCKDEP is enabled, it is due to md_open holds the bdev->bd_mutex before flush workqueue. kernel: [ 154.522645] ====================================================== kernel: [ 154.522647] WARNING: possible circular locking dependency detected kernel: [ 154.522650] 5.6.0-rc7-lp151.27-default #25 Tainted: G O kernel: [ 154.522651] ------------------------------------------------------ kernel: [ 154.522653] mdadm/2482 is trying to acquire lock: kernel: [ 154.522655] ffff888078529128 ((wq_completion)md_misc){+.+.}, at: flush_workqueue+0x84/0x4b0 kernel: [ 154.522673] kernel: [ 154.522673] but task is already holding lock: kernel: [ 154.522675] ffff88804efa9338 (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x79/0x590 kernel: [ 154.522691] kernel: [ 154.522691] which lock already depends on the new lock. kernel: [ 154.522691] kernel: [ 154.522694] kernel: [ 154.522694] the existing dependency chain (in reverse order) is: kernel: [ 154.522696] kernel: [ 154.522696] -> #4 (&bdev->bd_mutex){+.+.}: kernel: [ 154.522704] __mutex_lock+0x87/0x950 kernel: [ 154.522706] __blkdev_get+0x79/0x590 kernel: [ 154.522708] blkdev_get+0x65/0x140 kernel: [ 154.522709] blkdev_get_by_dev+0x2f/0x40 kernel: [ 154.522716] lock_rdev+0x3d/0x90 [md_mod] kernel: [ 154.522719] md_import_device+0xd6/0x1b0 [md_mod] kernel: [ 154.522723] new_dev_store+0x15e/0x210 [md_mod] kernel: [ 154.522728] md_attr_store+0x7a/0xc0 [md_mod] kernel: [ 154.522732] kernfs_fop_write+0x117/0x1b0 kernel: [ 154.522735] vfs_write+0xad/0x1a0 kernel: [ 154.522737] ksys_write+0xa4/0xe0 kernel: [ 154.522745] do_syscall_64+0x64/0x2b0 kernel: [ 154.522748] entry_SYSCALL_64_after_hwframe+0x49/0xbe kernel: [ 154.522749] kernel: [ 154.522749] -> #3 (&mddev->reconfig_mutex){+.+.}: kernel: [ 154.522752] __mutex_lock+0x87/0x950 kernel: [ 154.522756] new_dev_store+0xc9/0x210 [md_mod] kernel: [ 154.522759] md_attr_store+0x7a/0xc0 [md_mod] kernel: [ 154.522761] kernfs_fop_write+0x117/0x1b0 kernel: [ 154.522763] vfs_write+0xad/0x1a0 kernel: [ 154.522765] ksys_write+0xa4/0xe0 kernel: [ 154.522767] do_syscall_64+0x64/0x2b0 kernel: [ 154.522769] entry_SYSCALL_64_after_hwframe+0x49/0xbe kernel: [ 154.522770] kernel: [ 154.522770] -> #2 (kn->count#253){++++}: kernel: [ 154.522775] __kernfs_remove+0x253/0x2c0 kernel: [ 154.522778] kernfs_remove+0x1f/0x30 kernel: [ 154.522780] kobject_del+0x28/0x60 kernel: [ 154.522783] mddev_delayed_delete+0x24/0x30 [md_mod] kernel: [ 154.522786] process_one_work+0x2a7/0x5f0 kernel: [ 154.522788] worker_thread+0x2d/0x3d0 kernel: [ 154.522793] kthread+0x117/0x130 kernel: [ 154.522795] ret_from_fork+0x3a/0x50 kernel: [ 154.522796] kernel: [ 154.522796] -> #1 ((work_completion)(&mddev->del_work)){+.+.}: kernel: [ 154.522800] process_one_work+0x27e/0x5f0 kernel: [ 154.522802] worker_thread+0x2d/0x3d0 kernel: [ 154.522804] kthread+0x117/0x130 kernel: [ 154.522806] ret_from_fork+0x3a/0x50 kernel: [ 154.522807] kernel: [ 154.522807] -> #0 ((wq_completion)md_misc){+.+.}: kernel: [ 154.522813] __lock_acquire+0x1392/0x1690 kernel: [ 154.522816] lock_acquire+0xb4/0x1a0 kernel: [ 154.522818] flush_workqueue+0xab/0x4b0 kernel: [ 154.522821] md_open+0xb6/0xc0 [md_mod] kernel: [ 154.522823] __blkdev_get+0xea/0x590 kernel: [ 154.522825] blkdev_get+0x65/0x140 kernel: [ 154.522828] do_dentry_open+0x1d1/0x380 kernel: [ 154.522831] path_openat+0x567/0xcc0 kernel: [ 154.522834] do_filp_open+0x9b/0x110 kernel: [ 154.522836] do_sys_openat2+0x201/0x2a0 kernel: [ 154.522838] do_sys_open+0x57/0x80 kernel: [ 154.522840] do_syscall_64+0x64/0x2b0 kernel: [ 154.522842] entry_SYSCALL_64_after_hwframe+0x49/0xbe kernel: [ 154.522844] kernel: [ 154.522844] other info that might help us debug this: kernel: [ 154.522844] kernel: [ 154.522846] Chain exists of: kernel: [ 154.522846] (wq_completion)md_misc --> &mddev->reconfig_mutex --> &bdev->bd_mutex kernel: [ 154.522846] kernel: [ 154.522850] Possible unsafe locking scenario: kernel: [ 154.522850] kernel: [ 154.522852] CPU0 CPU1 kernel: [ 154.522853] ---- ---- kernel: [ 154.522854] lock(&bdev->bd_mutex); kernel: [ 154.522856] lock(&mddev->reconfig_mutex); kernel: [ 154.522858] lock(&bdev->bd_mutex); kernel: [ 154.522860] lock((wq_completion)md_misc); kernel: [ 154.522861] kernel: [ 154.522861] *** DEADLOCK *** kernel: [ 154.522861] kernel: [ 154.522864] 1 lock held by mdadm/2482: kernel: [ 154.522865] #0: ffff88804efa9338 (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x79/0x590 kernel: [ 154.522868] kernel: [ 154.522868] stack backtrace: kernel: [ 154.522873] CPU: 1 PID: 2482 Comm: mdadm Tainted: G O 5.6.0-rc7-lp151.27-default #25 kernel: [ 154.522875] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 kernel: [ 154.522878] Call Trace: kernel: [ 154.522881] dump_stack+0x8f/0xcb kernel: [ 154.522884] check_noncircular+0x194/0x1b0 kernel: [ 154.522888] ? __lock_acquire+0x1392/0x1690 kernel: [ 154.522890] __lock_acquire+0x1392/0x1690 kernel: [ 154.522893] lock_acquire+0xb4/0x1a0 kernel: [ 154.522895] ? flush_workqueue+0x84/0x4b0 kernel: [ 154.522898] flush_workqueue+0xab/0x4b0 kernel: [ 154.522900] ? flush_workqueue+0x84/0x4b0 kernel: [ 154.522905] ? md_open+0xb6/0xc0 [md_mod] kernel: [ 154.522908] md_open+0xb6/0xc0 [md_mod] kernel: [ 154.522910] __blkdev_get+0xea/0x590 kernel: [ 154.522912] ? bd_acquire+0xc0/0xc0 kernel: [ 154.522914] blkdev_get+0x65/0x140 kernel: [ 154.522916] ? bd_acquire+0xc0/0xc0 kernel: [ 154.522918] do_dentry_open+0x1d1/0x380 kernel: [ 154.522921] path_openat+0x567/0xcc0 kernel: [ 154.522923] ? __lock_acquire+0x380/0x1690 kernel: [ 154.522926] do_filp_open+0x9b/0x110 kernel: [ 154.522929] ? __alloc_fd+0xe5/0x1f0 kernel: [ 154.522935] ? kmem_cache_alloc+0x28c/0x630 kernel: [ 154.522939] ? do_sys_openat2+0x201/0x2a0 kernel: [ 154.522941] do_sys_openat2+0x201/0x2a0 kernel: [ 154.522944] do_sys_open+0x57/0x80 kernel: [ 154.522946] do_syscall_64+0x64/0x2b0 kernel: [ 154.522948] entry_SYSCALL_64_after_hwframe+0x49/0xbe kernel: [ 154.522951] RIP: 0033:0x7f98d279d9ae And md_alloc also flushed the same workqueue, but the thing is different here. Because all the paths call md_alloc don't hold bdev->bd_mutex, and the flush is necessary to avoid race condition, so leave it as it is. Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 13964369dc8021af4988f2cc4051a703efd8650a Author: Ryder Lee Date: Sat Apr 25 03:32:22 2020 +0800 mt76: avoid rx reorder buffer overflow [ Upstream commit 7c4f744d6703757be959f521a7a441bf34745d99 ] Enlarge slot to support 11ax 256 BA (256 MPDUs in an AMPDU) Signed-off-by: Chih-Min Chen Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 35fde8a69bd66f377c3e9a76ad56478e999ef2bd Author: Bhupesh Sharma Date: Mon May 11 15:41:41 2020 +0530 net: qed*: Reduce RX and TX default ring count when running inside kdump kernel [ Upstream commit 73e030977f7884dbe1be0018bab517e8d02760f8 ] Normally kdump kernel(s) run under severe memory constraint with the basic idea being to save the crashdump vmcore reliably when the primary kernel panics/hangs. Currently the qed* ethernet driver ends up consuming a lot of memory in the kdump kernel, leading to kdump kernel panic when one tries to save the vmcore via ssh/nfs (thus utilizing the services of the underlying qed* network interfaces). An example OOM message log seen in the kdump kernel can be seen here [1], with crashkernel size reservation of 512M. Using tools like memstrack (see [2]), we can track the modules taking up the bulk of memory in the kdump kernel and organize the memory usage output as per 'highest allocator first'. An example log for the OOM case indicates that the qed* modules end up allocating approximately 216M memory, which is a large part of the total crashkernel size: dracut-pre-pivot[676]: ======== Report format module_summary: ======== dracut-pre-pivot[676]: Module qed using 149.6MB (2394 pages), peak allocation 149.6MB (2394 pages) dracut-pre-pivot[676]: Module qede using 65.3MB (1045 pages), peak allocation 65.3MB (1045 pages) This patch reduces the default RX and TX ring count from 1024 to 64 when running inside kdump kernel, which leads to a significant memory saving. An example log with the patch applied shows the reduced memory allocation in the kdump kernel: dracut-pre-pivot[674]: ======== Report format module_summary: ======== dracut-pre-pivot[674]: Module qed using 141.8MB (2268 pages), peak allocation 141.8MB (2268 pages) <..snip..> [dracut-pre-pivot[674]: Module qede using 4.8MB (76 pages), peak allocation 4.9MB (78 pages) Tested crashdump vmcore save via ssh/nfs protocol using underlying qed* network interface after applying this patch. [1] OOM log: ------------ kworker/0:6: page allocation failure: order:6, mode:0x60c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null) kworker/0:6 cpuset=/ mems_allowed=0 CPU: 0 PID: 145 Comm: kworker/0:6 Not tainted 4.18.0-109.el8.aarch64 #1 Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL025 01/18/2019 Workqueue: events work_for_cpu_fn Call trace: dump_backtrace+0x0/0x188 show_stack+0x24/0x30 dump_stack+0x90/0xb4 warn_alloc+0xf4/0x178 __alloc_pages_nodemask+0xcac/0xd58 alloc_pages_current+0x8c/0xf8 kmalloc_order_trace+0x38/0x108 qed_iov_alloc+0x40/0x248 [qed] qed_resc_alloc+0x224/0x518 [qed] qed_slowpath_start+0x254/0x928 [qed] __qede_probe+0xf8/0x5e0 [qede] qede_probe+0x68/0xd8 [qede] local_pci_probe+0x44/0xa8 work_for_cpu_fn+0x20/0x30 process_one_work+0x1ac/0x3e8 worker_thread+0x44/0x448 kthread+0x130/0x138 ret_from_fork+0x10/0x18 Cannot start slowpath qede: probe of 0000:05:00.1 failed with error -12 [2]. Memstrack tool: https://github.com/ryncsn/memstrack Cc: kexec@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: Ariel Elior Cc: GR-everest-linux-l2@marvell.com Cc: Manish Chopra Cc: David S. Miller Signed-off-by: Bhupesh Sharma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ef93244e55ed9bc7bec0737927f527e7d66bdddc Author: Christophe JAILLET Date: Fri May 8 05:56:03 2020 +0300 wcn36xx: Fix error handling path in 'wcn36xx_probe()' [ Upstream commit a86308fc534edeceaf64670c691e17485436a4f4 ] In case of error, 'qcom_wcnss_open_channel()' must be undone by a call to 'rpmsg_destroy_ept()', as already done in the remove function. Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Signed-off-by: Christophe JAILLET Reviewed-by: Bjorn Andersson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200507043619.200051-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 2bc8b1816cf4908ae0a04c3e87e167d2dcb60f38 Author: Rakesh Pillai Date: Fri May 8 05:55:18 2020 +0300 ath10k: Remove msdu from idr when management pkt send fails [ Upstream commit c730c477176ad4af86d9aae4d360a7ad840b073a ] Currently when the sending of any management pkt via wmi command fails, the packet is being unmapped freed in the error handling. But the idr entry added, which is used to track these packet is not getting removed. Hence, during unload, in wmi cleanup, all the entries in IDR are removed and the corresponding buffer is attempted to be freed. This can cause a situation where one packet is attempted to be freed twice. Fix this error by rmeoving the msdu from the idr list when the sending of a management packet over wmi fails. Tested HW: WCN3990 Tested FW: WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1 Fixes: 1807da49733e ("ath10k: wmi: add management tx by reference support over wmi") Signed-off-by: Rakesh Pillai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1588667015-25490-1-git-send-email-pillair@codeaurora.org Signed-off-by: Sasha Levin commit 15757cfd011d5a8ead6d6c9203ad97f2d0ba8411 Author: Christoph Hellwig Date: Sat Apr 4 10:11:28 2020 +0200 nvme: refine the Qemu Identify CNS quirk [ Upstream commit b9a5c3d4c34d8bd9fd75f7f28d18a57cb68da237 ] Add a helper to check if we can use Identify CNS values > 1, and refine the Qemu quirk to not apply to reported versions larger than 1.1, as the Qemu implementation had been fixed by then. Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a323c77b53cae7c2ba6a6a59584341476bb5c600 Author: Hans de Goede Date: Sat May 2 20:29:50 2020 +0200 platform/x86: intel-vbtn: Also handle tablet-mode switch on "Detachable" and "Portable" chassis-types [ Upstream commit 1fac39fd0316b19c3e57a182524332332d1643ce ] Commit de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's") added a DMI chassis-type check to avoid accidentally reporting SW_TABLET_MODE = 1 to userspace on laptops. Some devices with a detachable keyboard and using the intel-vbnt (INT33D6) interface to report if they are in tablet mode (keyboard detached) or not, report 32 / "Detachable" as chassis-type, e.g. the HP Pavilion X2 series. Other devices with a detachable keyboard and using the intel-vbnt (INT33D6) interface to report SW_TABLET_MODE, report 8 / "Portable" as chassis-type. The Dell Venue 11 Pro 7130 is an example of this. Extend the DMI chassis-type check to also accept Portables and Detachables so that the intel-vbtn driver will report SW_TABLET_MODE on these devices. Note the chassis-type check was originally added to avoid a false-positive tablet-mode report on the Dell XPS 9360 laptop. To the best of my knowledge that laptop is using a chassis-type of 9 / "Laptop", so after this commit we still ignore the tablet-switch for that chassis-type. Fixes: de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's") Signed-off-by: Hans de Goede Reviewed-by: Mario Limonciello Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit eeb28a17ce58cbc23b523348cbc087d19e8b1f9a Author: Hans de Goede Date: Sat May 2 20:29:49 2020 +0200 platform/x86: intel-vbtn: Do not advertise switches to userspace if they are not there [ Upstream commit 990fbb48067bf8cfa34b7d1e6e1674eaaef2f450 ] Commit de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's") added a DMI chassis-type check to avoid accidentally reporting SW_TABLET_MODE = 1 to userspace on laptops (specifically on the Dell XPS 9360), to avoid e.g. userspace ignoring touchpad events because userspace thought the device was in tablet-mode. But if we are not getting the initial status of the switch because the device does not have a tablet mode, then we really should not advertise the presence of a tablet-mode switch to userspace at all, as userspace may use the mere presence of this switch for certain heuristics. Fixes: de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's") Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit acb3848de0d05757d442b6a991f8bb26d5369303 Author: Hans de Goede Date: Sat May 2 20:29:48 2020 +0200 platform/x86: intel-vbtn: Split keymap into buttons and switches parts [ Upstream commit f6ba524970c4b73b234bf41ecd6628f5803b1559 ] Split the sparse keymap into 2 separate keymaps, a buttons and a switches keymap and combine the 2 to a single map again in intel_vbtn_input_setup(). This is a preparation patch for not telling userspace that we have switches when we do not have them (and for doing the same for the buttons). Fixes: de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's") Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit e8ffc604cc958eea5f5831bb586c35607608451a Author: Hans de Goede Date: Sat May 2 20:29:47 2020 +0200 platform/x86: intel-vbtn: Use acpi_evaluate_integer() [ Upstream commit 18937875a231d831c309716d6d8fc358f8381881 ] Use acpi_evaluate_integer() instead of open-coding it. This is a preparation patch for adding a intel_vbtn_has_switches() helper function. Fixes: de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's") Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit edd948273038641da2aafa666a6666d6928777ee Author: Brian Foster Date: Wed May 6 13:25:22 2020 -0700 xfs: fix duplicate verification from xfs_qm_dqflush() [ Upstream commit 629dcb38dc351947ed6a26a997d4b587f3bd5c7e ] The pre-flush dquot verification in xfs_qm_dqflush() duplicates the read verifier by checking the dquot in the on-disk buffer. Instead, verify the in-core variant before it is flushed to the buffer. Fixes: 7224fa482a6d ("xfs: add full xfs_dqblk verifier") Signed-off-by: Brian Foster Reviewed-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Allison Collins Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit cc9485cd593f1fb306b78c25a5aaca5d5c4510b7 Author: Brian Foster Date: Wed May 6 13:25:20 2020 -0700 xfs: reset buffer write failure state on successful completion [ Upstream commit b6983e80b03bd4fd42de71993b3ac7403edac758 ] The buffer write failure flag is intended to control the internal write retry that XFS has historically implemented to help mitigate the severity of transient I/O errors. The flag is set when a buffer is resubmitted from the I/O completion path due to a previous failure. It is checked on subsequent I/O completions to skip the internal retry and fall through to the higher level configurable error handling mechanism. The flag is cleared in the synchronous and delwri submission paths and also checked in various places to log write failure messages. There are a couple minor problems with the current usage of this flag. One is that we issue an internal retry after every submission from xfsaild due to how delwri submission clears the flag. This results in double the expected or configured number of write attempts when under sustained failures. Another more subtle issue is that the flag is never cleared on successful I/O completion. This can cause xfs_wait_buftarg() to suggest that dirty buffers are being thrown away due to the existence of the flag, when the reality is that the flag might still be set because the write succeeded on the retry. Clear the write failure flag on successful I/O completion to address both of these problems. This means that the internal retry attempt occurs once since the last time a buffer write failed and that various other contexts only see the flag set when the immediately previous write attempt has failed. Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Allison Collins Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 875e941843112c141f48cb4d1e20b2a4d312c143 Author: Daniel Thompson Date: Wed May 6 17:42:23 2020 +0100 kgdb: Fix spurious true from in_dbg_master() [ Upstream commit 3fec4aecb311995189217e64d725cfe84a568de3 ] Currently there is a small window where a badly timed migration could cause in_dbg_master() to spuriously return true. Specifically if we migrate to a new core after reading the processor id and the previous core takes a breakpoint then we will evaluate true if we read kgdb_active before we get the IPI to bring us to halt. Fix this by checking irqs_disabled() first. Interrupts are always disabled when we are executing the kgdb trap so this is an acceptable prerequisite. This also allows us to replace raw_smp_processor_id() with smp_processor_id() since the short circuit logic will prevent warnings from PREEMPT_DEBUG. Fixes: dcc7871128e9 ("kgdb: core changes to support kdb") Suggested-by: Will Deacon Link: https://lore.kernel.org/r/20200506164223.2875760-1-daniel.thompson@linaro.org Reviewed-by: Douglas Anderson Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit d31ac33174303418dbe533deafdf2333abd0c693 Author: Serge Semin Date: Wed May 6 20:42:22 2020 +0300 mips: cm: Fix an invalid error code of INTVN_*_ERR [ Upstream commit 8a0efb8b101665a843205eab3d67ab09cb2d9a8d ] Commit 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache errors") adds cm2_causes[] array with map of error type ID and pointers to the short description string. There is a mistake in the table, since according to MIPS32 manual CM2_ERROR_TYPE = {17,18} correspond to INTVN_WR_ERR and INTVN_RD_ERR, while the table claims they have {0x17,0x18} codes. This is obviously hex-dec copy-paste bug. Moreover codes {0x18 - 0x1a} indicate L2 ECC errors. Fixes: 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache errors") Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Rob Herring Cc: linux-pm@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 7ac70ff8e2674d6df73c292aeeea7ba102084d16 Author: Jiaxun Yang Date: Wed May 6 13:52:45 2020 +0800 MIPS: Truncate link address into 32bit for 32bit kernel [ Upstream commit ff487d41036035376e47972c7c522490b839ab37 ] LLD failed to link vmlinux with 64bit load address for 32bit ELF while bfd will strip 64bit address into 32bit silently. To fix LLD build, we should truncate load address provided by platform into 32bit for 32bit kernel. Signed-off-by: Jiaxun Yang Link: https://github.com/ClangBuiltLinux/linux/issues/786 Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784 Reviewed-by: Fangrui Song Reviewed-by: Kees Cook Tested-by: Nathan Chancellor Cc: Maciej W. Rozycki Tested-by: Nick Desaulniers Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 6d0f96ade36f1ee3d58725c74aeaf9966a3271bb Author: Devulapally Shiva Krishna Date: Tue May 5 08:42:55 2020 +0530 Crypto/chcr: fix for ccm(aes) failed test [ Upstream commit 10b0c75d7bc19606fa9a62c8ab9180e95c0e0385 ] The ccm(aes) test fails when req->assoclen > ~240bytes. The problem is the value assigned to auth_offset is wrong. As auth_offset is unsigned char, it can take max value as 255. So fix it by making it unsigned int. Signed-off-by: Ayush Sawal Signed-off-by: Devulapally Shiva Krishna Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c69572fd2ae04ca8f44336a0d602decf3ab3b689 Author: Darrick J. Wong Date: Mon May 4 14:06:27 2020 -0700 xfs: clean up the error handling in xfs_swap_extents [ Upstream commit 8bc3b5e4b70d28f8edcafc3c9e4de515998eea9e ] Make sure we release resources properly if we cannot clean out the COW extents in preparation for an extent swap. Fixes: 96987eea537d6c ("xfs: cancel COW blocks before swapext") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a8696209ca848f38f0ab6d22d9636479a0dfea2c Author: Jeremy Kerr Date: Tue May 5 12:12:50 2020 +0200 powerpc/spufs: fix copy_to_user while atomic [ Upstream commit 88413a6bfbbe2f648df399b62f85c934460b7a4d ] Currently, we may perform a copy_to_user (through simple_read_from_buffer()) while holding a context's register_lock, while accessing the context save area. This change uses a temporary buffer for the context save area data, which we then pass to simple_read_from_buffer. Includes changes from Christoph Hellwig . Fixes: bf1ab978be23 ("[POWERPC] coredump: Add SPU elf notes to coredump.") Signed-off-by: Jeremy Kerr Reviewed-by: Arnd Bergmann [hch: renamed to function to avoid ___-prefixes] Signed-off-by: Christoph Hellwig Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 1ac03c4b21aa3a177128785cc08ca1127390be05 Author: Yunjian Wang Date: Tue May 5 10:49:20 2020 +0800 net: allwinner: Fix use correct return type for ndo_start_xmit() [ Upstream commit 09f6c44aaae0f1bdb8b983d7762676d5018c53bc ] The method ndo_start_xmit() returns a value of type netdev_tx_t. Fix the ndo function to use the correct type. And emac_start_xmit() can leak one skb if 'channel' == 3. Signed-off-by: Yunjian Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 26311fa940bb07c553aa1c60244ef9ca6883cf87 Author: Dan Carpenter Date: Tue May 5 10:25:56 2020 +0200 media: cec: silence shift wrapping warning in __cec_s_log_addrs() [ Upstream commit 3b5af3171e2d5a73ae6f04965ed653d039904eb6 ] The log_addrs->log_addr_type[i] value is a u8 which is controlled by the user and comes from the ioctl. If it's over 31 then that results in undefined behavior (shift wrapping) and that leads to a Smatch static checker warning. We already cap the value later so we can silence the warning just by re-ordering the existing checks. I think the UBSan checker will also catch this bug at runtime and generate a warning. But otherwise the bug is harmless. Fixes: 9881fe0ca187 ("[media] cec: add HDMI CEC framework (adapter)") Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b0687a01d693de6f482655f979f4979b1011a013 Author: Wei Yongjun Date: Mon Apr 27 12:15:07 2020 +0000 net: lpc-enet: fix error return code in lpc_mii_init() [ Upstream commit 88ec7cb22ddde725ed4ce15991f0bd9dd817fd85 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: b7370112f519 ("lpc32xx: Added ethernet driver") Signed-off-by: Wei Yongjun Acked-by: Vladimir Zapolskiy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9b33fbf99dc34b96de7948cdf6828854536a8976 Author: Shaokun Zhang Date: Thu Apr 23 20:05:30 2020 +0800 drivers/perf: hisi: Fix typo in events attribute array [ Upstream commit 88562f06ebf56587788783e5420f25fde3ca36c8 ] Fix up one typo: wr_dr_64b -> wr_ddr_64b. Fixes: 2bab3cf9104c ("perf: hisi: Add support for HiSilicon SoC HHA PMU driver") Signed-off-by: Shaokun Zhang Cc: Will Deacon Cc: Mark Rutland Link: https://lore.kernel.org/r/1587643530-34357-1-git-send-email-zhangshaokun@hisilicon.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 373491f1f41896241864b527b584856d8a510946 Author: Peter Zijlstra Date: Wed Apr 1 17:40:33 2020 -0400 sched/core: Fix illegal RCU from offline CPUs [ Upstream commit bf2c59fce4074e55d622089b34be3a6bc95484fb ] In the CPU-offline process, it calls mmdrop() after idle entry and the subsequent call to cpuhp_report_idle_dead(). Once execution passes the call to rcu_report_dead(), RCU is ignoring the CPU, which results in lockdep complaining when mmdrop() uses RCU from either memcg or debugobjects below. Fix it by cleaning up the active_mm state from BP instead. Every arch which has CONFIG_HOTPLUG_CPU should have already called idle_task_exit() from AP. The only exception is parisc because it switches them to &init_mm unconditionally (see smp_boot_one_cpu() and smp_cpu_init()), but the patch will still work there because it calls mmgrab(&init_mm) in smp_cpu_init() and then should call mmdrop(&init_mm) in finish_cpu(). WARNING: suspicious RCU usage ----------------------------- kernel/workqueue.c:710 RCU or wq_pool_mutex should be held! other info that might help us debug this: RCU used illegally from offline CPU! Call Trace: dump_stack+0xf4/0x164 (unreliable) lockdep_rcu_suspicious+0x140/0x164 get_work_pool+0x110/0x150 __queue_work+0x1bc/0xca0 queue_work_on+0x114/0x120 css_release+0x9c/0xc0 percpu_ref_put_many+0x204/0x230 free_pcp_prepare+0x264/0x570 free_unref_page+0x38/0xf0 __mmdrop+0x21c/0x2c0 idle_task_exit+0x170/0x1b0 pnv_smp_cpu_kill_self+0x38/0x2e0 cpu_die+0x48/0x64 arch_cpu_idle_dead+0x30/0x50 do_idle+0x2f4/0x470 cpu_startup_entry+0x38/0x40 start_secondary+0x7a8/0xa80 start_secondary_resume+0x10/0x14 Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Qian Cai Signed-off-by: Peter Zijlstra (Intel) Acked-by: Michael Ellerman (powerpc) Link: https://lkml.kernel.org/r/20200401214033.8448-1-cai@lca.pw Signed-off-by: Sasha Levin commit fb020dcd627544e71a34cea6e117ff1a5a0d73c2 Author: Jann Horn Date: Thu Mar 5 23:06:57 2020 +0100 exit: Move preemption fixup up, move blocking operations down [ Upstream commit 586b58cac8b4683eb58a1446fbc399de18974e40 ] With CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_CGROUPS=y, kernel oopses in non-preemptible context look untidy; after the main oops, the kernel prints a "sleeping function called from invalid context" report because exit_signals() -> cgroup_threadgroup_change_begin() -> percpu_down_read() can sleep, and that happens before the preempt_count_set(PREEMPT_ENABLED) fixup. It looks like the same thing applies to profile_task_exit() and kcov_task_exit(). Fix it by moving the preemption fixup up and the calls to profile_task_exit() and kcov_task_exit() down. Fixes: 1dc0fffc48af ("sched/core: Robustify preemption leak checks") Signed-off-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200305220657.46800-1-jannh@google.com Signed-off-by: Sasha Levin commit 831900a329849d1d78a90790567d50301ce1182f Author: Nathan Chancellor Date: Tue Apr 21 14:47:04 2020 -0700 lib/mpi: Fix 64-bit MIPS build with Clang [ Upstream commit 18f1ca46858eac22437819937ae44aa9a8f9f2fa ] When building 64r6_defconfig with CONFIG_MIPS32_O32 disabled and CONFIG_CRYPTO_RSA enabled: lib/mpi/generic_mpih-mul1.c:37:24: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb); ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/mpi/longlong.h:664:22: note: expanded from macro 'umul_ppmm' : "=d" ((UDItype)(w0)) ~~~~~~~~~~^~~ lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb); ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/mpi/longlong.h:668:22: note: expanded from macro 'umul_ppmm' : "=d" ((UDItype)(w1)) ~~~~~~~~~~^~~ 2 errors generated. This special case for umul_ppmm for MIPS64r6 was added in commit bbc25bee37d2b ("lib/mpi: Fix umul_ppmm() for MIPS64r6"), due to GCC being inefficient and emitting a __multi3 intrinsic. There is no such issue with clang; with this patch applied, I can build this configuration without any problems and there are no link errors like mentioned in the commit above (which I can still reproduce with GCC 9.3.0 when that commit is reverted). Only use this definition when GCC is being used. This really should have been caught by commit b0c091ae04f67 ("lib/mpi: Eliminate unused umul_ppmm definitions for MIPS") when I was messing around in this area but I was not testing 64-bit MIPS at the time. Link: https://github.com/ClangBuiltLinux/linux/issues/885 Reported-by: Dmitry Golovin Signed-off-by: Nathan Chancellor Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9226fccf008442daba59dfa02ca6670c7230bfef Author: Doug Berger Date: Wed Apr 29 13:02:00 2020 -0700 net: bcmgenet: set Rx mode before starting netif [ Upstream commit 72f96347628e73dbb61b307f18dd19293cc6792a ] This commit explicitly calls the bcmgenet_set_rx_mode() function when the network interface is started. This function is normally called by ndo_set_rx_mode when the flags are changed, but apparently not when the driver is suspended and resumed. This change ensures that address filtering or promiscuous mode are properly restored by the driver after the MAC may have been reset. Fixes: b6e978e50444 ("net: bcmgenet: add suspend/resume callbacks") Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3cea36c903da102cd81307bc2c9a07f212fd6f39 Author: Andrii Nakryiko Date: Tue Apr 28 18:21:06 2020 -0700 selftests/bpf: Fix memory leak in extract_build_id() [ Upstream commit 9f56bb531a809ecaa7f0ddca61d2cf3adc1cb81a ] getline() allocates string, which has to be freed. Fixes: 81f77fd0deeb ("bpf: add selftest for stackmap with BPF_F_STACK_BUILD_ID") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Cc: Song Liu Link: https://lore.kernel.org/bpf/20200429012111.277390-7-andriin@fb.com Signed-off-by: Sasha Levin commit fbcd580375fe0740850ef62fb2be250abe8b56de Author: Pablo Neira Ayuso Date: Fri Apr 24 21:55:34 2020 +0200 netfilter: nft_nat: return EOPNOTSUPP if type or flags are not supported [ Upstream commit 0d7c83463fdf7841350f37960a7abadd3e650b41 ] Instead of EINVAL which should be used for malformed netlink messages. Fixes: eb31628e37a0 ("netfilter: nf_tables: Add support for IPv6 NAT") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4fe5dcafc74d9729e5f11f2d418c394eadbe0035 Author: Paul Moore Date: Tue Apr 21 09:10:56 2020 -0400 audit: fix a net reference leak in audit_list_rules_send() [ Upstream commit 3054d06719079388a543de6adb812638675ad8f5 ] If audit_list_rules_send() fails when trying to create a new thread to send the rules it also fails to cleanup properly, leaking a reference to a net structure. This patch fixes the error patch and renames audit_send_list() to audit_send_list_thread() to better match its cousin, audit_send_reply_thread(). Reported-by: teroincn@gmail.com Reviewed-by: Richard Guy Briggs Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit e366d4001a16d5f0b0b82ba59ef8bc5de18bdd55 Author: Hans de Goede Date: Fri Apr 17 19:15:32 2020 +0200 Bluetooth: btbcm: Add 2 missing models to subver tables [ Upstream commit c03ee9af4e07112bd3fc688daca9e654f41eca93 ] Currently the bcm_uart_subver_ and bcm_usb_subver_table-s lack entries for the BCM4324B5 and BCM20703A1 chipsets. This makes the code use just "BCM" as prefix for the filename to pass to request-firmware, making it harder for users to figure out which firmware they need. This especially is problematic with the UART attached BCM4324B5 where this leads to the filename being just "BCM.hcd". Add the 2 missing devices to subver tables. This has been tested on: 1. A Dell XPS15 9550 where this makes btbcm.c try to load "BCM20703A1-0a5c-6410.hcd" before it tries to load "BCM-0a5c-6410.hcd". 2. A Thinkpad 8 where this makes btbcm.c try to load "BCM4324B5.hcd" before it tries to load "BCM.hcd" Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 419fe4c9190c24de4fc90c1f839804c6bc5b7c2d Author: Tiezhu Yang Date: Tue Apr 21 19:59:46 2020 +0800 MIPS: Make sparse_init() using top-down allocation [ Upstream commit 269b3a9ac538c4ae87f84be640b9fa89914a2489 ] In the current code, if CONFIG_SWIOTLB is set, when failed to get IO TLB memory from the low pages by plat_swiotlb_setup(), it may lead to the boot process failed with kernel panic. (1) On the Loongson and SiByte platform arch/mips/loongson64/dma.c arch/mips/sibyte/common/dma.c void __init plat_swiotlb_setup(void) { swiotlb_init(1); } kernel/dma/swiotlb.c void __init swiotlb_init(int verbose) { ... vstart = memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE); if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose)) return; ... pr_warn("Cannot allocate buffer"); no_iotlb_memory = true; } phys_addr_t swiotlb_tbl_map_single() { ... if (no_iotlb_memory) panic("Can not allocate SWIOTLB buffer earlier ..."); ... } (2) On the Cavium OCTEON platform arch/mips/cavium-octeon/dma-octeon.c void __init plat_swiotlb_setup(void) { ... octeon_swiotlb = memblock_alloc_low(swiotlbsize, PAGE_SIZE); if (!octeon_swiotlb) panic("%s: Failed to allocate %zu bytes align=%lx\n", __func__, swiotlbsize, PAGE_SIZE); ... } Because IO_TLB_DEFAULT_SIZE is 64M, if the rest size of low memory is less than 64M when call plat_swiotlb_setup(), we can easily reproduce the panic case. In order to reduce the possibility of kernel panic when failed to get IO TLB memory under CONFIG_SWIOTLB, it is better to allocate low memory as small as possible before plat_swiotlb_setup(), so make sparse_init() using top-down allocation. Reported-by: Juxin Gao Co-developed-by: Juxin Gao Signed-off-by: Juxin Gao Signed-off-by: Tiezhu Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 1bab4e0d4d1e0269cd67a96781389a2393b4a4b8 Author: Kieran Bingham Date: Tue Apr 7 17:44:17 2020 +0200 media: platform: fcp: Set appropriate DMA parameters [ Upstream commit dd844fb8e50b12e65bbdc5746c9876c6735500df ] Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will enable extra validation on DMA operations ensuring that the size restraints are met. When using the FCP in conjunction with the VSP1/DU, and display frames, the size of the DMA operations is larger than the default maximum segment size reported by the DMA core (64K). With the DMA debug enabled, this produces a warning such as the following: "DMA-API: rcar-fcp fea27000.fcp: mapping sg segment longer than device claims to support [len=3145728] [max=65536]" We have no specific limitation on the segment size which isn't already handled by the VSP1/DU which actually handles the DMA allcoations and buffer management, so define a maximum segment size of up to 4GB (a 32 bit mask). Reported-by: Geert Uytterhoeven Fixes: 7b49235e83b2 ("[media] v4l: Add Renesas R-Car FCP driver") Signed-off-by: Kieran Bingham Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5d9560f9d171612bd0a07c6754ac05d072ce0518 Author: Colin Ian King Date: Mon Feb 10 18:51:33 2020 +0100 media: dvb: return -EREMOTEIO on i2c transfer failure. [ Upstream commit 96f3a9392799dd0f6472648a7366622ffd0989f3 ] Currently when i2c transfers fail the error return -EREMOTEIO is assigned to err but then later overwritten when the tuner attach call is made. Fix this by returning early with the error return code -EREMOTEIO on i2c transfer failure errors. If the transfer fails, an uninitialized value will be read from b2. Addresses-Coverity: ("Unused value") Fixes: fbfee8684ff2 ("V4L/DVB (5651): Dibusb-mb: convert pll handling to properly use dvb-pll") Signed-off-by: Colin Ian King Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6d2f2b4218ad6af229ccefb517193094b88939ca Author: Paul Moore Date: Mon Apr 20 10:09:29 2020 -0400 audit: fix a net reference leak in audit_send_reply() [ Upstream commit a48b284b403a4a073d8beb72d2bb33e54df67fb6 ] If audit_send_reply() fails when trying to create a new thread to send the reply it also fails to cleanup properly, leaking a reference to a net structure. This patch fixes the error path and makes a handful of other cleanups that came up while fixing the code. Reported-by: teroincn@gmail.com Reviewed-by: Richard Guy Briggs Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit c58e0d771b56fe241c6ff71704c6912a48e1b845 Author: Jitao Shi Date: Wed Apr 15 09:13:17 2020 +0800 dt-bindings: display: mediatek: control dpi pins mode to avoid leakage [ Upstream commit b0ff9b590733079f7f9453e5976a9dd2630949e3 ] Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set the dpi pins to gpio mode and output-low to avoid leakage current when dpi disabled. Acked-by: Rob Herring Signed-off-by: Jitao Shi Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 95d00778b239a24df59906f2694446142345405c Author: Kees Cook Date: Wed Feb 19 22:23:02 2020 -0800 e1000: Distribute switch variables for initialization [ Upstream commit a34c7f5156654ebaf7eaace102938be7ff7036cb ] Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, move such variables into the "case" where they're used or lift them up into the main function body. drivers/net/ethernet/intel/e1000/e1000_main.c: In function ‘e1000_xmit_frame’: drivers/net/ethernet/intel/e1000/e1000_main.c:3143:18: warning: statement will never be executed [-Wswitch-unreachable] 3143 | unsigned int pull_size; | ^~~~~~~~~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916 Signed-off-by: Kees Cook Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 0951c977abd3ff5b8cd038f365a3c2a31c8e944f Author: Stephane Eranian Date: Thu Apr 2 08:43:54 2020 -0700 tools api fs: Make xxx__mountpoint() more scalable [ Upstream commit c6fddb28bad26e5472cb7acf7b04cd5126f1a4ab ] The xxx_mountpoint() interface provided by fs.c finds mount points for common pseudo filesystems. The first time xxx_mountpoint() is invoked, it scans the mount table (/proc/mounts) looking for a match. If found, it is cached. The price to scan /proc/mounts is paid once if the mount is found. When the mount point is not found, subsequent calls to xxx_mountpoint() scan /proc/mounts over and over again. There is no caching. This causes a scaling issue in perf record with hugeltbfs__mountpoint(). The function is called for each process found in synthesize__mmap_events(). If the machine has thousands of processes and if the /proc/mounts has many entries this could cause major overhead in perf record. We have observed multi-second slowdowns on some configurations. As an example on a laptop: Before: $ sudo umount /dev/hugepages $ strace -e trace=openat -o /tmp/tt perf record -a ls $ fgrep mounts /tmp/tt 285 After: $ sudo umount /dev/hugepages $ strace -e trace=openat -o /tmp/tt perf record -a ls $ fgrep mounts /tmp/tt 1 One could argue that the non-caching in case the moint point is not found is intentional. That way subsequent calls may discover a moint point if the sysadmin mounts the filesystem. But the same argument could be made against caching the mount point. It could be unmounted causing errors. It all depends on the intent of the interface. This patch assumes it is expected to scan /proc/mounts once. The patch documents the caching behavior in the fs.h header file. An alternative would be to just fix perf record. But it would solve the problem with hugetlbs__mountpoint() but there could be similar issues (possibly down the line) with other xxx_mountpoint() calls in perf or other tools. Signed-off-by: Stephane Eranian Reviewed-by: Ian Rogers Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andrey Zhizhikin Cc: Kan Liang Cc: Kefeng Wang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Petr Mladek Cc: Thomas Gleixner Link: http://lore.kernel.org/lkml/20200402154357.107873-3-irogers@google.com Signed-off-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e12bc9cb438d67ddd64c596a907391d008248f7a Author: Jaehoon Chung Date: Mon Mar 30 14:25:28 2020 +0900 brcmfmac: fix wrong location to get firmware feature [ Upstream commit c57673852062428cdeabdd6501ac8b8e4c302067 ] sup_wpa feature is getting after setting feature_disable flag. If firmware is supported sup_wpa feature, it's always enabled regardless of feature_disable flag. Fixes: b8a64f0e96c2 ("brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK") Signed-off-by: Jaehoon Chung Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200330052528.10503-1-jh80.chung@samsung.com Signed-off-by: Sasha Levin commit 0c2e9cbe81a658f686b2d99bdc50ba587c29b535 Author: Christoph Hellwig Date: Mon Jun 1 21:50:23 2020 -0700 staging: android: ion: use vmap instead of vm_map_ram [ Upstream commit 5bf9917452112694b2c774465ee4dbe441c84b77 ] vm_map_ram can keep mappings around after the vm_unmap_ram. Using that with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues. Signed-off-by: Christoph Hellwig Signed-off-by: Andrew Morton Acked-by: Greg Kroah-Hartman Acked-by: Peter Zijlstra (Intel) Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Daniel Vetter Cc: David Airlie Cc: Gao Xiang Cc: Haiyang Zhang Cc: Johannes Weiner Cc: "K. Y. Srinivasan" Cc: Laura Abbott Cc: Mark Rutland Cc: Michael Kelley Cc: Minchan Kim Cc: Nitin Gupta Cc: Robin Murphy Cc: Sakari Ailus Cc: Stephen Hemminger Cc: Sumit Semwal Cc: Wei Liu Cc: Benjamin Herrenschmidt Cc: Catalin Marinas Cc: Heiko Carstens Cc: Paul Mackerras Cc: Vasily Gorbik Cc: Will Deacon Link: http://lkml.kernel.org/r/20200414131348.444715-4-hch@lst.de Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 38b5dc60dffc85d4779fdb4c634862c28b78136c Author: Jia-Ju Bai Date: Sat May 30 10:41:50 2020 +0800 net: vmxnet3: fix possible buffer overflow caused by bad DMA value in vmxnet3_get_rss() [ Upstream commit 3e1c6846b9e108740ef8a37be80314053f5dd52a ] The value adapter->rss_conf is stored in DMA memory, and it is assigned to rssConf, so rssConf->indTableSize can be modified at anytime by malicious hardware. Because rssConf->indTableSize is assigned to n, buffer overflow may occur when the code "rssConf->indTable[n]" is executed. To fix this possible bug, n is checked after being used. Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ff40b1166a2f7e7761ac9e0fe6d2975ef7f7335c Author: Jon Doron Date: Fri Apr 24 14:37:40 2020 +0300 x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit [ Upstream commit f7d31e65368aeef973fab788aa22c4f1d5a6af66 ] The problem the patch is trying to address is the fact that 'struct kvm_hyperv_exit' has different layout on when compiling in 32 and 64 bit modes. In 64-bit mode the default alignment boundary is 64 bits thus forcing extra gaps after 'type' and 'msr' but in 32-bit mode the boundary is at 32 bits thus no extra gaps. This is an issue as even when the kernel is 64 bit, the userspace using the interface can be both 32 and 64 bit but the same 32 bit userspace has to work with 32 bit kernel. The issue is fixed by forcing the 64 bit layout, this leads to ABI change for 32 bit builds and while we are obviously breaking '32 bit userspace with 32 bit kernel' case, we're fixing the '32 bit userspace with 64 bit kernel' one. As the interface has no (known) users and 32 bit KVM is rather baroque nowadays, this seems like a reasonable decision. Reviewed-by: Vitaly Kuznetsov Signed-off-by: Jon Doron Message-Id: <20200424113746.3473563-2-arilou@gmail.com> Reviewed-by: Roman Kagan Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 4d4d112dab0f7ba2b374264ec29c3d9405369fe5 Author: Serge Semin Date: Fri May 29 16:11:57 2020 +0300 spi: dw: Fix Rx-only DMA transfers [ Upstream commit 46164fde6b7890e7a3982d54549947c8394c0192 ] Tx-only DMA transfers are working perfectly fine since in this case the code just ignores the Rx FIFO overflow interrupts. But it turns out the SPI Rx-only transfers are broken since nothing pushing any data to the shift registers, so the Rx FIFO is left empty and the SPI core subsystems just returns a timeout error. Since DW DMAC driver doesn't support something like cyclic write operations of a single byte to a device register, the only way to support the Rx-only SPI transfers is to fake it by using a dummy Tx-buffer. This is what we intend to fix in this commit by setting the SPI_CONTROLLER_MUST_TX flag for DMA-capable platform. Signed-off-by: Serge Semin Reviewed-by: Andy Shevchenko Cc: Georgy Vlasov Cc: Ramil Zaripov Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Arnd Bergmann Cc: Feng Tang Cc: Rob Herring Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200529131205.31838-9-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a1bff0d3a6bf247e8cb02966fcd0df3658e48a23 Author: Martin Blumenstingl Date: Mon May 4 00:28:05 2020 +0200 mmc: meson-mx-sdio: trigger a soft reset after a timeout or CRC error [ Upstream commit 91995b904ec2e44b5c159ac6a5d3f154345a4de7 ] The vendor driver (from the 3.10 kernel) triggers a soft reset every time before starting a new command. While this fixes a problem where SDIO cards are not detected at all (because all commands simply timed out) this hurts SD card read performance a bit (in my tests between 10% to 20%). Trigger a soft reset after we got a CRC error or if the previous command timed out (just like the vendor driver from the same 3.10 kernel for the newer SDHC controller IP does). This fixes detection of SDIO cards and doesn't hurt SD card read performance at the same time. With this patch the initialization of an RTL8723BS SDIO card looks like this: req done (CMD52): -110: 00000000 00000000 00000000 00000000 clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 1 timing 0 starting CMD0 arg 00000000 flags 000000c0 req done (CMD0): 0: 00000000 00000000 00000000 00000000 clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 0 starting CMD8 arg 000001aa flags 000002f5 req done (CMD8): -110: 00000000 00000000 00000000 00000000 starting CMD5 arg 00000000 flags 000002e1 req done (CMD5): 0: 90ff0000 00000000 00000000 00000000 starting CMD5 arg 00200000 flags 000002e1 req done (CMD5): 0: 90ff0000 00000000 00000000 00000000 starting CMD3 arg 00000000 flags 00000075 req done (CMD3): 0: 00010000 00000000 00000000 00000000 starting CMD7 arg 00010000 flags 00000015 req done (CMD7): 0: 00001e00 00000000 00000000 00000000 starting CMD52 arg 00000000 flags 00000195 req done (CMD52): 0: 00001032 00000000 00000000 00000000 [... more CMD52 omitted ...] clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2 clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2 starting CMD52 arg 00000e00 flags 00000195 req done (CMD52): 0: 00001000 00000000 00000000 00000000 starting CMD52 arg 80000e02 flags 00000195 req done (CMD52): 0: 00001002 00000000 00000000 00000000 clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 4 timing 2 starting CMD52 arg 00020000 flags 00000195 req done (CMD52): 0: 00001007 00000000 00000000 00000000 [... more CMD52 omitted ...] new high speed SDIO card at address 0001 Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20200503222805.2668941-1-martin.blumenstingl@googlemail.com Tested-by: Tobias Baumann <017623705678@o2online.de> Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit f5dfbbee5d4c1f69168cdd72c8a6ac3dd525a836 Author: Sven Eckelmann Date: Mon Nov 25 10:46:50 2019 +0100 batman-adv: Revert "disable ethtool link speed detection when auto negotiation off" [ Upstream commit 9ad346c90509ebd983f60da7d082f261ad329507 ] The commit 8c46fcd78308 ("batman-adv: disable ethtool link speed detection when auto negotiation off") disabled the usage of ethtool's link_ksetting when auto negotation was enabled due to invalid values when used with tun/tap virtual net_devices. According to the patch, automatic measurements should be used for these kind of interfaces. But there are major flaws with this argumentation: * automatic measurements are not implemented * auto negotiation has nothing to do with the validity of the retrieved values The first point has to be fixed by a longer patch series. The "validity" part of the second point must be addressed in the same patch series by dropping the usage of ethtool's link_ksetting (thus always doing automatic measurements over ethernet). Drop the patch again to have more default values for various net_device types/configurations. The user can still overwrite them using the batadv_hardif's BATADV_ATTR_THROUGHPUT_OVERRIDE. Reported-by: Matthias Schiffer Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit cceec3c3cbfafea6469373746cff64d436703d6e Author: Linus Walleij Date: Tue May 19 12:59:12 2020 +0100 ARM: 8978/1: mm: make act_mm() respect THREAD_SIZE [ Upstream commit e1de94380af588bdf6ad6f0cc1f75004c35bc096 ] Recent work with KASan exposed the folling hard-coded bitmask in arch/arm/mm/proc-macros.S: bic rd, sp, #8128 bic rd, rd, #63 This forms the bitmask 0x1FFF that is coinciding with (PAGE_SIZE << THREAD_SIZE_ORDER) - 1, this code was assuming that THREAD_SIZE is always 8K (8192). As KASan was increasing THREAD_SIZE_ORDER to 2, I ran into this bug. Fix it by this little oneline suggested by Ard: bic rd, sp, #(THREAD_SIZE - 1) & ~63 Where THREAD_SIZE is defined using THREAD_SIZE_ORDER. We have to also include since the THREAD_SIZE expands to use the _AC() macro. Cc: Ard Biesheuvel Cc: Florian Fainelli Suggested-by: Ard Biesheuvel Signed-off-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Sasha Levin commit f8a27dee67c08bf7aa56d444271b6b3e20aed9cb Author: Filipe Manana Date: Mon May 18 12:15:09 2020 +0100 btrfs: do not ignore error from btrfs_next_leaf() when inserting checksums [ Upstream commit 7e4a3f7ed5d54926ec671bbb13e171cfe179cc50 ] We are currently treating any non-zero return value from btrfs_next_leaf() the same way, by going to the code that inserts a new checksum item in the tree. However if btrfs_next_leaf() returns an error (a value < 0), we should just stop and return the error, and not behave as if nothing has happened, since in that case we do not have a way to know if there is a next leaf or we are currently at the last leaf already. So fix that by returning the error from btrfs_next_leaf(). Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ffa7a58fb048e577b358e521369bdc2cd354f8b6 Author: Serge Semin Date: Thu May 21 23:48:15 2020 +0300 clocksource: dw_apb_timer_of: Fix missing clockevent timers [ Upstream commit 6d2e16a3181bafb77b535095c39ad1c8b9558c8c ] Commit 100214889973 ("clocksource: dw_apb_timer_of: use clocksource_of_init") replaced a publicly available driver initialization method with one called by the timer_probe() method available after CLKSRC_OF. In current implementation it traverses all the timers available in the system and calls their initialization methods if corresponding devices were either in dtb or in acpi. But if before the commit any number of available timers would be installed as clockevent and clocksource devices, after that there would be at most two. The rest are just ignored since default case branch doesn't do anything. I don't see a reason of such behaviour, neither the commit message explains it. Moreover this might be wrong if on some platforms these timers might be used for different purpose, as virtually CPU-local clockevent timers and as an independent broadcast timer. So in order to keep the compatibility with the platforms where the order of the timers detection has some meaning, lets add the secondly discovered timer to be of clocksource/sched_clock type, while the very first and the others would provide the clockevents service. Fixes: 100214889973 ("clocksource: dw_apb_timer_of: use clocksource_of_init") Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: Arnd Bergmann Cc: Rob Herring Cc: linux-mips@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20200521204818.25436-7-Sergey.Semin@baikalelectronics.ru Signed-off-by: Sasha Levin commit 56fee2aa8469595b9c62021e3092c2ebfba0e30f Author: Serge Semin Date: Thu May 21 23:48:13 2020 +0300 clocksource: dw_apb_timer: Make CPU-affiliation being optional [ Upstream commit cee43dbf2ee3f430434e2b66994eff8a1aeda889 ] Currently the DW APB Timer driver binds each clockevent timers to a particular CPU. This isn't good for multiple reasons. First of all seeing the device is placed on APB bus (which makes it accessible from any CPU core), accessible over MMIO and having the DYNIRQ flag set we can be sure that manually binding the timer to any CPU just isn't correct. By doing so we just set an extra limitation on device usage. This also doesn't reflect the device actual capability, since by setting the IRQ affinity we can make it virtually local to any CPU. Secondly imagine if you had a real CPU-local timer with the same rating and the same CPU-affinity. In this case if DW APB timer was registered first, then due to the clockevent framework tick-timer selection procedure we'll end up with the real CPU-local timer being left unselected for clock-events tracking. But on most of the platforms (MIPS/ARM/etc) such timers are normally embedded into the CPU core and are accessible with much better performance then devices placed on APB. For instance in MIPS architectures there is r4k-timer, which is CPU-local, assigned with the same rating, and normally its clockevent device is registered after the platform-specific one. So in order to fix all of these issues let's make the DW APB Timer CPU affinity being optional and deactivated by passing a negative CPU id, which will effectively set the DW APB clockevent timer cpumask to 'cpu_possible_mask'. Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: Arnd Bergmann Cc: Rob Herring Cc: linux-mips@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20200521204818.25436-5-Sergey.Semin@baikalelectronics.ru Signed-off-by: Sasha Levin commit 655800d9203e59ae1fcd88882cb1887665d3f75f Author: Serge Semin Date: Fri May 22 03:07:51 2020 +0300 spi: dw: Enable interrupts in accordance with DMA xfer mode [ Upstream commit 43dba9f3f98c2b184a19f856f06fe22817bfd9e0 ] It's pointless to track the Tx overrun interrupts if Rx-only SPI transfer is issued. Similarly there is no need in handling the Rx overrun/underrun interrupts if Tx-only SPI transfer is executed. So lets unmask the interrupts only if corresponding SPI transactions are implied. Co-developed-by: Georgy Vlasov Signed-off-by: Georgy Vlasov Signed-off-by: Serge Semin Cc: Ramil Zaripov Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Andy Shevchenko Cc: Rob Herring Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200522000806.7381-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 04980e41634f6c4b38de530d6aa7ce7f14f5234b Author: Douglas Anderson Date: Thu May 7 13:08:44 2020 -0700 kgdb: Prevent infinite recursive entries to the debugger [ Upstream commit 3ca676e4ca60d1834bb77535dafe24169cadacef ] If we detect that we recursively entered the debugger we should hack our I/O ops to NULL so that the panic() in the next line won't actually cause another recursion into the debugger. The first line of kgdb_panic() will check this and return. Signed-off-by: Douglas Anderson Reviewed-by: Daniel Thompson Link: https://lore.kernel.org/r/20200507130644.v4.6.I89de39f68736c9de610e6f241e68d8dbc44bc266@changeid Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit b6f50bfa774da31cd8e4f00fb027aaac9a560bf5 Author: Douglas Anderson Date: Thu May 7 13:08:39 2020 -0700 kgdb: Disable WARN_CONSOLE_UNLOCKED for all kgdb [ Upstream commit 202164fbfa2b2ffa3e66b504e0f126ba9a745006 ] In commit 81eaadcae81b ("kgdboc: disable the console lock when in kgdb") we avoided the WARN_CONSOLE_UNLOCKED() yell when we were in kgdboc. That still works fine, but it turns out that we get a similar yell when using other I/O drivers. One example is the "I/O driver" for the kgdb test suite (kgdbts). When I enabled that I again got the same yells. Even though "kgdbts" doesn't actually interact with the user over the console, using it still causes kgdb to print to the consoles. That trips the same warning: con_is_visible+0x60/0x68 con_scroll+0x110/0x1b8 lf+0x4c/0xc8 vt_console_print+0x1b8/0x348 vkdb_printf+0x320/0x89c kdb_printf+0x68/0x90 kdb_main_loop+0x190/0x860 kdb_stub+0x2cc/0x3ec kgdb_cpu_enter+0x268/0x744 kgdb_handle_exception+0x1a4/0x200 kgdb_compiled_brk_fn+0x34/0x44 brk_handler+0x7c/0xb8 do_debug_exception+0x1b4/0x228 Let's increment/decrement the "ignore_console_lock_warning" variable all the time when we enter the debugger. This will allow us to later revert commit 81eaadcae81b ("kgdboc: disable the console lock when in kgdb"). Signed-off-by: Douglas Anderson Reviewed-by: Greg Kroah-Hartman Reviewed-by: Daniel Thompson Link: https://lore.kernel.org/r/20200507130644.v4.1.Ied2b058357152ebcc8bf68edd6f20a11d98d7d4e@changeid Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit 6d1ef7c11cb94bde6bbe5af47a900d0a2059efee Author: Hsin-Yu Chao Date: Fri May 15 17:27:04 2020 +0800 Bluetooth: Add SCO fallback for invalid LMP parameters error [ Upstream commit 56b5453a86203a44726f523b4133c1feca49ce7c ] Bluetooth PTS test case HFP/AG/ACC/BI-12-I accepts SCO connection with invalid parameter at the first SCO request expecting AG to attempt another SCO request with the use of "safe settings" for given codec, base on section 5.7.1.2 of HFP 1.7 specification. This patch addresses it by adding "Invalid LMP Parameters" (0x1e) to the SCO fallback case. Verified with below log: < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 Handle: 256 Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x0380 3-EV3 may not be used 2-EV5 may not be used 3-EV5 may not be used > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) ncmd 1 Status: Success (0x00) > HCI Event: Number of Completed Packets (0x13) plen 5 Num handles: 1 Handle: 256 Count: 1 > HCI Event: Max Slots Change (0x1b) plen 3 Handle: 256 Max slots: 1 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e) Handle: 0 Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC) Link type: eSCO (0x02) Transmission interval: 0x00 Retransmission window: 0x02 RX packet length: 0 TX packet length: 0 Air mode: Transparent (0x03) < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 Handle: 256 Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 8 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x03c8 EV3 may be used 2-EV3 may not be used 3-EV3 may not be used 2-EV5 may not be used 3-EV5 may not be used > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) ncmd 1 Status: Success (0x00) > HCI Event: Max Slots Change (0x1b) plen 3 Handle: 256 Max slots: 5 > HCI Event: Max Slots Change (0x1b) plen 3 Handle: 256 Max slots: 1 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 Status: Success (0x00) Handle: 257 Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC) Link type: eSCO (0x02) Transmission interval: 0x06 Retransmission window: 0x04 RX packet length: 30 TX packet length: 30 Air mode: Transparent (0x03) Signed-off-by: Hsin-Yu Chao Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit d83dc18881fcdb4ab285573d9b0806149cc32532 Author: Tiezhu Yang Date: Sat May 16 10:15:48 2020 +0800 MIPS: Loongson: Build ATI Radeon GPU driver as module [ Upstream commit a44de7497f91834df0b8b6d459e259788ba66794 ] When ATI Radeon GPU driver has been compiled directly into the kernel instead of as a module, we should make sure the firmware for the model (check available ones in /lib/firmware/radeon) is built-in to the kernel as well, otherwise there exists the following fatal error during GPU init, change CONFIG_DRM_RADEON=y to CONFIG_DRM_RADEON=m to fix it. [ 1.900997] [drm] Loading RS780 Microcode [ 1.905077] radeon 0000:01:05.0: Direct firmware load for radeon/RS780_pfp.bin failed with error -2 [ 1.914140] r600_cp: Failed to load firmware "radeon/RS780_pfp.bin" [ 1.920405] [drm:r600_init] *ERROR* Failed to load firmware! [ 1.926069] radeon 0000:01:05.0: Fatal error during GPU init [ 1.931729] [drm] radeon: finishing device. Fixes: 024e6a8b5bb1 ("MIPS: Loongson: Add a Loongson-3 default config file") Signed-off-by: Tiezhu Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 33c8caccce9c745b1fa26e8b6c8242513ad549e3 Author: Jesper Dangaard Brouer Date: Thu May 14 12:50:49 2020 +0200 ixgbe: Fix XDP redirect on archs with PAGE_SIZE above 4K [ Upstream commit 88eb0ee17b2ece64fcf6689a4557a5c2e7a89c4b ] The ixgbe driver have another memory model when compiled on archs with PAGE_SIZE above 4096 bytes. In this mode it doesn't split the page in two halves, but instead increment rx_buffer->page_offset by truesize of packet (which include headroom and tailroom for skb_shared_info). This is done correctly in ixgbe_build_skb(), but in ixgbe_rx_buffer_flip which is currently only called on XDP_TX and XDP_REDIRECT, it forgets to add the tailroom for skb_shared_info. This breaks XDP_REDIRECT, for veth and cpumap. Fix by adding size of skb_shared_info tailroom. Maintainers notice: This fix have been queued to Jeff. Fixes: 6453073987ba ("ixgbe: add initial support for xdp redirect") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Cc: Jeff Kirsher Link: https://lore.kernel.org/bpf/158945344946.97035.17031588499266605743.stgit@firesoul Signed-off-by: Sasha Levin commit 6d94929ed5df09303b2658b5a311db5e1a93316b Author: Luke Nelson Date: Fri May 8 11:15:44 2020 -0700 arm64: insn: Fix two bugs in encoding 32-bit logical immediates [ Upstream commit 579d1b3faa3735e781ff74aac0afd598515dbc63 ] This patch fixes two issues present in the current function for encoding arm64 logical immediates when using the 32-bit variants of instructions. First, the code does not correctly reject an all-ones 32-bit immediate, and returns an undefined instruction encoding. Second, the code incorrectly rejects some 32-bit immediates that are actually encodable as logical immediates. The root cause is that the code uses a default mask of 64-bit all-ones, even for 32-bit immediates. This causes an issue later on when the default mask is used to fill the top bits of the immediate with ones, shown here: /* * Pattern: 0..01..10..01..1 * * Fill the unused top bits with ones, and check if * the result is a valid immediate (all ones with a * contiguous ranges of zeroes). */ imm |= ~mask; if (!range_of_ones(~imm)) return AARCH64_BREAK_FAULT; To see the problem, consider an immediate of the form 0..01..10..01..1, where the upper 32 bits are zero, such as 0x80000001. The code checks if ~(imm | ~mask) contains a range of ones: the incorrect mask yields 1..10..01..10..0, which fails the check; the correct mask yields 0..01..10..0, which succeeds. The fix for both issues is to generate a correct mask based on the instruction immediate size, and use the mask to check for all-ones, all-zeroes, and values wider than the mask. Currently, arch/arm64/kvm/va_layout.c is the only user of this function, which uses 64-bit immediates and therefore won't trigger these bugs. We tested the new code against llvm-mc with all 1,302 encodable 32-bit logical immediates and all 5,334 encodable 64-bit logical immediates. Fixes: ef3935eeebff ("arm64: insn: Add encoder for bitwise operations using literals") Suggested-by: Will Deacon Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20200508181547.24783-2-luke.r.nels@gmail.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f8f72a29018bad55b5e6f4da22e4275ba0bc461c Author: Andy Shevchenko Date: Wed May 6 18:30:18 2020 +0300 spi: dw: Zero DMA Tx and Rx configurations on stack [ Upstream commit 3cb97e223d277f84171cc4ccecab31e08b2ee7b5 ] Some DMA controller drivers do not tolerate non-zero values in the DMA configuration structures. Zero them to avoid issues with such DMA controller drivers. Even despite above this is a good practice per se. Fixes: 7063c0d942a1 ("spi/dw_spi: add DMA support") Signed-off-by: Andy Shevchenko Acked-by: Feng Tang Cc: Feng Tang Link: https://lore.kernel.org/r/20200506153025.21441-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit efd45fe5e73d42452610401ef7a7b993b92794fb Author: Daniel Thompson Date: Mon May 4 18:05:18 2020 +0100 arm64: cacheflush: Fix KGDB trap detection [ Upstream commit ab8ad279ceac4fc78ae4dcf1a26326e05695e537 ] flush_icache_range() contains a bodge to avoid issuing IPIs when the kgdb trap handler is running because issuing IPIs is unsafe (and not needed) in this execution context. However the current test, based on kgdb_connected is flawed: it both over-matches and under-matches. The over match occurs because kgdb_connected is set when gdb attaches to the stub and remains set during normal running. This is relatively harmelss because in almost all cases irq_disabled() will be false. The under match is more serious. When kdb is used instead of kgdb to access the debugger then kgdb_connected is not set in all the places that the debug core updates sw breakpoints (and hence flushes the icache). This can lead to deadlock. Fix by replacing the ad-hoc check with the proper kgdb macro. This also allows us to drop the #ifdef wrapper. Fixes: 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings") Signed-off-by: Daniel Thompson Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20200504170518.2959478-1-daniel.thompson@linaro.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 264f6966bfa6e7399ba883cdcd876e070b662545 Author: Ard Biesheuvel Date: Mon May 4 10:06:29 2020 +0200 efi/libstub/x86: Work around LLVM ELF quirk build regression [ Upstream commit f77767ed5f4d398b29119563155e4ece2dfeee13 ] When building the x86 EFI stub with Clang, the libstub Makefile rules that manipulate the ELF object files may throw an error like: STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o strip: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10 objcopy: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10 This is the result of a LLVM feature [0] where symbol references are stored in a LLVM specific .llvm_addrsig section in a non-transparent way, causing generic ELF tools such as strip or objcopy to choke on them. So force the compiler not to emit these sections, by passing the appropriate command line option. [0] https://sourceware.org/bugzilla/show_bug.cgi?id=23817 Cc: Nick Desaulniers Cc: Peter Collingbourne Cc: Sami Tolvanen Reported-by: Arnd Bergmann Suggested-by: Fangrui Song Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 8ae0b5d2a177f19a582f5c3f496fed0cf603b2f3 Author: Arthur Kiyanovski Date: Sun May 3 09:52:11 2020 +0000 net: ena: fix error returning in ena_com_get_hash_function() [ Upstream commit e9a1de378dd46375f9abfd8de1e6f59ee114a793 ] In case the "func" parameter is NULL we now return "-EINVAL". This shouldn't happen in general, but when it does happen, this is the proper way to handle it. We also check func for NULL in the beginning of the function, as there is no reason to do all the work and realize in the end of the function it was useless. Signed-off-by: Sameeh Jubran Signed-off-by: Arthur Kiyanovski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 79165d03353c436238513aa8633de1d820825270 Author: Mark Starovoytov Date: Thu Apr 30 11:04:34 2020 +0300 net: atlantic: make hw_get_regs optional [ Upstream commit d0f23741c202c685447050713907f3be39a985ee ] This patch fixes potential crash in case if hw_get_regs is NULL. Signed-off-by: Mark Starovoytov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b80956bc0f48e964052458ea497ad613831f66a9 Author: Evan Green Date: Mon Apr 27 16:32:48 2020 -0700 spi: pxa2xx: Apply CS clk quirk to BXT [ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ] With a couple allies at Intel, and much badgering, I got confirmation from Intel that at least BXT suffers from the same SPI chip-select issue as Cannonlake (and beyond). The issue being that after going through runtime suspend/resume, toggling the chip-select line without also sending data does nothing. Add the quirk to BXT to briefly toggle dynamic clock gating off and on, forcing the fabric to wake up enough to notice the CS register change. Signed-off-by: Evan Green Cc: Shobhit Srivastava Cc: Andy Shevchenko Link: https://lore.kernel.org/r/20200427163238.1.Ib1faaabe236e37ea73be9b8dcc6aa034cb3c8804@changeid Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b34bdf1148731cd258192cd6a6ed6014fcd627e4 Author: Julien Thierry Date: Fri Mar 27 15:28:41 2020 +0000 objtool: Ignore empty alternatives [ Upstream commit 7170cf47d16f1ba29eca07fd818870b7af0a93a5 ] The .alternatives section can contain entries with no original instructions. Objtool will currently crash when handling such an entry. Just skip that entry, but still give a warning to discourage useless entries. Signed-off-by: Julien Thierry Acked-by: Peter Zijlstra (Intel) Reviewed-by: Miroslav Benes Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 11ff15e4fec72c392945579a49ee4bc0d9c796e9 Author: Brad Love Date: Thu Nov 14 21:03:57 2019 +0100 media: si2157: Better check for running tuner in init [ Upstream commit e955f959ac52e145f27ff2be9078b646d0352af0 ] Getting the Xtal trim property to check if running is less error prone. Reset if_frequency if state is unknown. Replaces the previous "garbage check". Signed-off-by: Brad Love Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8ff3bf83df470b5cb8e5735fbaa44b00bf6ec3b4 Author: Arnd Bergmann Date: Wed Apr 8 18:26:48 2020 +0200 crypto: ccp -- don't "select" CONFIG_DMADEVICES [ Upstream commit eebac678556d6927f09a992872f4464cf3aecc76 ] DMADEVICES is the top-level option for the slave DMA subsystem, and should not be selected by device drivers, as this can cause circular dependencies such as: drivers/net/ethernet/freescale/Kconfig:6:error: recursive dependency detected! drivers/net/ethernet/freescale/Kconfig:6: symbol NET_VENDOR_FREESCALE depends on PPC_BESTCOMM drivers/dma/bestcomm/Kconfig:6: symbol PPC_BESTCOMM depends on DMADEVICES drivers/dma/Kconfig:6: symbol DMADEVICES is selected by CRYPTO_DEV_SP_CCP drivers/crypto/ccp/Kconfig:10: symbol CRYPTO_DEV_SP_CCP depends on CRYPTO crypto/Kconfig:16: symbol CRYPTO is selected by LIBCRC32C lib/Kconfig:222: symbol LIBCRC32C is selected by LIQUIDIO drivers/net/ethernet/cavium/Kconfig:65: symbol LIQUIDIO depends on PTP_1588_CLOCK drivers/ptp/Kconfig:8: symbol PTP_1588_CLOCK is implied by FEC drivers/net/ethernet/freescale/Kconfig:23: symbol FEC depends on NET_VENDOR_FREESCALE The LIQUIDIO driver causing this problem is addressed in a separate patch, but this change is needed to prevent it from happening again. Using "depends on DMADEVICES" is what we do for all other implementations of slave DMA controllers as well. Fixes: b3c2fee5d66b ("crypto: ccp - Ensure all dependencies are specified") Signed-off-by: Arnd Bergmann Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0302d9e2e266da411c929dd16fe6eecbb901b3a2 Author: Bogdan Togorean Date: Mon Apr 13 14:35:08 2020 +0300 drm: bridge: adv7511: Extend list of audio sample rates [ Upstream commit b97b6a1f6e14a25d1e1ca2a46c5fa3e2ca374e22 ] ADV7511 support sample rates up to 192kHz. CTS and N parameters should be computed accordingly so this commit extend the list up to maximum supported sample rate. Signed-off-by: Bogdan Togorean Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20200413113513.86091-2-bogdan.togorean@analog.com Signed-off-by: Sasha Levin commit 743acb5ae4042064155c961ae5736dc61bcea2eb Author: Ard Biesheuvel Date: Wed May 27 13:37:00 2020 +0200 ACPI: GED: use correct trigger type field in _Exx / _Lxx handling commit e5c399b0bd6490c12c0af2a9eaa9d7cd805d52c9 upstream. Commit ea6f3af4c5e63f69 ("ACPI: GED: add support for _Exx / _Lxx handler methods") added a reference to the 'triggering' field of either the normal or the extended ACPI IRQ resource struct, but inadvertently used the wrong pointer in the latter case. Note that both pointers refer to the same union, and the 'triggering' field appears at the same offset in both struct types, so it currently happens to work by accident. But let's fix it nonetheless Fixes: ea6f3af4c5e63f69 ("ACPI: GED: add support for _Exx / _Lxx handler methods") Signed-off-by: Ard Biesheuvel Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 929fccde381ef382c519c52c2746ab5febc30442 Author: Marc Zyngier Date: Tue Jun 9 08:50:29 2020 +0100 KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception commit 0370964dd3ff7d3d406f292cb443a927952cbd05 upstream. On a VHE system, the EL1 state is left in the CPU most of the time, and only syncronized back to memory when vcpu_put() is called (most of the time on preemption). Which means that when injecting an exception, we'd better have a way to either: (1) write directly to the EL1 sysregs (2) synchronize the state back to memory, and do the changes there For an AArch64, we already do (1), so we are safe. Unfortunately, doing the same thing for AArch32 would be pretty invasive. Instead, we can easily implement (2) by calling the put/load architectural backends, and keep preemption disabled. We can then reload the state back into EL1. Cc: stable@vger.kernel.org Reported-by: James Morse Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 6152c2efa0463206aa747f9a6095a8eb87b203a8 Author: Juergen Gross Date: Mon May 11 09:42:31 2020 +0200 xen/pvcalls-back: test for errors when calling backend_connect() commit c8d70a29d6bbc956013f3401f92a4431a9385a3c upstream. backend_connect() can fail, so switch the device to connected only if no error occurred. Fixes: 0a9c75c2c7258f2 ("xen/pvcalls: xenbus state handling") Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross Link: https://lore.kernel.org/r/20200511074231.19794-1-jgross@suse.com Reviewed-by: Stefano Stabellini Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 5fff08f45970e1f78472b27080e77695289a75e3 Author: Ulf Hansson Date: Thu Apr 30 11:16:37 2020 +0200 mmc: sdio: Fix potential NULL pointer error in mmc_sdio_init_card() commit f04086c225da11ad16d7f9a2fbca6483ab16dded upstream. During some scenarios mmc_sdio_init_card() runs a retry path for the UHS-I specific initialization, which leads to removal of the previously allocated card. A new card is then re-allocated while retrying. However, in one of the corresponding error paths we may end up to remove an already removed card, which likely leads to a NULL pointer exception. So, let's fix this. Fixes: 5fc3d80ef496 ("mmc: sdio: don't use rocr to check if the card could support UHS mode") Cc: Signed-off-by: Ulf Hansson Link: https://lore.kernel.org/r/20200430091640.455-2-ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman commit fe06085e4e68ec177a8f475a149194602cb5a672 Author: Ludovic Desroches Date: Thu Apr 2 00:15:00 2020 +0200 ARM: dts: at91: sama5d2_ptc_ek: fix sdmmc0 node description commit a1af7f36c70369b971ee1cf679dd68368dad23f0 upstream. Remove non-removable and mmc-ddr-1_8v properties from the sdmmc0 node which come probably from an unchecked copy/paste. Signed-off-by: Ludovic Desroches Fixes:42ed535595ec "ARM: dts: at91: introduce the sama5d2 ptc ek board" Cc: stable@vger.kernel.org # 4.19 and later Link: https://lore.kernel.org/r/20200401221504.41196-1-ludovic.desroches@microchip.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 420c7bb85f4324f43c7aef7d3e9fee0b281b464e Author: Veerabhadrarao Badiganti Date: Thu May 28 20:43:52 2020 +0530 mmc: sdhci-msm: Clear tuning done flag while hs400 tuning commit 9253d71011c349d5f5cc0cebdf68b4a80811b92d upstream. Clear tuning_done flag while executing tuning to ensure vendor specific HS400 settings are applied properly when the controller is re-initialized in HS400 mode. Without this, re-initialization of the qcom SDHC in HS400 mode fails while resuming the driver from runtime-suspend or system-suspend. Fixes: ff06ce417828 ("mmc: sdhci-msm: Add HS400 platform support") Cc: stable@vger.kernel.org Signed-off-by: Veerabhadrarao Badiganti Link: https://lore.kernel.org/r/1590678838-18099-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7ccbb4434449daba99ae3fc8e734f93587567651 Author: Chris Wilson Date: Fri Apr 10 09:35:35 2020 +0100 agp/intel: Reinforce the barrier after GTT updates commit f30d3ced9fafa03e4855508929b5b6334907f45e upstream. After changing the timing between GTT updates and execution on the GPU, we started seeing sporadic failures on Ironlake. These were narrowed down to being an insufficiently strong enough barrier/delay after updating the GTT and scheduling execution on the GPU. By forcing the uncached read, and adding the missing barrier for the singular insert_page (relocation paths), the sporadic failures go away. Fixes: 983d308cb8f6 ("agp/intel: Serialise after GTT updates") Fixes: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE") Signed-off-by: Chris Wilson Acked-by: Andi Shyti Cc: stable@vger.kernel.org # v4.0+ Link: https://patchwork.freedesktop.org/patch/msgid/20200410083535.25464-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman commit 28292eb6dda1ecfe1549a7e444f1c5d8c8489d92 Author: Barret Rhoden Date: Tue Apr 14 18:29:20 2020 -0400 perf: Add cond_resched() to task_function_call() commit 2ed6edd33a214bca02bd2b45e3fc3038a059436b upstream. Under rare circumstances, task_function_call() can repeatedly fail and cause a soft lockup. There is a slight race where the process is no longer running on the cpu we targeted by the time remote_function() runs. The code will simply try again. If we are very unlucky, this will continue to fail, until a watchdog fires. This can happen in a heavily loaded, multi-core virtual machine. Reported-by: syzbot+bb4935a5c09b5ff79940@syzkaller.appspotmail.com Signed-off-by: Barret Rhoden Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200414222920.121401-1-brho@google.com Signed-off-by: Greg Kroah-Hartman commit 958286418617c31ab7d5ee9528a2ad97f2bc5c3c Author: OGAWA Hirofumi Date: Thu Jun 4 16:50:56 2020 -0700 fat: don't allow to mount if the FAT length == 0 commit b1b65750b8db67834482f758fc385bfa7560d228 upstream. If FAT length == 0, the image doesn't have any data. And it can be the cause of overlapping the root dir and FAT entries. Also Windows treats it as invalid format. Reported-by: syzbot+6f1624f937d9d6911e2d@syzkaller.appspotmail.com Signed-off-by: OGAWA Hirofumi Signed-off-by: Andrew Morton Cc: Marco Elver Cc: Dmitry Vyukov Link: http://lkml.kernel.org/r/87r1wz8mrd.fsf@mail.parknet.co.jp Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 53bb2a6566fb84d2ce3d36ecd42af5cb9c34f14e Author: Wang Hai Date: Wed Jun 3 15:56:21 2020 -0700 mm/slub: fix a memory leak in sysfs_slab_add() commit dde3c6b72a16c2db826f54b2d49bdea26c3534a2 upstream. syzkaller reports for memory leak when kobject_init_and_add() returns an error in the function sysfs_slab_add() [1] When this happened, the function kobject_put() is not called for the corresponding kobject, which potentially leads to memory leak. This patch fixes the issue by calling kobject_put() even if kobject_init_and_add() fails. [1] BUG: memory leak unreferenced object 0xffff8880a6d4be88 (size 8): comm "syz-executor.3", pid 946, jiffies 4295772514 (age 18.396s) hex dump (first 8 bytes): 70 69 64 5f 33 00 ff ff pid_3... backtrace: kstrdup+0x35/0x70 mm/util.c:60 kstrdup_const+0x3d/0x50 mm/util.c:82 kvasprintf_const+0x112/0x170 lib/kasprintf.c:48 kobject_set_name_vargs+0x55/0x130 lib/kobject.c:289 kobject_add_varg lib/kobject.c:384 [inline] kobject_init_and_add+0xd8/0x170 lib/kobject.c:473 sysfs_slab_add+0x1d8/0x290 mm/slub.c:5811 __kmem_cache_create+0x50a/0x570 mm/slub.c:4384 create_cache+0x113/0x1e0 mm/slab_common.c:407 kmem_cache_create_usercopy+0x1a1/0x260 mm/slab_common.c:505 kmem_cache_create+0xd/0x10 mm/slab_common.c:564 create_pid_cachep kernel/pid_namespace.c:54 [inline] create_pid_namespace kernel/pid_namespace.c:96 [inline] copy_pid_ns+0x77c/0x8f0 kernel/pid_namespace.c:148 create_new_namespaces+0x26b/0xa30 kernel/nsproxy.c:95 unshare_nsproxy_namespaces+0xa7/0x1e0 kernel/nsproxy.c:229 ksys_unshare+0x3d2/0x770 kernel/fork.c:2969 __do_sys_unshare kernel/fork.c:3037 [inline] __se_sys_unshare kernel/fork.c:3035 [inline] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3035 do_syscall_64+0xa1/0x530 arch/x86/entry/common.c:295 Fixes: 80da026a8e5d ("mm/slub: fix slab double-free in case of duplicate sysfs filename") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: Andrew Morton Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Link: http://lkml.kernel.org/r/20200602115033.1054-1-wanghai38@huawei.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 03f9f16e9a8312923a4e63990bdf27ba3c1a8952 Author: Ezequiel Garcia Date: Mon Apr 27 18:44:05 2020 -0300 drm/vkms: Hold gem object while still in-use commit 0ea2ea42b31abc1141f2fd3911f952a97d401fcb upstream. We need to keep the reference to the drm_gem_object until the last access by vkms_dumb_create. Therefore, the put the object after it is used. This fixes a use-after-free issue reported by syzbot. While here, change vkms_gem_create() symbol to static. Reported-and-tested-by: syzbot+e3372a2afe1e7ef04bc7@syzkaller.appspotmail.com Signed-off-by: Ezequiel Garcia Reviewed-by: Rodrigo Siqueira Signed-off-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/20200427214405.13069-1-ezequiel@collabora.com Signed-off-by: Greg Kroah-Hartman commit 84981421848f9107d461cb8e124aa71cac4fc60f Author: Casey Schaufler Date: Thu Apr 9 16:35:28 2020 -0700 Smack: slab-out-of-bounds in vsscanf commit 84e99e58e8d1e26f04c097f4266e431a33987f36 upstream. Add barrier to soob. Return -EOVERFLOW if the buffer is exceeded. Suggested-by: Hillf Danton Reported-by: syzbot+bfdd4a2f07be52351350@syzkaller.appspotmail.com Signed-off-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman commit bdf4d37b03dc410b91f318c8e097a41e732d1038 Author: Qiujun Huang Date: Sat Apr 4 12:18:38 2020 +0800 ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream. In ath9k_hif_usb_rx_cb interface number is assumed to be 0. usb_ifnum_to_if(urb->dev, 0) But it isn't always true. The case reported by syzbot: https://lore.kernel.org/linux-usb/000000000000666c9c05a1c05d12@google.com usb 2-1: new high-speed USB device number 2 using dummy_hcd usb 2-1: config 1 has an invalid interface number: 2 but max is 0 usb 2-1: config 1 has no interface number 0 usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 general protection fault, probably for non-canonical address 0xdffffc0000000015: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0 Call Trace __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 __do_softirq+0x21e/0x950 kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x178/0x1a0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:546 [inline] smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200404041838.10426-6-hqjagain@gmail.com Signed-off-by: Greg Kroah-Hartman commit c2ebfef9f927d9aaab65849e0746aff1b86142fe Author: Qiujun Huang Date: Sat Apr 4 12:18:37 2020 +0800 ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb commit 19d6c375d671ce9949a864fb9a03e19f5487b4d3 upstream. Add barrier to accessing the stack array skb_pool. The case reported by syzbot: https://lore.kernel.org/linux-usb/0000000000003d7c1505a2168418@google.com BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:626 [inline] BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_cb+0xdf6/0xf70 drivers/net/wireless/ath/ath9k/hif_usb.c:666 Write of size 8 at addr ffff8881db309a28 by task swapper/1/0 Call Trace: ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:626 [inline] ath9k_hif_usb_rx_cb+0xdf6/0xf70 drivers/net/wireless/ath/ath9k/hif_usb.c:666 __usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1648 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1713 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 Reported-and-tested-by: syzbot+d403396d4df67ad0bd5f@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200404041838.10426-5-hqjagain@gmail.com Signed-off-by: Greg Kroah-Hartman commit 97c23a7fd0985c8099c1b2887fd0b9d8520db480 Author: Qiujun Huang Date: Sat Apr 4 12:18:36 2020 +0800 ath9k: Fix use-after-free Write in ath9k_htc_rx_msg commit e4ff08a4d727146bb6717a39a8d399d834654345 upstream. Write out of slab bounds. We should check epid. The case reported by syzbot: https://lore.kernel.org/linux-usb/0000000000006ac55b05a1c05d72@google.com BUG: KASAN: use-after-free in htc_process_conn_rsp drivers/net/wireless/ath/ath9k/htc_hst.c:131 [inline] BUG: KASAN: use-after-free in ath9k_htc_rx_msg+0xa25/0xaf0 drivers/net/wireless/ath/ath9k/htc_hst.c:443 Write of size 2 at addr ffff8881cea291f0 by task swapper/1/0 Call Trace: htc_process_conn_rsp drivers/net/wireless/ath/ath9k/htc_hst.c:131 [inline] ath9k_htc_rx_msg+0xa25/0xaf0 drivers/net/wireless/ath/ath9k/htc_hst.c:443 ath9k_hif_usb_reg_in_cb+0x1ba/0x630 drivers/net/wireless/ath/ath9k/hif_usb.c:718 __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 Reported-and-tested-by: syzbot+b1c61e5f11be5782f192@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200404041838.10426-4-hqjagain@gmail.com Signed-off-by: Greg Kroah-Hartman commit 66a4ca83d50bb38c814190af2188868153cce5de Author: Qiujun Huang Date: Sat Apr 4 12:18:35 2020 +0800 ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx commit abeaa85054ff8cfe8b99aafc5c70ea067e5d0908 upstream. Free wmi later after cmd urb has been killed, as urb cb will access wmi. the case reported by syzbot: https://lore.kernel.org/linux-usb/0000000000000002fc05a1d61a68@google.com BUG: KASAN: use-after-free in ath9k_wmi_ctrl_rx+0x416/0x500 drivers/net/wireless/ath/ath9k/wmi.c:215 Read of size 1 at addr ffff8881cef1417c by task swapper/1/0 Call Trace: ath9k_wmi_ctrl_rx+0x416/0x500 drivers/net/wireless/ath/ath9k/wmi.c:215 ath9k_htc_rx_msg+0x2da/0xaf0 drivers/net/wireless/ath/ath9k/htc_hst.c:459 ath9k_hif_usb_reg_in_cb+0x1ba/0x630 drivers/net/wireless/ath/ath9k/hif_usb.c:718 __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 Reported-and-tested-by: syzbot+5d338854440137ea0fef@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200404041838.10426-3-hqjagain@gmail.com Signed-off-by: Greg Kroah-Hartman commit 462a083ac69f5776bcb6b42fe8fce03e22d57726 Author: Sumit Saxena Date: Fri May 8 14:22:42 2020 +0530 scsi: megaraid_sas: TM command refire leads to controller firmware crash commit 6fd8525a70221c26823b1c7e912fb21f218fb0c5 upstream. When TM command times out, driver invokes the controller reset. Post reset, driver re-fires pended TM commands which leads to firmware crash. Post controller reset, return pended TM commands back to OS. Link: https://lore.kernel.org/r/20200508085242.23406-1-chandrakanth.patil@broadcom.com Cc: stable@vger.kernel.org Signed-off-by: Sumit Saxena Signed-off-by: Chandrakanth Patil Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 031998bd30c9e2284634390c43e555a358c638e3 Author: Marc Zyngier Date: Tue Jun 9 08:40:35 2020 +0100 KVM: arm64: Make vcpu_cp1x() work on Big Endian hosts commit 3204be4109ad681523e3461ce64454c79278450a upstream. AArch32 CP1x registers are overlayed on their AArch64 counterparts in the vcpu struct. This leads to an interesting problem as they are stored in their CPU-local format, and thus a CP1x register doesn't "hit" the lower 32bit portion of the AArch64 register on a BE host. To workaround this unfortunate situation, introduce a bias trick in the vcpu_cp1x() accessors which picks the correct half of the 64bit register. Cc: stable@vger.kernel.org Reported-by: James Morse Tested-by: James Morse Acked-by: James Morse Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit bf9cc08188fa45e63795c1335c823c2ad60973d9 Author: Xing Li Date: Sat May 23 15:56:29 2020 +0800 KVM: MIPS: Fix VPN2_MASK definition for variable cpu_vmbits commit 5816c76dea116a458f1932eefe064e35403248eb upstream. If a CPU support more than 32bit vmbits (which is true for 64bit CPUs), VPN2_MASK set to fixed 0xffffe000 will lead to a wrong EntryHi in some functions such as _kvm_mips_host_tlb_inv(). The cpu_vmbits definition of 32bit CPU in cpu-features.h is 31, so we still use the old definition. Cc: Stable Reviewed-by: Aleksandar Markovic Signed-off-by: Xing Li [Huacai: Improve commit messages] Signed-off-by: Huacai Chen Message-Id: <1590220602-3547-3-git-send-email-chenhc@lemote.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 7fe991bd330dc9fd02012f641a0b162f6121770d Author: Xing Li Date: Sat May 23 15:56:28 2020 +0800 KVM: MIPS: Define KVM_ENTRYHI_ASID to cpu_asid_mask(&boot_cpu_data) commit fe2b73dba47fb6d6922df1ad44e83b1754d5ed4d upstream. The code in decode_config4() of arch/mips/kernel/cpu-probe.c asid_mask = MIPS_ENTRYHI_ASID; if (config4 & MIPS_CONF4_AE) asid_mask |= MIPS_ENTRYHI_ASIDX; set_cpu_asid_mask(c, asid_mask); set asid_mask to cpuinfo->asid_mask. So in order to support variable ASID_MASK, KVM_ENTRYHI_ASID should also be changed to cpu_asid_mask(&boot_cpu_data). Cc: Stable #4.9+ Reviewed-by: Aleksandar Markovic Signed-off-by: Xing Li [Huacai: Change current_cpu_data to boot_cpu_data for optimization] Signed-off-by: Huacai Chen Message-Id: <1590220602-3547-2-git-send-email-chenhc@lemote.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 10e983955710620e52216a0a28a89c93fe513bf1 Author: Sean Christopherson Date: Thu Feb 27 09:44:30 2020 -0800 KVM: nVMX: Consult only the "basic" exit reason when routing nested exit commit 2ebac8bb3c2d35f5135466490fc8eeaf3f3e2d37 upstream. Consult only the basic exit reason, i.e. bits 15:0 of vmcs.EXIT_REASON, when determining whether a nested VM-Exit should be reflected into L1 or handled by KVM in L0. For better or worse, the switch statement in nested_vmx_exit_reflected() currently defaults to "true", i.e. reflects any nested VM-Exit without dedicated logic. Because the case statements only contain the basic exit reason, any VM-Exit with modifier bits set will be reflected to L1, even if KVM intended to handle it in L0. Practically speaking, this only affects EXIT_REASON_MCE_DURING_VMENTRY, i.e. a #MC that occurs on nested VM-Enter would be incorrectly routed to L1, as "failed VM-Entry" is the only modifier that KVM can currently encounter. The SMM modifiers will never be generated as KVM doesn't support/employ a SMI Transfer Monitor. Ditto for "exit from enclave", as KVM doesn't yet support virtualizing SGX, i.e. it's impossible to enter an enclave in a KVM guest (L1 or L2). Fixes: 644d711aa0e1 ("KVM: nVMX: Deciding if L0 or L1 should handle an L2 exit") Cc: Jim Mattson Cc: Xiaoyao Li Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20200227174430.26371-1-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 9c3e4bc3b1dc6594cb19976c5f26ab937e86de70 Author: Paolo Bonzini Date: Wed May 20 08:02:17 2020 -0400 KVM: nSVM: leave ASID aside in copy_vmcb_control_area commit 6c0238c4a62b3a0b1201aeb7e33a4636d552a436 upstream. Restoring the ASID from the hsave area on VMEXIT is wrong, because its value depends on the handling of TLB flushes. Just skipping the field in copy_vmcb_control_area will do. Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 25f7dc433f5f40ed4a38caa66d35001ad795005e Author: Paolo Bonzini Date: Sat May 16 09:19:06 2020 -0400 KVM: nSVM: fix condition for filtering async PF commit a3535be731c2a343912578465021f50937f7b099 upstream. Async page faults have to be trapped in the host (L1 in this case), since the APF reason was passed from L0 to L1 and stored in the L1 APF data page. This was completely reversed: the page faults were passed to the guest, a L2 hypervisor. Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c6ee786d76d8d6205fc0d1a5baf2cb77d55a4311 Author: Christophe JAILLET Date: Wed May 6 20:19:02 2020 +0200 video: fbdev: w100fb: Fix a potential double free. commit 18722d48a6bb9c2e8d046214c0a5fd19d0a7c9f6 upstream. Some memory is vmalloc'ed in the 'w100fb_save_vidmem' function and freed in the 'w100fb_restore_vidmem' function. (these functions are called respectively from the 'suspend' and the 'resume' functions) However, it is also freed in the 'remove' function. In order to avoid a potential double free, set the corresponding pointer to NULL once freed in the 'w100fb_restore_vidmem' function. Fixes: aac51f09d96a ("[PATCH] w100fb: Rewrite for platform independence") Cc: Richard Purdie Cc: Antonino Daplas Cc: Bartlomiej Zolnierkiewicz Cc: # v2.6.14+ Signed-off-by: Christophe JAILLET Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200506181902.193290-1-christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman commit de13aebcf5a812fc9bd70fac7dd7a47bbf9cc3ef Author: Eric W. Biederman Date: Fri Jun 12 09:42:03 2020 -0500 proc: Use new_inode not new_inode_pseudo commit ef1548adada51a2f32ed7faef50aa465e1b4c5da upstream. Recently syzbot reported that unmounting proc when there is an ongoing inotify watch on the root directory of proc could result in a use after free when the watch is removed after the unmount of proc when the watcher exits. Commit 69879c01a0c3 ("proc: Remove the now unnecessary internal mount of proc") made it easier to unmount proc and allowed syzbot to see the problem, but looking at the code it has been around for a long time. Looking at the code the fsnotify watch should have been removed by fsnotify_sb_delete in generic_shutdown_super. Unfortunately the inode was allocated with new_inode_pseudo instead of new_inode so the inode was not on the sb->s_inodes list. Which prevented fsnotify_unmount_inodes from finding the inode and removing the watch as well as made it so the "VFS: Busy inodes after unmount" warning could not find the inodes to warn about them. Make all of the inodes in proc visible to generic_shutdown_super, and fsnotify_sb_delete by using new_inode instead of new_inode_pseudo. The only functional difference is that new_inode places the inodes on the sb->s_inodes list. I wrote a small test program and I can verify that without changes it can trigger this issue, and by replacing new_inode_pseudo with new_inode the issues goes away. Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/000000000000d788c905a7dfa3f4@google.com Reported-by: syzbot+7d2debdcdb3cb93c1e5e@syzkaller.appspotmail.com Fixes: 0097875bd415 ("proc: Implement /proc/thread-self to point at the directory of the current thread") Fixes: 021ada7dff22 ("procfs: switch /proc/self away from proc_dir_entry") Fixes: 51f0885e5415 ("vfs,proc: guarantee unique inodes in /proc") Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit cab0f4ae8b6f07eedda6f2ccaa8eec345f8040cc Author: Yuxuan Shui Date: Wed May 27 04:08:02 2020 +0100 ovl: initialize error in ovl_copy_xattr commit 520da69d265a91c6536c63851cbb8a53946974f0 upstream. In ovl_copy_xattr, if all the xattrs to be copied are overlayfs private xattrs, the copy loop will terminate without assigning anything to the error variable, thus returning an uninitialized value. If ovl_copy_xattr is called from ovl_clear_empty, this uninitialized error value is put into a pointer by ERR_PTR(), causing potential invalid memory accesses down the line. This commit initialize error with 0. This is the correct value because when there's no xattr to copy, because all xattrs are private, ovl_copy_xattr should succeed. This bug is discovered with the help of INIT_STACK_ALL and clang. Signed-off-by: Yuxuan Shui Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1050405 Fixes: 0956254a2d5b ("ovl: don't copy up opaqueness") Cc: stable@vger.kernel.org # v4.8 Signed-off-by: Alexander Potapenko Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 70dba6e91bdbfc87063109e1c0b8ca112f9e7019 Author: tannerlove Date: Tue Jun 9 17:21:32 2020 -0400 selftests/net: in rxtimestamp getopt_long needs terminating null entry [ Upstream commit 865a6cbb2288f8af7f9dc3b153c61b7014fdcf1e ] getopt_long requires the last element to be filled with zeros. Otherwise, passing an unrecognized option can cause a segfault. Fixes: 16e781224198 ("selftests/net: Add a test to validate behavior of rx timestamps") Signed-off-by: Tanner Love Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 65575b2fd7ccec290c42b02bfb14bd1d7badd9bc Author: Longpeng(Mike) Date: Tue Jun 2 15:05:01 2020 +0800 crypto: virtio: Fix dest length calculation in __virtio_crypto_skcipher_do_req() [ Upstream commit d90ca42012db2863a9a30b564a2ace6016594bda ] The src/dst length is not aligned with AES_BLOCK_SIZE(which is 16) in some testcases in tcrypto.ko. For example, the src/dst length of one of cts(cbc(aes))'s testcase is 17, the crypto_virtio driver will set @src_data_len=16 but @dst_data_len=17 in this case and get a wrong at then end. SRC: pp pp pp pp pp pp pp pp pp pp pp pp pp pp pp pp pp (17 bytes) EXP: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc pp (17 bytes) DST: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 00 (pollute the last bytes) (pp: plaintext cc:ciphertext) Fix this issue by limit the length of dest buffer. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Cc: Gonglei Cc: Herbert Xu Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: "David S. Miller" Cc: virtualization@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Longpeng(Mike) Link: https://lore.kernel.org/r/20200602070501.2023-4-longpeng2@huawei.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 79603e1cc526c77d232ccc3c2bf70611bb78bf68 Author: Longpeng(Mike) Date: Tue Jun 2 15:04:59 2020 +0800 crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req() [ Upstream commit b02989f37fc5e865ceeee9070907e4493b3a21e2 ] The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it by sg_next() on calculation of src/dst scatterlist. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Reported-by: LABBE Corentin Cc: Herbert Xu Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: "David S. Miller" Cc: virtualization@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200123101000.GB24255@Red Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Link: https://lore.kernel.org/r/20200602070501.2023-2-longpeng2@huawei.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 44009142eec6a2b05501d782cc44b74e0068170b Author: Longpeng(Mike) Date: Tue Jun 2 15:05:00 2020 +0800 crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req() [ Upstream commit 8c855f0720ff006d75d0a2512c7f6c4f60ff60ee ] The system'll crash when the users insmod crypto/tcrypto.ko with mode=155 ( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory of request structure. In crypto_authenc_init_tfm(), the reqsize is set to: [PART 1] sizeof(authenc_request_ctx) + [PART 2] ictx->reqoff + [PART 3] MAX(ahash part, skcipher part) and the 'PART 3' is used by both ahash and skcipher in turn. When the virtio_crypto driver finish skcipher req, it'll call ->complete callback(in crypto_finalize_skcipher_request) and then free its resources whose pointers are recorded in 'skcipher parts'. However, the ->complete is 'crypto_authenc_encrypt_done' in this case, it will use the 'ahash part' of the request and change its content, so virtio_crypto driver will get the wrong pointer after ->complete finish and mistakenly free some other's memory. So the system will crash when these memory will be used again. The resources which need to be cleaned up are not used any more. But the pointers of these resources may be changed in the function "crypto_finalize_skcipher_request". Thus release specific resources before calling this function. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Reported-by: LABBE Corentin Cc: Gonglei Cc: Herbert Xu Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: "David S. Miller" Cc: virtualization@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200123101000.GB24255@Red Acked-by: Gonglei Signed-off-by: Longpeng(Mike) Link: https://lore.kernel.org/r/20200602070501.2023-3-longpeng2@huawei.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit fa42072ebe6b0f6a963bbdb0ca7505819beaa057 Author: Lukas Wunner Date: Mon May 25 14:25:03 2020 +0200 spi: pxa2xx: Fix runtime PM ref imbalance on probe error [ Upstream commit 65e318e17358a3fd4fcb5a69d89b14016dee2f06 ] The PXA2xx SPI driver releases a runtime PM ref in the probe error path even though it hasn't acquired a ref earlier. Apparently commit e2b714afee32 ("spi: pxa2xx: Disable runtime PM if controller registration fails") sought to copy-paste the invocation of pm_runtime_disable() from pxa2xx_spi_remove(), but erroneously copied the call to pm_runtime_put_noidle() as well. Drop it. Fixes: e2b714afee32 ("spi: pxa2xx: Disable runtime PM if controller registration fails") Signed-off-by: Lukas Wunner Reviewed-by: Jarkko Nikula Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org # v4.17+ Cc: Jarkko Nikula Link: https://lore.kernel.org/r/58b2ac6942ca1f91aaeeafe512144bc5343e1d84.1590408496.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cfb29d1f09b7f27ad74d7933f159a2a7159032c3 Author: Lubomir Rintel Date: Fri Jul 19 14:27:13 2019 +0200 spi: pxa2xx: Balance runtime PM enable/disable on error [ Upstream commit 1274204542f683e1d8491ebe9cc86284d5a8ebcc ] Don't undo the PM initialization if we error out before we managed to initialize it. The call to pm_runtime_disable() without being preceded by pm_runtime_enable() would disturb the balance of the Force. In practice, this happens if we fail to allocate any of the GPIOS ("cs", "ready") due to -EPROBE_DEFER because we're getting probled before the GPIO driver. Signed-off-by: Lubomir Rintel Link: https://lore.kernel.org/r/20190719122713.3444318-1-lkundrak@v3.sk Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a2bae6359bf015f964c397e738a7fedbe0b68c14 Author: Lukas Wunner Date: Fri May 15 17:58:02 2020 +0200 spi: bcm2835: Fix controller unregister order [ Upstream commit 9dd277ff92d06f6aa95b39936ad83981d781f49b ] The BCM2835 SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes bcm2835_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: bcm2835_spi_remove() tears down the DMA channels and turns off the SPI controller, including its interrupts and clock. The SPI controller is thus no longer usable. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. If their drivers need to access the SPI bus, e.g. to quiesce their interrupts, unbinding will fail. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unbinding of slaves. Fix by using the non-devm variant spi_register_controller(). Note that the struct spi_controller as well as the driver-private data are not freed until after bcm2835_spi_remove() has finished, so accessing them is safe. Fixes: 247263dba208 ("spi: bcm2835: use devm_spi_register_master()") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.13+ Link: https://lore.kernel.org/r/2397dd70cdbe95e0bc4da2b9fca0f31cb94e5aed.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 73a10f53daf346ed026eb3dfe1fec9453cc8f490 Author: Lukas Wunner Date: Mon May 25 14:25:02 2020 +0200 spi: pxa2xx: Fix controller unregister order [ Upstream commit 32e5b57232c0411e7dea96625c415510430ac079 ] The PXA2xx SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes pxa2xx_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: pxa2xx_spi_remove() disables the chip, rendering the SPI bus inaccessible even though the SPI controller is still registered. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. Because their drivers cannot access the SPI bus, e.g. to quiesce interrupts, the slave devices may be left in an improper state. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unregistering the controller and specifically after unbinding of slaves. Fix by reverting to the non-devm variant of spi_register_controller(). An alternative approach would be to use device-managed functions for all steps in pxa2xx_spi_remove(), e.g. by calling devm_add_action_or_reset() on probe. However that approach would add more LoC to the driver and it wouldn't lend itself as well to backporting to stable. The improper use of devm_spi_register_controller() was introduced in 2013 by commit a807fcd090d6 ("spi: pxa2xx: use devm_spi_register_master()"), but all earlier versions of the driver going back to 2006 were likewise broken because they invoked spi_unregister_master() at the end of pxa2xx_spi_remove(), rather than at the beginning. Fixes: e0c9905e87ac ("[PATCH] SPI: add PXA2xx SSP SPI Driver") Signed-off-by: Lukas Wunner Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org # v2.6.17+ Cc: Tsuchiya Yuto Link: https://bugzilla.kernel.org/show_bug.cgi?id=206403#c1 Link: https://lore.kernel.org/r/834c446b1cf3284d2660f1bee1ebe3e737cd02a9.1590408496.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 675efd2778ce532d9492617d564426434c8be02c Author: Lukas Wunner Date: Fri May 15 17:58:01 2020 +0200 spi: Fix controller unregister order [ Upstream commit 84855678add8aba927faf76bc2f130a40f94b6f7 ] When an SPI controller unregisters, it unbinds all its slave devices. For this, their drivers may need to access the SPI bus, e.g. to quiesce interrupts. However since commit ffbbdd21329f ("spi: create a message queueing infrastructure"), spi_destroy_queue() is executed before unbinding the slaves. It sets ctlr->running = false, thereby preventing SPI bus access and causing unbinding of slave devices to fail. Fix by unbinding slaves before calling spi_destroy_queue(). Fixes: ffbbdd21329f ("spi: create a message queueing infrastructure") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.4+ Cc: Linus Walleij Link: https://lore.kernel.org/r/8aaf9d44c153fe233b17bc2dec4eb679898d7e7b.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 03a381292891560d7347a0a0ee4f6875bf8065a5 Author: Andy Shevchenko Date: Sat Jun 15 20:41:35 2019 +0300 spi: No need to assign dummy value in spi_unregister_controller() [ Upstream commit ebc37af5e0a134355ea2b62ed4141458bdbd5389 ] The device_for_each_child() doesn't require the returned value to be checked. Thus, drop the dummy variable completely and have no warning anymore: drivers/spi/spi.c: In function ‘spi_unregister_controller’: drivers/spi/spi.c:2480:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] int dummy; ^~~~~ Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 52c419ba4c96880abd61b38e6e08e4ecd17350f3 Author: Anthony Steinhauser Date: Sun Jun 7 05:44:19 2020 -0700 x86/speculation: PR_SPEC_FORCE_DISABLE enforcement for indirect branches. [ Upstream commit 4d8df8cbb9156b0a0ab3f802b80cb5db57acc0bf ] Currently, it is possible to enable indirect branch speculation even after it was force-disabled using the PR_SPEC_FORCE_DISABLE option. Moreover, the PR_GET_SPECULATION_CTRL command gives afterwards an incorrect result (force-disabled when it is in fact enabled). This also is inconsistent vs. STIBP and the documention which cleary states that PR_SPEC_FORCE_DISABLE cannot be undone. Fix this by actually enforcing force-disabled indirect branch speculation. PR_SPEC_ENABLE called after PR_SPEC_FORCE_DISABLE now fails with -EPERM as described in the documentation. Fixes: 9137bb27e60e ("x86/speculation: Add prctl() control for indirect branch speculation") Signed-off-by: Anthony Steinhauser Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5d9d55cf4733c5ced8e1d19ea242a128ab9612d2 Author: Anthony Steinhauser Date: Tue May 19 06:40:42 2020 -0700 x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS. [ Upstream commit 21998a351512eba4ed5969006f0c55882d995ada ] When STIBP is unavailable or enhanced IBRS is available, Linux force-disables the IBPB mitigation of Spectre-BTB even when simultaneous multithreading is disabled. While attempts to enable IBPB using prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent) which are used e.g. by Chromium or OpenSSH succeed with no errors but the application remains silently vulnerable to cross-process Spectre v2 attacks (classical BTB poisoning). At the same time the SYSFS reporting (/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is conditionally enabled when in fact it is unconditionally disabled. STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is unavailable, it makes no sense to force-disable also IBPB, because IBPB protects against cross-process Spectre-BTB attacks regardless of the SMT state. At the same time since missing STIBP was only observed on AMD CPUs, AMD does not recommend using STIBP, but recommends using IBPB, so disabling IBPB because of missing STIBP goes directly against AMD's advice: https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning and BTB-poisoning attacks from user space against kernel (and BTB-poisoning attacks from guest against hypervisor), it is not designed to prevent cross-process (or cross-VM) BTB poisoning between processes (or VMs) running on the same core. Therefore, even with enhanced IBRS it is necessary to flush the BTB during context-switches, so there is no reason to force disable IBPB when enhanced IBRS is available. Enable the prctl control of IBPB even when STIBP is unavailable or enhanced IBRS is available. Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user") Signed-off-by: Anthony Steinhauser Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9c15bda92203db0510061ee74264e6fdc9aaae9c Author: Thomas Lendacky Date: Thu Dec 13 23:03:54 2018 +0000 x86/speculation: Add support for STIBP always-on preferred mode [ Upstream commit 20c3a2c33e9fdc82e9e8e8d2a6445b3256d20191 ] Different AMD processors may have different implementations of STIBP. When STIBP is conditionally enabled, some implementations would benefit from having STIBP always on instead of toggling the STIBP bit through MSR writes. This preference is advertised through a CPUID feature bit. When conditional STIBP support is requested at boot and the CPU advertises STIBP always-on mode as preferred, switch to STIBP "on" support. To show that this transition has occurred, create a new spectre_v2_user_mitigation value and a new spectre_v2_user_strings message. The new mitigation value is used in spectre_v2_user_select_mitigation() to print the new mitigation message as well as to return a new string from stibp_state(). Signed-off-by: Tom Lendacky Signed-off-by: Thomas Gleixner Cc: Andrea Arcangeli Cc: Konrad Rzeszutek Wilk Cc: Jiri Kosina Cc: Borislav Petkov Cc: Tim Chen Cc: David Woodhouse Link: https://lkml.kernel.org/r/20181213230352.6937.74943.stgit@tlendack-t1.amdoffice.net Signed-off-by: Sasha Levin commit 863d6dcbaab8700ef63a64b41271a450c0a5f755 Author: Waiman Long Date: Wed Dec 5 14:49:27 2018 -0500 x86/speculation: Change misspelled STIPB to STIBP [ Upstream commit aa77bfb354c495fc4361199e63fc5765b9e1e783 ] STIBP stands for Single Thread Indirect Branch Predictors. The acronym, however, can be easily mis-spelled as STIPB. It is perhaps due to the presence of another related term - IBPB (Indirect Branch Predictor Barrier). Fix the mis-spelling in the code. Signed-off-by: Waiman Long Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Andi Kleen Cc: David Woodhouse Cc: Ingo Molnar Cc: Jiri Kosina Cc: Josh Poimboeuf Cc: KarimAllah Ahmed Cc: Konrad Rzeszutek Wilk Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tim Chen Cc: x86-ml Link: https://lkml.kernel.org/r/1544039368-9009-1-git-send-email-longman@redhat.com Signed-off-by: Sasha Levin commit 2e4a2d83359b638cf26798d5f6f73834922c1840 Author: Paolo Bonzini Date: Tue May 19 05:34:41 2020 -0400 KVM: x86: only do L1TF workaround on affected processors [ Upstream commit d43e2675e96fc6ae1a633b6a69d296394448cc32 ] KVM stores the gfn in MMIO SPTEs as a caching optimization. These are split in two parts, as in "[high 11111 low]", to thwart any attempt to use these bits in an L1TF attack. This works as long as there are 5 free bits between MAXPHYADDR and bit 50 (inclusive), leaving bit 51 free so that the MMIO access triggers a reserved-bit-set page fault. The bit positions however were computed wrongly for AMD processors that have encryption support. In this case, x86_phys_bits is reduced (for example from 48 to 43, to account for the C bit at position 47 and four bits used internally to store the SEV ASID and other stuff) while x86_cache_bits in would remain set to 48, and _all_ bits between the reduced MAXPHYADDR and bit 51 are set. Then low_phys_bits would also cover some of the bits that are set in the shadow_mmio_value, terribly confusing the gfn caching mechanism. To fix this, avoid splitting gfns as long as the processor does not have the L1TF bug (which includes all AMD processors). When there is no splitting, low_phys_bits can be set to the reduced MAXPHYADDR removing the overlap. This fixes "npt=0" operation on EPYC processors. Thanks to Maxim Levitsky for bisecting this bug. Cc: stable@vger.kernel.org Fixes: 52918ed5fcf0 ("KVM: SVM: Override default MMIO mask if memory encryption is enabled") Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit bbedee8c4970f97e84030197024c6f9120abbf90 Author: Sean Christopherson Date: Thu Aug 1 13:35:23 2019 -0700 KVM: x86/mmu: Consolidate "is MMIO SPTE" code [ Upstream commit 26c44a63a291893e0a00f01e96b6e1d0310a79a9 ] Replace the open-coded "is MMIO SPTE" checks in the MMU warnings related to software-based access/dirty tracking to make the code slightly more self-documenting. No functional change intended. Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 40202c0356674bee7c4e53ea7cd9216aab1544c4 Author: Kai Huang Date: Fri May 3 01:40:25 2019 -0700 kvm: x86: Fix L1TF mitigation for shadow MMU [ Upstream commit 61455bf26236e7f3d72705382a6437fdfd1bd0af ] Currently KVM sets 5 most significant bits of physical address bits reported by CPUID (boot_cpu_data.x86_phys_bits) for nonpresent or reserved bits SPTE to mitigate L1TF attack from guest when using shadow MMU. However for some particular Intel CPUs the physical address bits of internal cache is greater than physical address bits reported by CPUID. Use the kernel's existing boot_cpu_data.x86_cache_bits to determine the five most significant bits. Doing so improves KVM's L1TF mitigation in the unlikely scenario that system RAM overlaps the high order bits of the "real" physical address space as reported by CPUID. This aligns with the kernel's warnings regarding L1TF mitigation, e.g. in the above scenario the kernel won't warn the user about lack of L1TF mitigation if x86_cache_bits is greater than x86_phys_bits. Also initialize shadow_nonpresent_or_rsvd_mask explicitly to make it consistent with other 'shadow_{xxx}_mask', and opportunistically add a WARN once if KVM's L1TF mitigation cannot be applied on a system that is marked as being susceptible to L1TF. Reviewed-by: Sean Christopherson Signed-off-by: Kai Huang Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 351533725d4779bdadfcd2689a82f2a29edf0c6b Author: Eiichi Tsukata Date: Sat Jun 6 13:26:27 2020 +0900 KVM: x86: Fix APIC page invalidation race [ Upstream commit e649b3f0188f8fd34dd0dde8d43fd3312b902fb2 ] Commit b1394e745b94 ("KVM: x86: fix APIC page invalidation") tried to fix inappropriate APIC page invalidation by re-introducing arch specific kvm_arch_mmu_notifier_invalidate_range() and calling it from kvm_mmu_notifier_invalidate_range_start. However, the patch left a possible race where the VMCS APIC address cache is updated *before* it is unmapped: (Invalidator) kvm_mmu_notifier_invalidate_range_start() (Invalidator) kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD) (KVM VCPU) vcpu_enter_guest() (KVM VCPU) kvm_vcpu_reload_apic_access_page() (Invalidator) actually unmap page Because of the above race, there can be a mismatch between the host physical address stored in the APIC_ACCESS_PAGE VMCS field and the host physical address stored in the EPT entry for the APIC GPA (0xfee0000). When this happens, the processor will not trap APIC accesses, and will instead show the raw contents of the APIC-access page. Because Windows OS periodically checks for unexpected modifications to the LAPIC register, this will show up as a BSOD crash with BugCheck CRITICAL_STRUCTURE_CORRUPTION (109) we are currently seeing in https://bugzilla.redhat.com/show_bug.cgi?id=1751017. The root cause of the issue is that kvm_arch_mmu_notifier_invalidate_range() cannot guarantee that no additional references are taken to the pages in the range before kvm_mmu_notifier_invalidate_range_end(). Fortunately, this case is supported by the MMU notifier API, as documented in include/linux/mmu_notifier.h: * If the subsystem * can't guarantee that no additional references are taken to * the pages in the range, it has to implement the * invalidate_range() notifier to remove any references taken * after invalidate_range_start(). The fix therefore is to reload the APIC-access page field in the VMCS from kvm_mmu_notifier_invalidate_range() instead of ..._range_start(). Cc: stable@vger.kernel.org Fixes: b1394e745b94 ("KVM: x86: fix APIC page invalidation") Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=197951 Signed-off-by: Eiichi Tsukata Message-Id: <20200606042627.61070-1-eiichi.tsukata@nutanix.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 3273c45d28735466b94b646346d8462f7a53182a Author: Tony Luck Date: Wed May 20 09:35:46 2020 -0700 x86/{mce,mm}: Unmap the entire page if the whole page is affected and poisoned commit 17fae1294ad9d711b2c3dd0edef479d40c76a5e8 upstream. An interesting thing happened when a guest Linux instance took a machine check. The VMM unmapped the bad page from guest physical space and passed the machine check to the guest. Linux took all the normal actions to offline the page from the process that was using it. But then guest Linux crashed because it said there was a second machine check inside the kernel with this stack trace: do_memory_failure set_mce_nospec set_memory_uc _set_memory_uc change_page_attr_set_clr cpa_flush clflush_cache_range_opt This was odd, because a CLFLUSH instruction shouldn't raise a machine check (it isn't consuming the data). Further investigation showed that the VMM had passed in another machine check because is appeared that the guest was accessing the bad page. Fix is to check the scope of the poison by checking the MCi_MISC register. If the entire page is affected, then unmap the page. If only part of the page is affected, then mark the page as uncacheable. This assumes that VMMs will do the logical thing and pass in the "whole page scope" via the MCi_MISC register (since they unmapped the entire page). [ bp: Adjust to x86/entry changes. ] Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()") Reported-by: Jue Wang Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Tested-by: Jue Wang Cc: Link: https://lkml.kernel.org/r/20200520163546.GA7977@agluck-desk2.amr.corp.intel.com Signed-off-by: Greg Kroah-Hartman commit ef1e0bfce4b46b3d378fc49e4b32a36e7fe4595f Author: Michał Mirosław Date: Mon Jun 8 18:50:39 2020 +0200 ALSA: pcm: disallow linking stream to itself commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream. Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code can't handle it. Fixed commit is not where bug was introduced, but changes the context significantly. Cc: stable@vger.kernel.org Fixes: 0888c321de70 ("pcm_native: switch to fdget()/fdput()") Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/89c4a2487609a0ed6af3ecf01cc972bdc59a7a2d.1591634956.git.mirq-linux@rere.qmqm.pl Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7c3261d8bc343a20c748b6a9fcb51218167cba45 Author: Christophe JAILLET Date: Sat May 30 15:35:37 2020 +0200 crypto: cavium/nitrox - Fix 'nitrox_get_first_device()' when ndevlist is fully iterated commit 320bdbd816156f9ca07e5fed7bfb449f2908dda7 upstream. When a list is completely iterated with 'list_for_each_entry(x, ...)', x is not NULL at the end. While at it, remove a useless initialization of the ndev variable. It is overridden by 'list_for_each_entry'. Fixes: f2663872f073 ("crypto: cavium - Register the CNN55XX supported crypto algorithms.") Cc: Signed-off-by: Christophe JAILLET Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3834e636b3910f59b4f499e3cf4139937cc078dc Author: Rafael J. Wysocki Date: Thu May 21 19:08:09 2020 +0200 PM: runtime: clk: Fix clk_pm_runtime_get() error path commit 64c7d7ea22d86cacb65d0c097cc447bc0e6d8abd upstream. clk_pm_runtime_get() assumes that the PM-runtime usage counter will be dropped by pm_runtime_get_sync() on errors, which is not the case, so PM-runtime references to devices acquired by the former are leaked on errors returned by the latter. Fix this by modifying clk_pm_runtime_get() to drop the reference if pm_runtime_get_sync() returns an error. Fixes: 9a34b45397e5 clk: Add support for runtime PM Cc: 4.15+ # 4.15+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 1590ebfa8d3578135b78c9b0d5bc9551e6ef556e Author: Justin Chen Date: Mon Apr 20 15:08:49 2020 -0400 spi: bcm-qspi: when tx/rx buffer is NULL set to 0 commit 4df3bea7f9d2ddd9ac2c29ba945c7c4db2def29c upstream. Currently we set the tx/rx buffer to 0xff when NULL. This causes problems with some spi slaves where 0xff is a valid command. Looking at other drivers, the tx/rx buffer is usually set to 0x00 when NULL. Following this convention solves the issue. Fixes: fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver") Signed-off-by: Justin Chen Signed-off-by: Kamal Dasu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200420190853.45614-6-kdasu.kdev@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 75956dbe6e1b9f4708ec3cdc65cd057f3dccb644 Author: Lukas Wunner Date: Fri May 15 17:58:03 2020 +0200 spi: bcm2835aux: Fix controller unregister order commit b9dd3f6d417258ad0beeb292a1bc74200149f15d upstream. The BCM2835aux SPI driver uses devm_spi_register_master() on bind. As a consequence, on unbind, __device_release_driver() first invokes bcm2835aux_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: bcm2835aux_spi_remove() turns off the SPI controller, including its interrupts and clock. The SPI controller is thus no longer usable. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. If their drivers need to access the SPI bus, e.g. to quiesce their interrupts, unbinding will fail. As a rule, devm_spi_register_master() must not be used if the ->remove() hook performs teardown steps which shall be performed after unbinding of slaves. Fix by using the non-devm variant spi_register_master(). Note that the struct spi_master as well as the driver-private data are not freed until after bcm2835aux_spi_remove() has finished, so accessing them is safe. Fixes: 1ea29b39f4c8 ("spi: bcm2835aux: add bcm2835 auxiliary spi device driver") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v4.4+ Cc: Martin Sperl Link: https://lore.kernel.org/r/32f27f4d8242e4d75f9a53f7e8f1f77483b08669.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 21d018ef732c7bf0c98941b1b0f67f3915b93afe Author: Lukas Wunner Date: Mon May 25 14:25:01 2020 +0200 spi: dw: Fix controller unregister order commit ca8b19d61e3fce5d2d7790cde27a0b57bcb3f341 upstream. The Designware SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes dw_spi_remove_host() before unregistering the SPI controller via devres_release_all(). This order is incorrect: dw_spi_remove_host() shuts down the chip, rendering the SPI bus inaccessible even though the SPI controller is still registered. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. Because their drivers cannot access the SPI bus, e.g. to quiesce interrupts, the slave devices may be left in an improper state. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unregistering the controller and specifically after unbinding of slaves. Fix by reverting to the non-devm variant of spi_register_controller(). An alternative approach would be to use device-managed functions for all steps in dw_spi_remove_host(), e.g. by calling devm_add_action_or_reset() on probe. However that approach would add more LoC to the driver and it wouldn't lend itself as well to backporting to stable. Fixes: 04f421e7b0b1 ("spi: dw: use managed resources") Signed-off-by: Lukas Wunner Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org # v3.14+ Cc: Baruch Siach Link: https://lore.kernel.org/r/3fff8cb8ae44a9893840d0688be15bb88c090a14.1590408496.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1b6f42200b8313d3895c26f6553bbc8380bf1c35 Author: Ryusuke Konishi Date: Wed Jun 10 18:41:35 2020 -0700 nilfs2: fix null pointer dereference at nilfs_segctor_do_construct() commit 8301c719a2bd131436438e49130ee381d30933f5 upstream. After commit c3aab9a0bd91 ("mm/filemap.c: don't initiate writeback if mapping has no dirty pages"), the following null pointer dereference has been reported on nilfs2: BUG: kernel NULL pointer dereference, address: 00000000000000a8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI ... RIP: 0010:percpu_counter_add_batch+0xa/0x60 ... Call Trace: __test_set_page_writeback+0x2d3/0x330 nilfs_segctor_do_construct+0x10d3/0x2110 [nilfs2] nilfs_segctor_construct+0x168/0x260 [nilfs2] nilfs_segctor_thread+0x127/0x3b0 [nilfs2] kthread+0xf8/0x130 ... This crash turned out to be caused by set_page_writeback() call for segment summary buffers at nilfs_segctor_prepare_write(). set_page_writeback() can call inc_wb_stat(inode_to_wb(inode), WB_WRITEBACK) where inode_to_wb(inode) is NULL if the inode of underlying block device does not have an associated wb. This fixes the issue by calling inode_attach_wb() in advance to ensure to associate the bdev inode with its wb. Fixes: c3aab9a0bd91 ("mm/filemap.c: don't initiate writeback if mapping has no dirty pages") Reported-by: Walton Hoops Reported-by: Tomas Hlavaty Reported-by: ARAI Shun-ichi Reported-by: Hideki EIRAKU Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Tested-by: Ryusuke Konishi Cc: [5.4+] Link: http://lkml.kernel.org/r/20200608.011819.1399059588922299158.konishi.ryusuke@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c39a90b1a419d7dd3a4cca15c3c925ee26c94f03 Author: Tejun Heo Date: Thu Jun 27 13:39:48 2019 -0700 cgroup, blkcg: Prepare some symbols for module and !CONFIG_CGROUP usages commit 9b0eb69b75bccada2d341d7e7ca342f0cb1c9a6a upstream. btrfs is going to use css_put() and wbc helpers to improve cgroup writeback support. Add dummy css_get() definition and export wbc helpers to prepare for module and !CONFIG_CGROUP builds. [only backport the export of __inode_attach_wb for stable kernels - gregkh] Reported-by: kbuild test robot Reviewed-by: Jan Kara Signed-off-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 37d0897f0599277b875b33bb893a0f41c8eff014 Author: Rafael J. Wysocki Date: Thu Jun 4 19:22:26 2020 +0200 ACPI: PM: Avoid using power resources if there are none for D0 commit 956ad9d98b73f59e442cc119c98ba1e04e94fe6d upstream. As recently reported, some platforms provide a list of power resources for device power state D3hot, through the _PR3 object, but they do not provide a list of power resources for device power state D0. Among other things, this causes acpi_device_get_power() to return D3hot as the current state of the device in question if all of the D3hot power resources are "on", because it sees the power_resources flag set and calls acpi_power_get_inferred_state() which finds that D3hot is the shallowest power state with all of the associated power resources turned "on", so that's what it returns. Moreover, that value takes precedence over the acpi_dev_pm_explicit_get() return value, because it means a deeper power state. The device may very well be in D0 physically at that point, however. Moreover, the presence of _PR3 without _PR0 for a given device means that only one D3-level power state can be supported by it. Namely, because there are no power resources to turn "off" when transitioning the device from D0 into D3cold (which should be supported since _PR3 is present), the evaluation of _PS3 should be sufficient to put it straight into D3cold, but this means that the effect of turning "on" the _PR3 power resources is unclear, so it is better to avoid doing that altogether. Consequently, there is no practical way do distinguish D3cold from D3hot for the device in question and the power states of it can be labeled so that D3hot is the deepest supported one (and Linux assumes that putting a device into D3hot via ACPI may cause power to be removed from it anyway, for legacy reasons). To work around the problem described above modify the ACPI enumeration of devices so that power resources are only used for device power management if the list of D0 power resources is not empty and make it mart D3cold as supported only if that is the case and the D3hot list of power resources is not empty too. Fixes: ef85bdbec444 ("ACPI / scan: Consolidate extraction of power resources lists") Link: https://bugzilla.kernel.org/show_bug.cgi?id=205057 Link: https://lore.kernel.org/linux-acpi/20200603194659.185757-1-hdegoede@redhat.com/ Reported-by: Hans de Goede Tested-by: Hans de Goede Tested-by: youling257@gmail.com Cc: 3.10+ # 3.10+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 9518d35f658cda515d83b3a55e76625100c9d0d2 Author: Ard Biesheuvel Date: Fri May 15 11:36:13 2020 +0200 ACPI: GED: add support for _Exx / _Lxx handler methods commit ea6f3af4c5e63f6981c0b0ab8ebec438e2d5ef40 upstream. Per the ACPI spec, interrupts in the range [0, 255] may be handled in AML using individual methods whose naming is based on the format _Exx or _Lxx, where xx is the hex representation of the interrupt index. Add support for this missing feature to our ACPI GED driver. Cc: v4.9+ # v4.9+ Signed-off-by: Ard Biesheuvel Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c1348a561d567bb1edcded41f720d6c8a178f96d Author: Qiushi Wu Date: Wed May 27 17:35:51 2020 -0500 ACPI: CPPC: Fix reference count leak in acpi_cppc_processor_probe() commit 4d8be4bc94f74bb7d096e1c2e44457b530d5a170 upstream. kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb718348b8" fixed a similar problem. Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance") Signed-off-by: Qiushi Wu Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit efb4903f931a5955ee34fd1be89efa601b761961 Author: Qiushi Wu Date: Wed May 27 16:17:17 2020 -0500 ACPI: sysfs: Fix reference count leak in acpi_sysfs_add_hotplug_profile() commit 6e6c25283dff866308c87b49434c7dbad4774cc0 upstream. kobject_init_and_add() takes reference even when it fails. Thus, when kobject_init_and_add() returns an error, kobject_put() must be called to properly clean up the kobject. Fixes: 3f8055c35836 ("ACPI / hotplug: Introduce user space interface for hotplug profiles") Signed-off-by: Qiushi Wu Cc: 3.10+ # 3.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 93d39b7ee74a1e3e5292f061dbe973b7e4e00a2f Author: Kai-Heng Feng Date: Mon Jun 8 14:26:28 2020 +0800 ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt Dock commit 0c5086f5699906ec8e31ea6509239489f060f2dc upstream. The HP Thunderbolt Dock has two separate USB devices, one is for speaker and one is for headset. Add names for them so userspace can apply UCM settings. Signed-off-by: Kai-Heng Feng Cc: Link: https://lore.kernel.org/r/20200608062630.10806-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4ee198dfe399ad4a3571380d4e633570a06413a6 Author: Takashi Iwai Date: Wed Jun 3 17:37:08 2020 +0200 ALSA: usb-audio: Fix inconsistent card PM state after resume commit 862b2509d157c629dd26d7ac6c6cdbf043d332eb upstream. When a USB-audio interface gets runtime-suspended via auto-pm feature, the driver suspends all functionality and increment chip->num_suspended_intf. Later on, when the system gets suspended to S3, the driver increments chip->num_suspended_intf again, skips the device changes, and sets the card power state to SNDRV_CTL_POWER_D3hot. In return, when the system gets resumed from S3, the resume callback decrements chip->num_suspended_intf. Since this refcount is still not zero (it's been runtime-suspended), the whole resume is skipped. But there is a small pitfall here. The problem is that the driver doesn't restore the card power state after this resume call, leaving it as SNDRV_CTL_POWER_D3hot. So, even after the system resume finishes, the card instance still appears as if it were system-suspended, and this confuses many ioctl accesses that are blocked unexpectedly. In details, we have two issues behind the scene: one is that the card power state is changed only when the refcount becomes zero, and another is that the prior auto-suspend check is kept in a boolean flag. Although the latter problem is almost negligible since the auto-pm feature is imposed only on the primary interface, but this can be a potential problem on the devices with multiple interfaces. This patch addresses those issues by the following: - Replace chip->autosuspended boolean flag with chip->system_suspend counter - At the first system-suspend, chip->num_suspended_intf is recorded to chip->system_suspend - At system-resume, the card power state is restored when the chip->num_suspended_intf refcount reaches to chip->system_suspend, i.e. the state returns to the auto-suspended Also, the patch fixes yet another hidden problem by the code refactoring along with the fixes above: namely, when some resume procedure failed, the driver left chip->num_suspended_intf that was already decreased, and it might lead to the refcount unbalance. In the new code, the refcount decrement is done after the whole resume procedure, and the problem is avoided as well. Fixes: 0662292aec05 ("ALSA: usb-audio: Handle normal and auto-suspend equally") Reported-and-tested-by: Macpaul Lin Cc: Link: https://lore.kernel.org/r/20200603153709.6293-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ca7b960aabb516ad202b94d366d9afb91ae799b5 Author: Hui Wang Date: Mon Jun 8 19:55:41 2020 +0800 ALSA: hda/realtek - add a pintbl quirk for several Lenovo machines commit 573fcbfd319ccef26caa3700320242accea7fd5c upstream. A couple of Lenovo ThinkCentre machines all have 2 front mics and they use the same codec alc623 and have the same pin config, so add a pintbl entry for those machines to apply the fixup ALC283_FIXUP_HEADSET_MIC. Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20200608115541.9531-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 23d0282aec465100238d20bceeaa01d792ec6583 Author: Chuhong Yuan Date: Wed Jun 3 17:24:59 2020 +0800 ALSA: es1688: Add the missed snd_card_free() commit d9b8fbf15d05350b36081eddafcf7b15aa1add50 upstream. snd_es968_pnp_detect() misses a snd_card_free() in a failed path. Add the missed function call to fix it. Fixes: a20971b201ac ("ALSA: Merge es1688 and es968 drivers") Signed-off-by: Chuhong Yuan Cc: Link: https://lore.kernel.org/r/20200603092459.1424093-1-hslester96@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7ba9be0ba0ce951deeaa057bfcf01f2b21a5b89a Author: Ard Biesheuvel Date: Fri May 22 18:15:49 2020 +0200 efi/efivars: Add missing kobject_put() in sysfs entry creation error path commit d8bd8c6e2cfab8b78b537715255be8d7557791c0 upstream. The documentation provided by kobject_init_and_add() clearly spells out the need to call kobject_put() on the kobject if an error is returned. Add this missing call to the error path. Cc: Reported-by: 亿一 Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 3c8cef06c72010300e1618ada6ff01bcc98eab2e Author: Hill Ma Date: Sat Apr 25 13:06:41 2020 -0700 x86/reboot/quirks: Add MacBook6,1 reboot quirk commit 140fd4ac78d385e6c8e6a5757585f6c707085f87 upstream. On MacBook6,1 reboot would hang unless parameter reboot=pci is added. Make it automatic. Signed-off-by: Hill Ma Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20200425200641.GA1554@cslab.localdomain Signed-off-by: Greg Kroah-Hartman commit 5aaf72a0dcb82d5c98f3b7df149baf4c7cf63e19 Author: Anthony Steinhauser Date: Sun Jan 5 12:19:43 2020 -0800 x86/speculation: Prevent rogue cross-process SSBD shutdown commit dbbe2ad02e9df26e372f38cc3e70dab9222c832e upstream. On context switch the change of TIF_SSBD and TIF_SPEC_IB are evaluated to adjust the mitigations accordingly. This is optimized to avoid the expensive MSR write if not needed. This optimization is buggy and allows an attacker to shutdown the SSBD protection of a victim process. The update logic reads the cached base value for the speculation control MSR which has neither the SSBD nor the STIBP bit set. It then OR's the SSBD bit only when TIF_SSBD is different and requests the MSR update. That means if TIF_SSBD of the previous and next task are the same, then the base value is not updated, even if TIF_SSBD is set. The MSR write is not requested. Subsequently if the TIF_STIBP bit differs then the STIBP bit is updated in the base value and the MSR is written with a wrong SSBD value. This was introduced when the per task/process conditional STIPB switching was added on top of the existing SSBD switching. It is exploitable if the attacker creates a process which enforces SSBD and has the contrary value of STIBP than the victim process (i.e. if the victim process enforces STIBP, the attacker process must not enforce it; if the victim process does not enforce STIBP, the attacker process must enforce it) and schedule it on the same core as the victim process. If the victim runs after the attacker the victim becomes vulnerable to Spectre V4. To fix this, update the MSR value independent of the TIF_SSBD difference and dependent on the SSBD mitigation method available. This ensures that a subsequent STIPB initiated MSR write has the correct state of SSBD. [ tglx: Handle X86_FEATURE_VIRT_SSBD & X86_FEATURE_VIRT_SSBD correctly and massaged changelog ] Fixes: 5bfbe3ad5840 ("x86/speculation: Prepare for per task indirect branch speculation control") Signed-off-by: Anthony Steinhauser Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3b8755a30d6443f8fb90652622d78c7951d6fa16 Author: Xiaochun Lee Date: Thu May 14 23:31:07 2020 -0400 x86/PCI: Mark Intel C620 MROMs as having non-compliant BARs commit 1574051e52cb4b5b7f7509cfd729b76ca1117808 upstream. The Intel C620 Platform Controller Hub has MROM functions that have non-PCI registers (undocumented in the public spec) where BAR 0 is supposed to be, which results in messages like this: pci 0000:00:11.0: [Firmware Bug]: reg 0x30: invalid BAR (can't size) Mark these MROM functions as having non-compliant BARs so we don't try to probe any of them. There are no other BARs on these devices. See the Intel C620 Series Chipset Platform Controller Hub Datasheet, May 2019, Document Number 336067-007US, sec 2.1, 35.5, 35.6. [bhelgaas: commit log, add 0xa26d] Link: https://lore.kernel.org/r/1589513467-17070-1-git-send-email-lixiaochun.2888@163.com Signed-off-by: Xiaochun Lee Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fadc4ae12ba16ca71009f41782ea7ebadaef345c Author: Bob Haarman Date: Tue Jun 2 12:30:59 2020 -0700 x86_64: Fix jiffies ODR violation commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch//kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor Reported-by: Alistair Delva Debugged-by: Nick Desaulniers Debugged-by: Sami Tolvanen Suggested-by: Fangrui Song Signed-off-by: Bob Haarman Signed-off-by: Thomas Gleixner Tested-by: Sedat Dilek # build+boot on Reviewed-by: Andi Kleen Reviewed-by: Josh Poimboeuf Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/852 Link: https://lkml.kernel.org/r/20200602193100.229287-1-inglorion@google.com Signed-off-by: Greg Kroah-Hartman commit f6e53d845f77fb07f158a76292aa2c887ce251ea Author: Qu Wenruo Date: Fri Sep 28 07:59:34 2018 +0800 btrfs: tree-checker: Check level for leaves and nodes [ Upstream commit f556faa46eb4e96d0d0772e74ecf66781e132f72 ] Although we have tree level check at tree read runtime, it's completely based on its parent level. We still need to do accurate level check to avoid invalid tree blocks sneak into kernel space. The check itself is simple, for leaf its level should always be 0. For nodes its level should be in range [1, BTRFS_MAX_LEVEL - 1]. Signed-off-by: Qu Wenruo Reviewed-by: Su Yue Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e4df4140aceb68ac9fd0258e5a03300e0f35a246 Author: Miklos Szeredi Date: Thu May 14 16:44:24 2020 +0200 aio: fix async fsync creds commit 530f32fc370fd1431ea9802dbc53ab5601dfccdb upstream. Avi Kivity reports that on fuse filesystems running in a user namespace asyncronous fsync fails with EOVERFLOW. The reason is that f_ops->fsync() is called with the creds of the kthread performing aio work instead of the creds of the process originally submitting IOCB_CMD_FSYNC. Fuse sends the creds of the caller in the request header and it needs to translate the uid and gid into the server's user namespace. Since the kthread is running in init_user_ns, the translation will fail and the operation returns an error. It can be argued that fsync doesn't actually need any creds, but just zeroing out those fields in the header (as with requests that currently don't take creds) is a backward compatibility risk. Instead of working around this issue in fuse, solve the core of the problem by calling the filesystem with the proper creds. Reported-by: Avi Kivity Tested-by: Giuseppe Scrivano Fixes: c9582eb0ff7d ("fuse: Fail all requests with invalid uids or gids") Cc: stable@vger.kernel.org # 4.18+ Signed-off-by: Miklos Szeredi Reviewed-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit cdfd1ec69045872a8deb873cc22fb49cbbf264a3 Author: Waiman Long Date: Thu Jun 4 16:48:21 2020 -0700 mm: add kvfree_sensitive() for freeing sensitive data objects [ Upstream commit d4eaa2837851db2bfed572898bfc17f9a9f9151e ] For kvmalloc'ed data object that contains sensitive information like cryptographic keys, we need to make sure that the buffer is always cleared before freeing it. Using memset() alone for buffer clearing may not provide certainty as the compiler may compile it away. To be sure, the special memzero_explicit() has to be used. This patch introduces a new kvfree_sensitive() for freeing those sensitive data objects allocated by kvmalloc(). The relevant places where kvfree_sensitive() can be used are modified to use it. Fixes: 4f0882491a14 ("KEYS: Avoid false positive ENOMEM error on key read") Suggested-by: Linus Torvalds Signed-off-by: Waiman Long Signed-off-by: Andrew Morton Reviewed-by: Eric Biggers Acked-by: David Howells Cc: Jarkko Sakkinen Cc: James Morris Cc: "Serge E. Hallyn" Cc: Joe Perches Cc: Matthew Wilcox Cc: David Rientjes Cc: Uladzislau Rezki Link: http://lkml.kernel.org/r/20200407200318.11711-1-longman@redhat.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9b91eb92713f2c15a5bf761529121776e88a695d Author: Masami Hiramatsu Date: Wed May 6 23:29:12 2020 +0900 perf probe: Accept the instance number of kretprobe event [ Upstream commit c6aab66a728b6518772c74bd9dff66e1a1c652fd ] Since the commit 6a13a0d7b4d1 ("ftrace/kprobe: Show the maxactive number on kprobe_events") introduced to show the instance number of kretprobe events, the length of the 1st format of the kprobe event will not 1, but it can be longer. This caused a parser error in perf-probe. Skip the length check the 1st format of the kprobe event to accept this instance number. Without this fix: # perf probe -a vfs_read%return Added new event: probe:vfs_read__return (on vfs_read%return) You can now use it in all perf tools, such as: perf record -e probe:vfs_read__return -aR sleep 1 # perf probe -l Semantic error :Failed to parse event name: r16:probe/vfs_read__return Error: Failed to show event list. And with this fixes: # perf probe -a vfs_read%return ... # perf probe -l probe:vfs_read__return (on vfs_read%return) Fixes: 6a13a0d7b4d1 ("ftrace/kprobe: Show the maxactive number on kprobe_events") Reported-by: Yuxuan Shui Signed-off-by: Masami Hiramatsu Tested-by: Yuxuan Shui Cc: Jiri Olsa Cc: Namhyung Kim Cc: stable@vger.kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207587 Link: http://lore.kernel.org/lkml/158877535215.26469.1113127926699134067.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5c1a2f23d2e17bb9ac9cbb2ab7433cabcb4c9826 Author: Kim Phillips Date: Fri Apr 17 09:33:56 2020 -0500 x86/cpu/amd: Make erratum #1054 a legacy erratum [ Upstream commit e2abfc0448a46d8a137505aa180caf14070ec535 ] Commit 21b5ee59ef18 ("x86/cpu/amd: Enable the fixed Instructions Retired counter IRPERF") mistakenly added erratum #1054 as an OS Visible Workaround (OSVW) ID 0. Erratum #1054 is not OSVW ID 0 [1], so make it a legacy erratum. There would never have been a false positive on older hardware that has OSVW bit 0 set, since the IRPERF feature was not available. However, save a couple of RDMSR executions per thread, on modern system configurations that correctly set non-zero values in their OSVW_ID_Length MSRs. [1] Revision Guide for AMD Family 17h Models 00h-0Fh Processors. The revision guide is available from the bugzilla link below. Fixes: 21b5ee59ef18 ("x86/cpu/amd: Enable the fixed Instructions Retired counter IRPERF") Reported-by: Andrew Cooper Signed-off-by: Kim Phillips Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200417143356.26054-1-kim.phillips@amd.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Signed-off-by: Sasha Levin commit 0eb10c10327c9b010c73e5878304a46a589d3228 Author: Jason Gunthorpe Date: Mon Apr 6 21:44:26 2020 -0300 RDMA/uverbs: Make the event_queue fds return POLLERR when disassociated [ Upstream commit eb356e6dc15a30af604f052cd0e170450193c254 ] If is_closed is set, and the event list is empty, then read() will return -EIO without blocking. After setting is_closed in ib_uverbs_free_event_queue(), we do trigger a wake_up on the poll_wait, but the fops->poll() function does not check it, so poll will continue to sleep on an empty list. Fixes: 14e23bd6d221 ("RDMA/core: Fix locking in ib_uverbs_event_read") Link: https://lore.kernel.org/r/0-v1-ace813388969+48859-uverbs_poll_fix%25jgg@mellanox.com Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ec8dfaee98d616fef55d978fb8ae9beac9c55aee Author: Masashi Honma Date: Tue May 5 06:44:43 2020 +0900 ath9k_htc: Silence undersized packet warnings [ Upstream commit 450edd2805982d14ed79733a82927d2857b27cac ] Some devices like TP-Link TL-WN722N produces this kind of messages frequently. kernel: ath: phy0: Short RX data len, dropping (dlen: 4) This warning is useful for developers to recognize that the device (Wi-Fi dongle or USB hub etc) is noisy but not for general users. So this patch make this warning to debug message. Reported-By: Denis Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207539 Fixes: cd486e627e67 ("ath9k_htc: Discard undersized packets") Signed-off-by: Masashi Honma Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200504214443.4485-1-masashi.honma@gmail.com Signed-off-by: Sasha Levin commit e59179b923406ec3c730823f165a45f1d4d8ce93 Author: Cédric Le Goater Date: Wed Apr 29 09:51:20 2020 +0200 powerpc/xive: Clear the page tables for the ESB IO mapping [ Upstream commit a101950fcb78b0ba20cd487be6627dea58d55c2b ] Commit 1ca3dec2b2df ("powerpc/xive: Prevent page fault issues in the machine crash handler") fixed an issue in the FW assisted dump of machines using hash MMU and the XIVE interrupt mode under the POWER hypervisor. It forced the mapping of the ESB page of interrupts being mapped in the Linux IRQ number space to make sure the 'crash kexec' sequence worked during such an event. But it didn't handle the un-mapping. This mapping is now blocking the removal of a passthrough IO adapter under the POWER hypervisor because it expects the guest OS to have cleared all page table entries related to the adapter. If some are still present, the RTAS call which isolates the PCI slot returns error 9001 "valid outstanding translations". Remove these mapping in the IRQ data cleanup routine. Under KVM, this cleanup is not required because the ESB pages for the adapter interrupts are un-mapped from the guest by the hypervisor in the KVM XIVE native device. This is now redundant but it's harmless. Fixes: 1ca3dec2b2df ("powerpc/xive: Prevent page fault issues in the machine crash handler") Cc: stable@vger.kernel.org # v5.5+ Signed-off-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200429075122.1216388-2-clg@kaod.org Signed-off-by: Sasha Levin commit 9a8d79b079b32d6b6821a54fbffbfcd17b97bf1f Author: Thomas Falcon Date: Thu May 28 11:19:17 2020 -0500 drivers/net/ibmvnic: Update VNIC protocol version reporting [ Upstream commit 784688993ebac34dffe44a9f2fabbe126ebfd4db ] VNIC protocol version is reported in big-endian format, but it is not byteswapped before logging. Fix that, and remove version comparison as only one protocol version exists at this time. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c9b475029d06004e1faf370070631e8deb290213 Author: Dennis Kadioglu Date: Tue May 26 23:03:13 2020 -0700 Input: synaptics - add a second working PNP_ID for Lenovo T470s [ Upstream commit 642aa86eaf8f1e6fe894f20fd7f12f0db52ee03c ] The Lenovo Thinkpad T470s I own has a different touchpad with "LEN007a" instead of the already included PNP ID "LEN006c". However, my touchpad seems to work well without any problems using RMI. So this patch adds the other PNP ID. Signed-off-by: Dennis Kadioglu Link: https://lore.kernel.org/r/ff770543cd53ae818363c0fe86477965@mail.eclipso.de Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit e147393117d97a8601014650d3625c2230aed06e Author: Jens Axboe Date: Tue May 26 09:38:31 2020 -0600 sched/fair: Don't NUMA balance for kthreads [ Upstream commit 18f855e574d9799a0e7489f8ae6fd8447d0dd74a ] Stefano reported a crash with using SQPOLL with io_uring: BUG: kernel NULL pointer dereference, address: 00000000000003b0 CPU: 2 PID: 1307 Comm: io_uring-sq Not tainted 5.7.0-rc7 #11 RIP: 0010:task_numa_work+0x4f/0x2c0 Call Trace: task_work_run+0x68/0xa0 io_sq_thread+0x252/0x3d0 kthread+0xf9/0x130 ret_from_fork+0x35/0x40 which is task_numa_work() oopsing on current->mm being NULL. The task work is queued by task_tick_numa(), which checks if current->mm is NULL at the time of the call. But this state isn't necessarily persistent, if the kthread is using use_mm() to temporarily adopt the mm of a task. Change the task_tick_numa() check to exclude kernel threads in general, as it doesn't make sense to attempt ot balance for kthreads anyway. Reported-by: Stefano Garzarella Signed-off-by: Jens Axboe Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Link: https://lore.kernel.org/r/865de121-8190-5d30-ece5-3b097dc74431@kernel.dk Signed-off-by: Sasha Levin commit 1f943261c82349b99537af9b5cbde8ee3c446611 Author: Fredrik Strupe Date: Mon May 18 19:41:11 2020 +0100 ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hook [ Upstream commit 3866f217aaa81bf7165c7f27362eee5d7919c496 ] call_undef_hook() in traps.c applies the same instr_mask for both 16-bit and 32-bit thumb instructions. If instr_mask then is only 16 bits wide (0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb instructions will be masked out. This makes the function match 32-bit thumb instructions where the second half-word is equal to instr_val, regardless of the first half-word. The result in this case is that all undefined 32-bit thumb instructions with the second half-word equal to 0xde01 (udf #1) work as breakpoints and will raise a SIGTRAP instead of a SIGILL, instead of just the one intended 16-bit instruction. An example of such an instruction is 0xeaa0de01, which is unallocated according to Arm ARM and should raise a SIGILL, but instead raises a SIGTRAP. This patch fixes the issue by setting all the bits in instr_mask, which will still match the intended 16-bit thumb instruction (where the upper half is always 0), but not any 32-bit thumb instructions. Cc: Oleg Nesterov Signed-off-by: Fredrik Strupe Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 7c4bc133260ee35fd98062cba3a4abe9c83d2115 Author: Stephan Gerhold Date: Thu Apr 9 13:49:03 2020 -0700 Input: mms114 - fix handling of mms345l [ Upstream commit 3f8f770575d911c989043d8f0fb8dec96360c41c ] MMS345L is another first generation touch screen from Melfas, which uses the same registers as MMS152. However, using I2C_M_NOSTART for it causes errors when reading: i2c i2c-0: sendbytes: NAK bailout. mms114 0-0048: __mms114_read_reg: i2c transfer failed (-5) The driver works fine as soon as I2C_M_NOSTART is removed. Reviewed-by: Andi Shyti Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200405170904.61512-1-stephan@gerhold.net [dtor: removed separate mms345l handling, made everyone use standard transfer mode, propagated the 10bit addressing flag to the read part of the transfer as well.] Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit e3780a268173d472d1e873b4b25283f8db0d6f66 Author: Su Kang Yin Date: Thu Jun 11 19:50:47 2020 +0800 crypto: talitos - fix ECB and CBC algs ivsize commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize") wrongly modified CBC algs ivsize instead of ECB aggs ivsize. This restore the CBC algs original ivsize of removes ECB's ones. Fixes: e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize") Signed-off-by: Su Kang Yin Reviewed-by: Christophe Leroy Signed-off-by: Greg Kroah-Hartman commit 227af79e6cb0ee3faeb8c70be4bc0aec0b09ea25 Author: Qu Wenruo Date: Thu Aug 22 10:14:15 2019 +0800 btrfs: Detect unbalanced tree with empty leaf before crashing btree operations commit 62fdaa52a3d00a875da771719b6dc537ca79fce1 upstream. [BUG] With crafted image, btrfs will panic at btree operations: kernel BUG at fs/btrfs/ctree.c:3894! invalid opcode: 0000 [#1] SMP PTI CPU: 0 PID: 1138 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9 RIP: 0010:__push_leaf_left+0x6b6/0x6e0 RSP: 0018:ffffc0bd4128b990 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa0a4ab8f0e38 RCX: 0000000000000000 RDX: ffffa0a280000000 RSI: 0000000000000000 RDI: ffffa0a4b3814000 RBP: ffffc0bd4128ba38 R08: 0000000000001000 R09: ffffc0bd4128b948 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000240 R13: ffffa0a4b556fb60 R14: ffffa0a4ab8f0af0 R15: ffffa0a4ab8f0af0 FS: 0000000000000000(0000) GS:ffffa0a4b7a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2461c80020 CR3: 000000022b32a006 CR4: 00000000000206f0 Call Trace: ? _cond_resched+0x1a/0x50 push_leaf_left+0x179/0x190 btrfs_del_items+0x316/0x470 btrfs_del_csums+0x215/0x3a0 __btrfs_free_extent.isra.72+0x5a7/0xbe0 __btrfs_run_delayed_refs+0x539/0x1120 btrfs_run_delayed_refs+0xdb/0x1b0 btrfs_commit_transaction+0x52/0x950 ? start_transaction+0x94/0x450 transaction_kthread+0x163/0x190 kthread+0x105/0x140 ? btrfs_cleanup_transaction+0x560/0x560 ? kthread_destroy_worker+0x50/0x50 ret_from_fork+0x35/0x40 Modules linked in: ---[ end trace c2425e6e89b5558f ]--- [CAUSE] The offending csum tree looks like this: checksum tree key (CSUM_TREE ROOT_ITEM 0) node 29741056 level 1 items 14 free 107 generation 19 owner CSUM_TREE ... key (EXTENT_CSUM EXTENT_CSUM 85975040) block 29630464 gen 17 key (EXTENT_CSUM EXTENT_CSUM 89911296) block 29642752 gen 17 <<< key (EXTENT_CSUM EXTENT_CSUM 92274688) block 29646848 gen 17 ... leaf 29630464 items 6 free space 1 generation 17 owner CSUM_TREE item 0 key (EXTENT_CSUM EXTENT_CSUM 85975040) itemoff 3987 itemsize 8 range start 85975040 end 85983232 length 8192 ... leaf 29642752 items 0 free space 3995 generation 17 owner 0 ^ empty leaf invalid owner ^ leaf 29646848 items 1 free space 602 generation 17 owner CSUM_TREE item 0 key (EXTENT_CSUM EXTENT_CSUM 92274688) itemoff 627 itemsize 3368 range start 92274688 end 95723520 length 3448832 So we have a corrupted csum tree where one tree leaf is completely empty, causing unbalanced btree, thus leading to unexpected btree balance error. [FIX] For this particular case, we handle it in two directions to catch it: - Check if the tree block is empty through btrfs_verify_level_key() So that invalid tree blocks won't be read out through btrfs_search_slot() and its variants. - Check 0 tree owner in tree checker NO tree is using 0 as its tree owner, detect it and reject at tree block read time. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202821 Reviewed-by: Nikolay Borisov Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Vikash Bansal Signed-off-by: Greg Kroah-Hartman commit 8cb9b069fa631b613bbbd6f63887190e55cafa3c Author: Anand Jain Date: Sat Jan 19 14:48:55 2019 +0800 btrfs: merge btrfs_find_device and find_device commit 09ba3bc9dd150457c506e4661380a6183af651c1 upstream. Both btrfs_find_device() and find_device() does the same thing except that the latter does not take the seed device onto account in the device scanning context. We can merge them. Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba [4.19.y backport notes: Vikash : - To apply this patch, a portion of commit e4319cd9cace was used to change the first argument of function "btrfs_find_device" from "struct btrfs_fs_info" to "struct btrfs_fs_devices". Signed-off-by: Vikash Bansal Signed-off-by: Greg Kroah-Hartman commit e18590b3e242638e873a61d299abf8a9df446236 Author: Christophe Leroy Date: Thu Jan 23 08:34:18 2020 +0000 lib: Reduce user_access_begin() boundaries in strncpy_from_user() and strnlen_user() commit ab10ae1c3bef56c29bac61e1201c752221b87b41 upstream. The range passed to user_access_begin() by strncpy_from_user() and strnlen_user() starts at 'src' and goes up to the limit of userspace although reads will be limited by the 'count' param. On 32 bits powerpc (book3s/32) access has to be granted for each 256Mbytes segment and the cost increases with the number of segments to unlock. Limit the range with 'count' param. Fixes: 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'") Signed-off-by: Christophe Leroy Signed-off-by: Linus Torvalds Signed-off-by: Miles Chen Signed-off-by: Greg Kroah-Hartman commit b46395f443d61ec34cd9e42d05cae1eebbd4c31a Author: Will Deacon Date: Sat Jan 19 21:56:05 2019 +0000 x86: uaccess: Inhibit speculation past access_ok() in user_access_begin() commit 6e693b3ffecb0b478c7050b44a4842854154f715 upstream. Commit 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'") makes the access_ok() check part of the user_access_begin() preceding a series of 'unsafe' accesses. This has the desirable effect of ensuring that all 'unsafe' accesses have been range-checked, without having to pick through all of the callsites to verify whether the appropriate checking has been made. However, the consolidated range check does not inhibit speculation, so it is still up to the caller to ensure that they are not susceptible to any speculative side-channel attacks for user addresses that ultimately fail the access_ok() check. This is an oversight, so use __uaccess_begin_nospec() to ensure that speculation is inhibited until the access_ok() check has passed. Reported-by: Julien Thierry Signed-off-by: Will Deacon Signed-off-by: Linus Torvalds Cc: Miles Chen Signed-off-by: Greg Kroah-Hartman commit e8236726c616d8843bf936e2bafefc2540bb87a7 Author: Stafford Horne Date: Tue Jan 8 22:15:15 2019 +0900 arch/openrisc: Fix issues with access_ok() commit 9cb2feb4d21d97386eb25c7b67e2793efcc1e70a upstream. The commit 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'") exposed incorrect implementations of access_ok() macro in several architectures. This change fixes 2 issues found in OpenRISC. OpenRISC was not properly using parenthesis for arguments and also using arguments twice. This patch fixes those 2 issues. I test booted this patch with v5.0-rc1 on qemu and it's working fine. Cc: Guenter Roeck Cc: Linus Torvalds Reported-by: Linus Torvalds Signed-off-by: Stafford Horne Signed-off-by: Linus Torvalds Signed-off-by: Miles Chen Signed-off-by: Greg Kroah-Hartman commit 3b051f174986b9c1f8b834522763b70131b50e37 Author: Linus Torvalds Date: Sun Jan 6 11:15:04 2019 -0800 Fix 'acccess_ok()' on alpha and SH commit 94bd8a05cd4de344a9a57e52ef7d99550251984f upstream. Commit 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'") broke both alpha and SH booting in qemu, as noticed by Guenter Roeck. It turns out that the bug wasn't actually in that commit itself (which would have been surprising: it was mostly a no-op), but in how the addition of access_ok() to the strncpy_from_user() and strnlen_user() functions now triggered the case where those functions would test the access of the very last byte of the user address space. The string functions actually did that user range test before too, but they did it manually by just comparing against user_addr_max(). But with user_access_begin() doing the check (using "access_ok()"), it now exposed problems in the architecture implementations of that function. For example, on alpha, the access_ok() helper macro looked like this: #define __access_ok(addr, size) \ ((get_fs().seg & (addr | size | (addr+size))) == 0) and what it basically tests is of any of the high bits get set (the USER_DS masking value is 0xfffffc0000000000). And that's completely wrong for the "addr+size" check. Because it's off-by-one for the case where we check to the very end of the user address space, which is exactly what the strn*_user() functions do. Why? Because "addr+size" will be exactly the size of the address space, so trying to access the last byte of the user address space will fail the __access_ok() check, even though it shouldn't. As a result, the user string accessor functions failed consistently - because they literally don't know how long the string is going to be, and the max access is going to be that last byte of the user address space. Side note: that alpha macro is buggy for another reason too - it re-uses the arguments twice. And SH has another version of almost the exact same bug: #define __addr_ok(addr) \ ((unsigned long __force)(addr) < current_thread_info()->addr_limit.seg) so far so good: yes, a user address must be below the limit. But then: #define __access_ok(addr, size) \ (__addr_ok((addr) + (size))) is wrong with the exact same off-by-one case: the case when "addr+size" is exactly _equal_ to the limit is actually perfectly fine (think "one byte access at the last address of the user address space") The SH version is actually seriously buggy in another way: it doesn't actually check for overflow, even though it did copy the _comment_ that talks about overflow. So it turns out that both SH and alpha actually have completely buggy implementations of access_ok(), but they happened to work in practice (although the SH overflow one is a serious serious security bug, not that anybody likely cares about SH security). This fixes the problems by using a similar macro on both alpha and SH. It isn't trying to be clever, the end address is based on this logic: unsigned long __ao_end = __ao_a + __ao_b - !!__ao_b; which basically says "add start and length, and then subtract one unless the length was zero". We can't subtract one for a zero length, or we'd just hit an underflow instead. For a lot of access_ok() users the length is a constant, so this isn't actually as expensive as it initially looks. Reported-and-tested-by: Guenter Roeck Cc: Matt Turner Cc: Yoshinori Sato Signed-off-by: Linus Torvalds Signed-off-by: Miles Chen Signed-off-by: Greg Kroah-Hartman commit 216284c4a126b28469eb0bf4994c669e251f47ba Author: Linus Torvalds Date: Fri Jan 4 12:56:09 2019 -0800 make 'user_access_begin()' do 'access_ok()' commit 594cc251fdd0d231d342d88b2fdff4bc42fb0690 upstream. Originally, the rule used to be that you'd have to do access_ok() separately, and then user_access_begin() before actually doing the direct (optimized) user access. But experience has shown that people then decide not to do access_ok() at all, and instead rely on it being implied by other operations or similar. Which makes it very hard to verify that the access has actually been range-checked. If you use the unsafe direct user accesses, hardware features (either SMAP - Supervisor Mode Access Protection - on x86, or PAN - Privileged Access Never - on ARM) do force you to use user_access_begin(). But nothing really forces the range check. By putting the range check into user_access_begin(), we actually force people to do the right thing (tm), and the range check vill be visible near the actual accesses. We have way too long a history of people trying to avoid them. Signed-off-by: Linus Torvalds Signed-off-by: Miles Chen Signed-off-by: Greg Kroah-Hartman commit 6f89ad2e79c3d67b8390d74666225b7489e3f280 Author: Lorenz Bauer Date: Thu May 21 15:48:41 2020 +0100 selftests: bpf: fix use of undeclared RET_IF macro commit 634efb750435 ("selftests: bpf: Reset global state between reuseport test runs") uses a macro RET_IF which doesn't exist in the v4.19 tree. It is defined as follows: #define RET_IF(condition, tag, format...) ({ if (CHECK_FAIL(condition)) { printf(tag " " format); return; } }) CHECK_FAIL in turn is defined as: #define CHECK_FAIL(condition) ({ int __ret = !!(condition); int __save_errno = errno; if (__ret) { test__fail(); fprintf(stdout, "%s:FAIL:%d\n", __func__, __LINE__); } errno = __save_errno; __ret; }) Replace occurences of RET_IF with CHECK. This will abort the test binary if clearing the intermediate state fails. Fixes: 634efb750435 ("selftests: bpf: Reset global state between reuseport test runs") Reported-by: kernel test robot Signed-off-by: Lorenz Bauer Signed-off-by: Greg Kroah-Hartman commit 75e36c19ff10836e5d03f87cf17793cf83b59430 Author: Willem de Bruijn Date: Sat May 30 15:41:31 2020 -0400 tun: correct header offsets in napi frags mode [ Upstream commit 96aa1b22bd6bb9fccf62f6261f390ed6f3e7967f ] Tun in IFF_NAPI_FRAGS mode calls napi_gro_frags. Unlike netif_rx and netif_gro_receive, this expects skb->data to point to the mac layer. But skb_probe_transport_header, __skb_get_hash_symmetric, and xdp_do_generic in tun_get_user need skb->data to point to the network header. Flow dissection also needs skb->protocol set, so eth_type_trans has to be called. Ensure the link layer header lies in linear as eth_type_trans pulls ETH_HLEN. Then take the same code paths for frags as for not frags. Push the link layer header back just before calling napi_gro_frags. By pulling up to ETH_HLEN from frag0 into linear, this disables the frag0 optimization in the special case when IFF_NAPI_FRAGS is used with zero length iov[0] (and thus empty skb->linear). Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver") Signed-off-by: Willem de Bruijn Acked-by: Petar Penkov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dbe7cfbfd6f71222858ba206a615923961df5481 Author: Ido Schimmel Date: Mon Jun 1 15:58:55 2020 +0300 vxlan: Avoid infinite loop when suppressing NS messages with invalid options [ Upstream commit 8066e6b449e050675df48e7c4b16c29f00507ff0 ] When proxy mode is enabled the vxlan device might reply to Neighbor Solicitation (NS) messages on behalf of remote hosts. In case the NS message includes the "Source link-layer address" option [1], the vxlan device will use the specified address as the link-layer destination address in its reply. To avoid an infinite loop, break out of the options parsing loop when encountering an option with length zero and disregard the NS message. This is consistent with the IPv6 ndisc code and RFC 4886 which states that "Nodes MUST silently discard an ND packet that contains an option with length zero" [2]. [1] https://tools.ietf.org/html/rfc4861#section-4.3 [2] https://tools.ietf.org/html/rfc4861#section-4.6 Fixes: 4b29dba9c085 ("vxlan: fix nonfunctional neigh_reduce()") Signed-off-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1e74500f99567d6532285576925466c368e9665b Author: Ido Schimmel Date: Mon Jun 1 15:58:54 2020 +0300 bridge: Avoid infinite loop when suppressing NS messages with invalid options [ Upstream commit 53fc685243bd6fb90d90305cea54598b78d3cbfc ] When neighbor suppression is enabled the bridge device might reply to Neighbor Solicitation (NS) messages on behalf of remote hosts. In case the NS message includes the "Source link-layer address" option [1], the bridge device will use the specified address as the link-layer destination address in its reply. To avoid an infinite loop, break out of the options parsing loop when encountering an option with length zero and disregard the NS message. This is consistent with the IPv6 ndisc code and RFC 4886 which states that "Nodes MUST silently discard an ND packet that contains an option with length zero" [2]. [1] https://tools.ietf.org/html/rfc4861#section-4.3 [2] https://tools.ietf.org/html/rfc4861#section-4.6 Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports") Signed-off-by: Ido Schimmel Reported-by: Alla Segal Tested-by: Alla Segal Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8e62792afc2ffebd464fc5f66605fac58c742d4d Author: Vasily Averin Date: Tue Jun 2 15:55:26 2020 +0300 net_failover: fixed rollback in net_failover_open() [ Upstream commit e8224bfe77293494626f6eec1884fee7b87d0ced ] found by smatch: drivers/net/net_failover.c:65 net_failover_open() error: we previously assumed 'primary_dev' could be null (see line 43) Fixes: cfc80d9a1163 ("net: Introduce net_failover driver") Signed-off-by: Vasily Averin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 470e709f63d31db6fe49449d8e37aa2a6c677483 Author: Hangbin Liu Date: Mon Jun 1 11:55:03 2020 +0800 ipv6: fix IPV6_ADDRFORM operation logic [ Upstream commit 79a1f0ccdbb4ad700590f61b00525b390cb53905 ] Socket option IPV6_ADDRFORM supports UDP/UDPLITE and TCP at present. Previously the checking logic looks like: if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) do_some_check; else if (sk->sk_protocol != IPPROTO_TCP) break; After commit b6f6118901d1 ("ipv6: restrict IPV6_ADDRFORM operation"), TCP was blocked as the logic changed to: if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) do_some_check; else if (sk->sk_protocol == IPPROTO_TCP) do_some_check; break; else break; Then after commit 82c9ae440857 ("ipv6: fix restrict IPV6_ADDRFORM operation") UDP/UDPLITE were blocked as the logic changed to: if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) do_some_check; if (sk->sk_protocol == IPPROTO_TCP) do_some_check; if (sk->sk_protocol != IPPROTO_TCP) break; Fix it by using Eric's code and simply remove the break in TCP check, which looks like: if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) do_some_check; else if (sk->sk_protocol == IPPROTO_TCP) do_some_check; else break; Fixes: 82c9ae440857 ("ipv6: fix restrict IPV6_ADDRFORM operation") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman