commit 2c2b15bb0e8872fe2914785ccb276c304417911d Author: Greg Kroah-Hartman Date: Wed May 30 07:52:42 2018 +0200 Linux 4.14.45 commit cd95b6e707122f33bcf85c39c8aedd356de10412 Author: Deepak Rawat Date: Tue May 15 15:39:09 2018 +0200 drm/vmwgfx: Set dmabuf_size when vmw_dmabuf_init is successful commit 91ba9f28a3de97761c2b5fd5df5d88421268e507 upstream. SOU primary plane prepare_fb hook depends upon dmabuf_size to pin up BO (and not call a new vmw_dmabuf_init) when a new fb size is same as current fb. This was changed in a recent commit which is causing page_flip to fail on VM with low display memory and multi-mon failure when cycle monitors from secondary display. Cc: # 4.14, 4.16 Fixes: 20fb5a635a0c ("drm/vmwgfx: Unpin the screen object backup buffer when not used") Signed-off-by: Deepak Rawat Reviewed-by: Sinclair Yeh Signed-off-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit 829484eb3e003a98a2973acbb90babd898e8ca96 Author: Randy Dunlap Date: Fri Dec 8 10:19:19 2017 -0800 kdb: make "mdr" command repeat [ Upstream commit 1e0ce03bf142454f38a5fc050bf4fd698d2d36d8 ] The "mdr" command should repeat (continue) when only Enter/Return is pressed, so make it do so. Signed-off-by: Randy Dunlap Cc: Daniel Thompson Cc: Jason Wessel Cc: kgdb-bugreport@lists.sourceforge.net Signed-off-by: Jason Wessel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 39958037723af522b275f5d3a72f5778d893f5aa Author: Jan Kundrát Date: Thu Jan 25 18:29:15 2018 +0100 pinctrl: mcp23s08: spi: Fix regmap debugfs entries [ Upstream commit 9b3e4207661e67f04c72af15e29f74cd944f5964 ] The SPI version of this chip allows several devices to be present on the same SPI bus via a local address. If this is in action and if the kernel has debugfs, however, the code attempts to create duplicate entries for the regmap's debugfs: mcp23s08 spi1.1: Failed to create debugfs directory This patch simply assigns a local name matching the device logical address to the `struct regmap_config`. No changes are needed for MCP23S18 because that device does not support any logical addressing. Similarly, I2C devices do not need any action, either, because they are already different in their I2C address. A similar problem is present for the pinctrl debugfs instance, but that one is not addressed by this patch. Signed-off-by: Jan Kundrát Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd36ea57d6d58041180c4f7d2c2bf5194c26845d Author: Bjorn Andersson Date: Sun Jan 28 16:59:48 2018 -0800 pinctrl: msm: Use dynamic GPIO numbering [ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ] The base of the TLMM gpiochip should not be statically defined as 0, fix this to not artificially restrict the existence of multiple pinctrl-msm devices. Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver") Reported-by: Timur Tabi Signed-off-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd1a6e338c1b644c52b1d6196f43cca87334a399 Author: Christophe JAILLET Date: Fri Jan 26 23:13:44 2018 +0100 regulator: of: Add a missing 'of_node_put()' in an error handling path of 'of_regulator_match()' [ Upstream commit 30966861a7a2051457be8c49466887d78cc47e97 ] If an unlikely failure in 'of_get_regulator_init_data()' occurs, we must release the reference on the current 'child' node before returning. Signed-off-by: Christophe JAILLET Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 36016bab698b7e604cd25ce6a8fd68951605c687 Author: Laurent Pinchart Date: Sat Jan 13 01:14:23 2018 +0200 ARM: dts: porter: Fix HDMI output routing [ Upstream commit d4b78db6ac3e084e2bdc57d5518bd247c727f396 ] The HDMI encoder is connected to the RGB output of the DU, which is port@0, not port@1. Fix the incorrect DT description. Fixes: c5af8a4248d3 ("ARM: dts: porter: add DU DT support") Signed-off-by: Laurent Pinchart Signed-off-by: Simon Horman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 105479a0278c0054fda5887410016cb3105578f8 Author: Aapo Vienamo Date: Wed Jan 31 14:34:07 2018 +0000 ARM: dts: imx7d: cl-som-imx7: fix pinctrl_enet [ Upstream commit 2bada7ac1fdcbf79a9689bd2ff65fa515ca7a31f ] The missing last digit of the CONFIG values is added. Looks like a typo of some sort when comparing to the downstream dt. This fixes intermittent behavior behaviour of the ethernet controllers. Signed-off-by: Aapo Vienamo Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0b7761ec49e4e4064fe756c0c2133b5621f2d6c0 Author: Filip Sadowski Date: Fri Dec 29 08:50:05 2017 -0500 i40e: Add delay after EMP reset for firmware to recover [ Upstream commit 1fa51a650e1deb50410677f1bd6c0ce17aa48a49 ] This patch adds necessary delay for 4.33 firmware to recover after EMP reset. Without this patch driver occasionally reinitializes structures too quickly to communicate with firmware after EMP reset causing AdminQ to timeout. Signed-off-by: Filip Sadowski Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit be5f9b150b64da61e2819f477c99eab54e31e35f Author: Charles Keepax Date: Mon Feb 12 18:15:44 2018 +0000 regmap: Correct comparison in regmap_cached [ Upstream commit 71df179363a5a733a8932e9afb869760d7559383 ] The cache pointer points to the actual memory used by the cache, as the comparison here is looking for the type of the cache it should check against cache_type. Fixes: 1ea975cf1ef5 ("regmap: Add a function to check if a regmap register is cached") Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 253aa8296a5e517313b4afb1f6b5cad80a9208d1 Author: Peter Rosin Date: Tue Jan 16 17:06:18 2018 +0100 ARM: dts: at91: tse850: use the correct compatible for the eeprom [ Upstream commit 7981190fb5dd710dea08c2613cee3d05e795ca5e ] The used part does contain an eeprom compatible with an Atmel 24c02 chip and it is from NXP, but it is not called 24c02. It's actually a se97b chip. Adjust the compatible accordingly. Fixes: 21dd0ece34c2 ("ARM: dts: at91: add devicetree for the Axentia TSE-850") Signed-off-by: Peter Rosin Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ffc1f3ac180c37699b79965e04613e12b1ce31c0 Author: Sergei Shtylyov Date: Fri Jan 12 23:12:05 2018 +0300 drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2 [ Upstream commit 8525d04ba8a6a9ecfa4bd619c988ca873a5fc2a4 ] According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS and the bias circuit must be enabled after the LVDS I/O pins are enabled, not before. Fix the Gen2 LVDS startup sequence accordingly. While at it, also fix the comment preceding the first LVDCR0 write that still talks about hardcoding the LVDS mode 0. Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support") Signed-off-by: Sergei Shtylyov Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e5b5d9be211e11acd6602b33a1fecea9f78cb850 Author: Sergei Shtylyov Date: Fri Jan 12 23:12:04 2018 +0300 drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3 [ Upstream commit 796ceb9269626afaed3b4955c40d2c3d7a8c5d01 ] According to the latest revisions of the R-Car Gen3 manual, the LVDS mode must be set before the LVDS I/O pins are enabled, not after -- fix the Gen3 LVDS startup sequence accordingly. Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection") Signed-off-by: Sergei Shtylyov Reviewed-by: Laurent Pinchart [Updated comment in rcar_du_lvdsenc_start_gen3()] [Moved Gen2 startup comment update to separate commit] [Fixed =| typo] Tested-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ce7da8b88f6a5602743337f4f08f4009591c4cc7 Author: Richard Haines Date: Mon Nov 13 20:54:22 2017 +0000 netlabel: If PF_INET6, check sk_buff ip header version [ Upstream commit 213d7f94775322ba44e0bbb55ec6946e9de88cea ] When resolving a fallback label, check the sk_buff version as it is possible (e.g. SCTP) to have family = PF_INET6 while receiving ip_hdr(skb)->version = 4. Signed-off-by: Richard Haines Acked-by: Paul Moore Signed-off-by: Paul Moore Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b9cd90c15ea726247cec2097e67008e513d1ae03 Author: Prashant Bhole Date: Thu Feb 15 09:19:26 2018 +0900 selftests/net: fixes psock_fanout eBPF test case [ Upstream commit ddd0010392d9cbcb95b53d11b7cafc67b373ab56 ] eBPF test fails due to verifier failure because log_buf is too small. Fixed by increasing log_buf size Signed-off-by: Prashant Bhole Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ce50075628803a1f248b19ea06a258a4ae48b35 Author: Jiri Olsa Date: Tue Feb 6 19:18:12 2018 +0100 perf tests: Fix dwarf unwind for stripped binaries [ Upstream commit fdf7c49c200d1b9909e2204cec5bd68b48605c71 ] When we strip the perf binary, dwarf unwind test stop to work. The reason is that strip will remove static function symbols, which we need to check for unwind. This change will keep this test working in cases where the global symbols are put into dynamic symbol table, which is the case on x86. It still won't work on powerpc. Making those 5 local functions global, and adding 'test_dwarf_unwind__' to their names. Committer testing: Before: # perf test dwarf 58: DWARF unwind : Ok # strip ~/bin/perf # perf test dwarf 58: DWARF unwind : FAILED! # perf test -v dwarf 58: DWARF unwind : --- start --- test child forked, pid 6590 unwind: thread map already set, dso=/home/acme/bin/perf unwind: access_mem addr 0x7ffce6c48098 val 48563f, offset 1144 unwind: test__dwarf_unwind:ip = 0x4a54e5 (0xa54e5) got: test__dwarf_unwind 0xa54e5, expecting test__dwarf_unwind unwind: '':ip = 0x4a50bb (0xa50bb) failed: got unresolved address 0xa50bb unwind failed test child finished with -1 ---- end ---- DWARF unwind: FAILED! # After: # perf test dwarf 58: DWARF unwind : Ok # strip ~/bin/perf # perf test dwarf 58: DWARF unwind : Ok # # perf test -v dwarf 58: DWARF unwind : --- start --- test child forked, pid 7219 unwind: thread map already set, dso=/home/acme/bin/perf unwind: access_mem addr 0x7fff007da2c8 val 48575f, offset 1144 unwind: test__arch_unwind_sample:ip = 0x589044 (0x189044) got: test__arch_unwind_sample 0x189044, expecting test__arch_unwind_sample unwind: test_dwarf_unwind__thread:ip = 0x4a52f7 (0xa52f7) got: test_dwarf_unwind__thread 0xa52f7, expecting test_dwarf_unwind__thread unwind: test_dwarf_unwind__compare:ip = 0x4a5468 (0xa5468) got: test_dwarf_unwind__compare 0xa5468, expecting test_dwarf_unwind__compare unwind: bsearch:ip = 0x7f6608ae94d8 (0x394d8) got: bsearch 0x394d8, expecting bsearch unwind: test_dwarf_unwind__krava_3:ip = 0x4a54d1 (0xa54d1) got: test_dwarf_unwind__krava_3 0xa54d1, expecting test_dwarf_unwind__krava_3 unwind: test_dwarf_unwind__krava_2:ip = 0x4a550b (0xa550b) got: test_dwarf_unwind__krava_2 0xa550b, expecting test_dwarf_unwind__krava_2 unwind: test_dwarf_unwind__krava_1:ip = 0x4a554b (0xa554b) got: test_dwarf_unwind__krava_1 0xa554b, expecting test_dwarf_unwind__krava_1 unwind: test__dwarf_unwind:ip = 0x4a5605 (0xa5605) got: test__dwarf_unwind 0xa5605, expecting test__dwarf_unwind test child finished with 0 ---- end ---- DWARF unwind: Ok # Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20180206181813.10943-17-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dac66c47df6ce7659a585d0ee2090a4ed06ca439 Author: Jiri Olsa Date: Fri Feb 16 13:36:19 2018 +0100 perf report: Fix memory corruption in --branch-history mode --branch-history [ Upstream commit e3ebaa465136ecfedf9c6f4671df02bf625f8125 ] Jin Yao reported memory corrupton in perf report with branch info used for stack trace: > Following command lines will cause perf crash. > perf record -j call -g -a > perf report --branch-history > > *** Error in `perf': double free or corruption (!prev): 0x00000000104aa040 *** > ======= Backtrace: ========= > /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f6b37254725] > /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f6b3725cf4a] > /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f6b37260abc] > perf[0x51b914] > perf(hist_entry_iter__add+0x1e5)[0x51f305] > perf[0x43cf01] > perf[0x4fa3bf] > perf[0x4fa923] > perf[0x4fd396] > perf[0x4f9614] > perf(perf_session__process_events+0x89e)[0x4fc38e] > perf(cmd_report+0x15d2)[0x43f202] > perf[0x4a059f] > perf(main+0x631)[0x427b71] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6b371fd830] > perf(_start+0x29)[0x427d89] For the cumulative output, we allocate the he_cache array based on the --max-stack option value and populate it with data from 'callchain_cursor'. The --max-stack option value does not ensure now the limit for number of callchain_cursor nodes, so the cumulative iter code will allocate smaller array than it's actually needed and cause above corruption. I think the --max-stack limit does not apply here anyway, because we add callchain data as normal hist entries, while the --max-stack control the limit of single entry callchain depth. Using the callchain_cursor.nr as he_cache array count to fix this. Also removing struct hist_entry_iter::max_stack, because there's no longer any use for it. We need more fixes to ensure that the branch stack code follows properly the logic of --max-stack, which is not the case at the moment. Original-patch-by: Jin Yao Signed-off-by: Jiri Olsa Reported-by: Jin Yao Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20180216123619.GA9945@krava Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fb872eb1131da285ce86d5390b34a912a90f9501 Author: Jiri Olsa Date: Thu Feb 15 13:26:35 2018 +0100 perf tests: Use arch__compare_symbol_names to compare symbols [ Upstream commit ab6e9a99345131cd8e54268d1d0dc04a33f7ed11 ] The symbol search called by machine__find_kernel_symbol_by_name is using internally arch__compare_symbol_names function to compare 2 symbol names, because different archs have different ways of comparing symbols. Mostly for skipping '.' prefixes and similar. In test 1 when we try to find matching symbols in kallsyms and vmlinux, by address and by symbol name. When either is found we compare the pair symbol names by simple strcmp, which is not good enough for reasons explained in previous paragraph. On powerpc this can cause lockup, because even thought we found the pair, the compared names are different and don't match simple strcmp. Following code path is executed, that leads to lockup: - we find the pair in kallsyms by sym->start next_pair: - we compare the names and it fails - we find the pair by sym->name - the pair addresses match so we call goto next_pair because we assume the names match in this case Signed-off-by: Jiri Olsa Tested-by: Naveen N. Rao Acked-by: Naveen N. Rao Cc: Alexander Shishkin Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: 031b84c407c3 ("perf probe ppc: Enable matching against dot symbols automatically") Link: http://lkml.kernel.org/r/20180215122635.24029-10-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit da5329644ad62458fa1eef515afb262848fdb462 Author: Jin Yao Date: Mon Jan 29 18:57:53 2018 +0800 perf report: Fix wrong jump arrow [ Upstream commit b40982e8468b46b8f7f5bba5a7e541ec04a29d7d ] When we use perf report interactive annotate view, we can see the position of jump arrow is not correct. For example, 1. perf record -b ... 2. perf report 3. In interactive mode, select Annotate 'function' Percent│ IPC Cycle │ if (flag) 1.37 │0.4┌── 1 ↓ je 82 │ │ x += x / y + y / x; 0.00 │0.4│ 1310 movsd (%rsp),%xmm0 0.00 │0.4│ 565 movsd 0x8(%rsp),%xmm4 │0.4│ movsd 0x8(%rsp),%xmm1 │0.4│ movsd (%rsp),%xmm3 │0.4│ divsd %xmm4,%xmm0 0.00 │0.4│ 579 divsd %xmm3,%xmm1 │0.4│ movsd (%rsp),%xmm2 │0.4│ addsd %xmm1,%xmm0 │0.4│ addsd %xmm2,%xmm0 0.00 │0.4│ movsd %xmm0,(%rsp) │ │ volatile double x = 1212121212, y = 121212; │ │ │ │ s_randseed = time(0); │ │ srand(s_randseed); │ │ │ │ for (i = 0; i < 2000000000; i++) { 1.37 │0.4└─→ 82: sub $0x1,%ebx 28.21 │0.48 17 ↑ jne 38 The jump arrow in above example is not correct. It should add the width of IPC and Cycle. With this patch, the result is: Percent│ IPC Cycle │ if (flag) 1.37 │0.48 1 ┌──je 82 │ │ x += x / y + y / x; 0.00 │0.48 1310 │ movsd (%rsp),%xmm0 0.00 │0.48 565 │ movsd 0x8(%rsp),%xmm4 │0.48 │ movsd 0x8(%rsp),%xmm1 │0.48 │ movsd (%rsp),%xmm3 │0.48 │ divsd %xmm4,%xmm0 0.00 │0.48 579 │ divsd %xmm3,%xmm1 │0.48 │ movsd (%rsp),%xmm2 │0.48 │ addsd %xmm1,%xmm0 │0.48 │ addsd %xmm2,%xmm0 0.00 │0.48 │ movsd %xmm0,(%rsp) │ │ volatile double x = 1212121212, y = 121212; │ │ │ │ s_randseed = time(0); │ │ srand(s_randseed); │ │ │ │ for (i = 0; i < 2000000000; i++) { 1.37 │0.48 82:└─→sub $0x1,%ebx 28.21 │0.48 17 ↑ jne 38 Committer notes: Please note that only from LBRv5 (according to Jiri) onwards, i.e. >= Skylake is that we'll have the cycles counts in each branch record entry, so to see the Cycles and IPC columns, and be able to test this patch, one need a capable hardware. While applying this I first tested it on a Broadwell class machine and couldn't get those columns, will add code to the annotate browser to warn the user about that, i.e. you have branch records, but no cycles, use a more recent hardware to get the cycles and IPC columns. Signed-off-by: Jin Yao Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jin Yao Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1517223473-14750-1-git-send-email-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4489f688fc3b6e1af1856f5fd0bcc1973cea8ba1 Author: Thomas Richter Date: Wed Feb 14 08:03:03 2018 +0100 perf test: Fix test case inet_pton to accept inlines. [ Upstream commit 0f19a038afdc592176c9a302f0d08be6a68ad74a ] Using Fedora 27 and latest Linux kernel the test case trace+probe_libc_inet_pton.sh fails again on s390. This time is the inlining of functions which does not match. After an update of the glibc (from 2.26-16 to 2.26-24) the output is different The expected output is: __inet_pton (/usr/lib64/libc-2.26.so) gaih_inet (inlined) .... The actual output is: 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.061/0.061/0.061/0.000 ms 0.000 probe_libc:inet_pton:(3ffb2140448)) __inet_pton (inlined) gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so) ... Fix this by being less strict on 'inlined' verses library name and accept both Signed-off-by: Thomas Richter Cc: Heiko Carstens Cc: Hendrik Brueckner Cc: Martin Schwidefsky Link: http://lkml.kernel.org/r/20180214070303.55757-1-tmricht@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 39478b7590d05498a6720c896ea773ca7f93f7d9 Author: Baoquan He Date: Wed Feb 14 13:46:56 2018 +0800 x86/apic: Set up through-local-APIC mode on the boot CPU if 'noapic' specified [ Upstream commit bee3204ec3c49f6f53add9c3962c9012a5c036fa ] Currently the kdump kernel becomes very slow if 'noapic' is specified. Normal kernel doesn't have this bug. Kernel parameter 'noapic' is used to disable IO-APIC in system for testing or special purpose. Here the root cause is that in kdump kernel LAPIC is disabled since commit: 522e664644 ("x86/apic: Disable I/O APIC before shutdown of the local APIC") In this case we need set up through-local-APIC on boot CPU in setup_local_APIC(). In normal kernel the legacy irq mode is enabled by the BIOS. If it is virtual wire mode, the local-APIC has been enabled and set as through-local-APIC. Though we fixed the regression introduced by commit 522e664644, to further improve robustness set up the through-local-APIC mode explicitly, do not rely on the default boot IRQ mode. Signed-off-by: Baoquan He Reviewed-by: Eric W. Biederman Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: douly.fnst@cn.fujitsu.com Cc: joro@8bytes.org Cc: prarit@redhat.com Cc: uobergfe@redhat.com Link: http://lkml.kernel.org/r/20180214054656.3780-7-bhe@redhat.com [ Rewrote the changelog. ] Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4c27990631f1e0f571ae02a84dde68410961b410 Author: Ørjan Eide Date: Tue Jan 30 21:28:33 2018 +0100 drm/rockchip: Respect page offset for PRIME mmap calls [ Upstream commit 57de50af162b67612da99207b061ade3239e57db ] When mapping external DMA-bufs through the PRIME mmap call, we might be given an offset which has to be respected. However for the internal DRM GEM mmap path, we have to ignore the fake mmap offset used to identify the buffer only. Currently the code always zeroes out vma->vm_pgoff, which breaks the former. This patch fixes the problem by moving the vm_pgoff assignment to a function that is used only for GEM mmap path, so that the PRIME path retains the original offset. Cc: Daniel Kurtz Signed-off-by: Ørjan Eide Signed-off-by: Tomasz Figa Signed-off-by: Sean Paul Signed-off-by: Thierry Escande Tested-by: Heiko Stuebner Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-4-thierry.escande@collabora.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8755c4061ea93e6cbb01f9b863bbbe723ce48c38 Author: Joe Perches Date: Tue Dec 5 23:04:58 2017 -0800 MIPS: Octeon: Fix logging messages with spurious periods after newlines [ Upstream commit db6775ca6e0353d2618ca7d5e210fc36ad43bbd4 ] Using a period after a newline causes bad output. Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes") Signed-off-by: Joe Perches Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17886/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f0cf2575cd478bb6b1230db1bba9978927116491 Author: Jake Moroni Date: Sun Feb 18 15:26:04 2018 -0500 dpaa_eth: fix pause capability advertisement logic [ Upstream commit 3021efb440d02bf5b952b6d151c7ffee9bdd49fe ] The ADVERTISED_Asym_Pause bit was being improperly set when both rx and tx pause were enabled. When rx and tx are both enabled, only the ADVERTISED_Pause bit is supposed to be set. Signed-off-by: Jake Moroni Acked-by: Madalin Bucur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 80300e879f9efaf723e7ef07a013271a8933f5f9 Author: Takeshi Kihara Date: Fri Feb 16 15:25:03 2018 +0100 pinctrl: sh-pfc: r8a7796: Fix MOD_SEL register pin assignment for SSI pins group [ Upstream commit b418c4609d5052d174668ad6d13efe023c45c595 ] This patch fixes MOD_SEL1 bit20 and MOD_SEL2 bit20, bit21 pin assignment for SSI pins group. This is a correction to the incorrect implementation of MOD_SEL register pin assignment for R8A7796 SoC specification of R-Car Gen3 Hardware User's Manual Rev.0.51E or later. Fixes: f9aece7344bd ("pinctrl: sh-pfc: Initial R8A7796 PFC support") Signed-off-by: Takeshi Kihara Signed-off-by: Ulrich Hecht Reviewed-by: Simon Horman Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 46d8696c613b4256f625ffd0cbeb88574e3c7033 Author: Tejun Heo Date: Tue Jan 9 10:38:17 2018 -0800 rcu: Call touch_nmi_watchdog() while printing stall warnings [ Upstream commit 3caa973b7a260e7a2a69edc94c300ab9c65148c3 ] When RCU stall warning triggers, it can print out a lot of messages while holding spinlocks. If the console device is slow (e.g. an actual or IPMI serial console), it may end up triggering NMI hard lockup watchdog like the following. commit 162af93fa251958812ebbc5cc622acecda1d0547 Author: Niklas Cassel Date: Mon Feb 19 18:11:13 2018 +0100 net: stmmac: call correct function in stmmac_mac_config_rx_queues_routing() [ Upstream commit 13138de01400762f706c5e956e70660770d61962 ] stmmac_mac_config_rx_queues_routing() incorrectly calls rx_queue_prio() instead of rx_queue_routing(). This looks like a copy paste issue, since stmmac_mac_config_rx_queues_prio() already calls rx_queue_prio(), and both stmmac_mac_config_rx_queues_routing() and stmmac_mac_config_rx_queues_prio() are very similar in structure. Fixes: abe80fdc6ee6 ("net: stmmac: RX queue routing configuration") Signed-off-by: Niklas Cassel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a856adf28238ec7d4b0b990ae886c64fd4a7090 Author: Richard Guy Briggs Date: Wed Feb 21 04:30:07 2018 -0500 audit: return on memory error to avoid null pointer dereference [ Upstream commit 23138ead270045f1b3e912e667967b6094244999 ] If there is a memory allocation error when trying to change an audit kernel feature value, the ignored allocation error will trigger a NULL pointer dereference oops on subsequent use of that pointer. Return instead. Passes audit-testsuite. See: https://github.com/linux-audit/audit-kernel/issues/76 Signed-off-by: Richard Guy Briggs [PM: not necessary (other funcs check for NULL), but a good practice] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a548ba4de32eaabeba42ebd2ba918c3fc68ea101 Author: Rafael J. Wysocki Date: Wed Feb 21 13:24:16 2018 +0100 PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle [ Upstream commit dbdd0f58fd2cdde5cf945c9da67a2d52d32ba550 ] There is a problem with PCMCIA system resume callbacks with respect to suspend-to-idle in which the ->suspend_noirq() callback may be invoked after the ->resume_noirq() one without resuming the system entirely in some cases. This doesn't work for PCMCIA because of the lack of symmetry between its system suspend and system resume "noirq" callbacks. The system resume handling in PCMCIA is split between socket_early_resume() and socket_late_resume() which are called in different phases of system resume and both need to run for socket_suspend() (invoked by the system suspend "noirq" callback) to work. Specifically, socket_suspend() returns an error when called after socket_early_resume() without socket_late_resume(), so if the suspend-to-idle core detects a spurious wakeup event and attempts to put the system back to sleep, that is aborted by the error coming from socket_suspend(). Avoid that by using a new socket state flag, SOCKET_IN_RESUME, to indicate that socket_early_resume() has already run for the socket in which case socket_suspend() will do minimum handling and return 0. This change has been tested on my venerable Toshiba Portege R500 (which is where the problem has been discovered in the first place), but admittedly I have no PCMCIA cards to test along with the socket itself. Fixes: 33e4f80ee69b (ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle) Signed-off-by: Rafael J. Wysocki [linux@dominikbrodowski.net: follow same codepaths for both suspend variants; call ->suspend()] Signed-off-by: Dominik Brodowski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7d5ab9bf4f3404159ba3978c81a823e49b925dd0 Author: Henry Zhang Date: Wed Jan 17 18:41:33 2018 -0800 ARM: dts: bcm283x: Fix pin function of JTAG pins [ Upstream commit 1a012cb2569f2031b3636232c3ab21c20c92d281 ] BCM2835 ARM Peripherals doc shows gpio pins 4, 5, 6, 12 and 13 carry altenate function, ALT5 for ARM JTAG Fixes: 21ff843931b2 ("ARM: dts: bcm283x: Define standard pinctrl groups in the gpio node.") Signed-off-by: Henry Zhang Acked-by: Stefan Wahren Signed-off-by: Eric Anholt Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c10dc67e720b583237c5c80aa409d0894cae2e06 Author: Stefan Wahren Date: Fri Feb 16 11:55:34 2018 +0100 ARM: dts: bcm283x: Fix probing of bcm2835-i2s [ Upstream commit 79c81facdc0b43b1cef37b8d5689a8c8b78f8be0 ] Since 517e7a1537a ("ASoC: bcm2835: move to use the clock framework") the bcm2835-i2s requires a clock as DT property. Unfortunately the necessary DT change has never been applied. While we are at it also fix the first PCM register range to cover the PCM_GRAY register. Fixes: 517e7a1537a ("ASoC: bcm2835: move to use the clock framework") Signed-off-by: Stefan Wahren Reviewed-by: Eric Anholt Tested-by: Matthias Reichl Signed-off-by: Eric Anholt Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 13b520688d2c84e6691203a40f3fcef212845494 Author: Ladislav Michl Date: Thu Feb 22 18:21:36 2018 +0100 power: supply: ltc2941-battery-gauge: Fix temperature units [ Upstream commit dde5953f05a89eb63a0d666ffe51d447b2ac3e05 ] Temperature is measured in tenths of degree Celsius. Fixes: 085bc24d1553 ("Add LTC2941/LTC2943 Battery Gauge Driver") Signed-off-by: Ladislav Michl Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 72662ff1cf8500e2b44fd1dba78aa79593012c3e Author: Sergei Shtylyov Date: Sat Feb 24 22:41:45 2018 +0300 sh_eth: fix TSU init on SH7734/R8A7740 [ Upstream commit a94cf2a614f8bc5b2b33c708626ce695bf71e424 ] It appears that the single port Ether controllers having TSU (like SH7734/ R8A7740) need the same kind of treating in sh_eth_tsu_init() as R7S72100 currently has -- they also don't have the TSU registers related e.g. to passing the frames between ports. Add the 'sh_eth_cpu_data::dual_port' flag and use it as a new criterion for taking a "short path" in the TSU init sequence in order to avoid writing to the non-existent registers... Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734") Fixes: 73a0d907301e ("net: sh_eth: add support R8A7740") Signed-off-by: Sergei Shtylyov Tested-by: Geert Uytterhoeven Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 83e698e4684afb087f16b963a870c13e81166802 Author: Jacob Keller Date: Mon Jan 29 15:57:48 2018 -0800 ixgbe: prevent ptp_rx_hang from running when in FILTER_ALL mode [ Upstream commit 6704a3abf4cf4181a1ee64f5db4969347b88ca1d ] On hardware which supports timestamping all packets, the timestamps are recorded in the packet buffer, and the driver no longer uses or reads the registers. This makes the logic for checking and clearing Rx timestamp hangs meaningless. If we run the ixgbe_ptp_rx_hang() function in this case, then the driver will continuously spam the log output with "Clearing Rx timestamp hang". These messages are spurious, and confusing to end users. The original code in commit a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices", 2015-12-03) did have a flag PTP_RX_TIMESTAMP_IN_REGISTER which was intended to be used to avoid the Rx timestamp hang check, however it did not actually check the flag before calling the function. Do so now in order to stop the checks and prevent the spurious log messages. Fixes: a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices", 2015-12-03) Signed-off-by: Jacob Keller Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 504583768092571e828549063d427dc5fcc2e952 Author: Jan Kara Date: Thu Feb 22 10:39:52 2018 +0100 udf: Provide saner default for invalid uid / gid [ Upstream commit 116e5258e4115aca0c64ac0bf40ded3b353ed626 ] Currently when UDF filesystem is recorded without uid / gid (ids are set to -1), we will assign INVALID_[UG]ID to vfs inode unless user uses uid= and gid= mount options. In such case filesystem could not be modified in any way as VFS refuses to modify files with invalid ids (even by root). This is confusing to users and not very useful default since such media mode is generally used for removable media. Use overflow[ug]id instead so that at least root can modify the filesystem. Reported-by: Steve Kenton Reviewed-by: Pali Rohár Signed-off-by: Jan Kara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cb808972d770288c9072a9144d032ae7d3585720 Author: Thomas Vincent-Cross Date: Tue Feb 27 20:20:36 2018 +1100 PCI: Add function 1 DMA alias quirk for Marvell 88SE9220 [ Upstream commit 832e4e1f76b8a84991e9db56fdcef1ebce839b8b ] Add Marvell 88SE9220 DMA quirk as found and tested on bug 42679. Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679 Signed-off-by: Thomas Vincent-Cross Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5197a9786fee00333e22866a6a7d3ba14d32024d Author: Madalin Bucur Date: Mon Feb 26 11:24:01 2018 -0600 dpaa_eth: fix SG mapping [ Upstream commit 120d75ecf043044554abbba8507f6d22e4715beb ] An issue in the code mapping the skb fragments into scatter-gather frames was evidentiated by netperf TCP_SENDFILE tests. The size was set wrong for all fragments but the first, affecting the transmission of any skb with more than one fragment. Signed-off-by: Madalin Bucur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 602234ea4466443e3b7e6272a806973e7617897c Author: Viresh Kumar Date: Thu Feb 22 11:29:43 2018 +0530 cpufreq: Reorder cpufreq_online() error code path [ Upstream commit b24b6478e65f140610ab1ffaadc7bc6bf0be8aad ] Ideally the de-allocation of resources should happen in the exact opposite order in which they were allocated. It helps maintain the code in long term, even if nothing really breaks with incorrect ordering. That wasn't followed in cpufreq_online() and it has some inconsistencies. For example, the symlinks were created from within the locked region while they are removed only after putting the locks. Also ->exit() should have been called only after the symlinks are removed and the lock is dropped, as that was the case when ->init() was first called. Signed-off-by: Viresh Kumar [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8a6be540377410b5f17f53612674112bc93d80b0 Author: Niklas Cassel Date: Mon Feb 26 22:47:06 2018 +0100 net: stmmac: ensure that the MSS desc is the last desc to set the own bit [ Upstream commit 15d2ee42a3087089e73ad52fd8c1b37ab496b87c ] A dma_wmb() is used to guarantee the ordering, with respect to other writes, to cache coherent DMA memory. There is a dma_wmb() in prepare_tx_desc()/prepare_tso_tx_desc() which ensures that TDES0/1/2 is written before TDES3 (which contains the own bit), for First Desc. However, in the rare case that MSS changes, there will be a MSS context descriptor in front of the regular DMA descriptors: <- DMA Next Descriptor Thus, for this special case, we need a dma_wmb() after prepare_tso_tx_desc()/before writing the own bit to the MSS desc, so that we flush the write to TDES3 for First Desc, in order to ensure that the MSS descriptor is the last descriptor to set the own bit. Signed-off-by: Niklas Cassel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a3d4c34cdea992e137bed4cf66c03e2db6a324ec Author: Niklas Cassel Date: Mon Feb 26 22:47:08 2018 +0100 net: stmmac: ensure that the device has released ownership before reading data [ Upstream commit a6b25da5e7ba212af5826a662e6a035a79bffabd ] According to Documentation/memory-barriers.txt, we need to use a dma_rmb() after reading the status/own bit, to ensure that all descriptor fields are read after reading the own bit. This way, we ensure that the DMA engine is done with the DMA descriptor before we read the other descriptor fields, e.g. reading the tx hardware timestamp (if PTP is enabled). Signed-off-by: Niklas Cassel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 957094fcc06f2a3f519c13ae8644c0ee9527139f Author: Monk Liu Date: Tue Jan 23 18:26:20 2018 +0800 drm/amdgpu: adjust timeout for ib_ring_tests(v2) [ Upstream commit dbf797655a43c6318ebb90b899e6583fcadc6472 ] issue: sometime GFX/MM ib test hit timeout under SRIOV env, root cause is that engine doesn't come back soon enough so the current IB test considered as timed out. fix: for SRIOV GFX IB test wait time need to be expanded a lot during SRIOV runtimei mode since it couldn't really begin before GFX engine come back. for SRIOV MM IB test it always need more time since MM scheduling is not go together with GFX engine, it is controled by h/w MM scheduler so no matter runtime or exclusive mode MM IB test always need more time. v2: use ring type instead of idx to judge Signed-off-by: Monk Liu Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 230d616f58a90c6d08a0422324096840f96775f8 Author: Monk Liu Date: Mon Jan 29 19:24:32 2018 +0800 drm/amdgpu: disable GFX ring and disable PQ wptr in hw_fini [ Upstream commit 9f0178fb67699992d38601cb923b434f9986dd68 ] otherwise there will be DMAR reading error comes out from CP since GFX is still alive and CPC's WPTR_POLL is still enabled, which would lead to DMAR read error. fix: we can hault CPG after hw_fini, but cannot halt CPC becaues KIQ stil need to be alive to let RLCV invoke, but its WPTR_POLL could be disabled. Signed-off-by: Monk Liu Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit de9054cdc8d015c447c5c70124147a2bd310a1c8 Author: Ravikumar Kattekola Date: Tue Feb 6 18:28:02 2018 +0530 ARM: dts: dra71-evm: Correct evm_sd regulator max voltage [ Upstream commit f4aa1bd5b4fc80f5f4ecd184caad832fd62c25f7 ] Correct vpo_sd_1v8_3v3 regulator max voltage to 3.3V Fixes: 9868bc585ae2 ("ARM: dts: Add support for dra718-evm") Signed-off-by: Ravikumar Kattekola Signed-off-by: Sekhar Nori Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ee6f703020ab473b72298fc63b61060f8c8bd1c2 Author: Laurent Pinchart Date: Sun Feb 11 15:07:44 2018 +0200 drm: omapdrm: dss: Move initialization code from component bind to probe [ Upstream commit 215003b4ae1d47035092fef73b6a22aa82037091 ] There's no reason to delay initialization of most of the driver (such as mapping memory I/O, getting clocks or enabling runtime PM) to the component master bind handler. This additionally fixes a real PM issue caused enabling runtime PM in the bind handler. The bind handler performs the following sequence of PM operations: pm_runtime_enable(dev); pm_runtime_get_sync(dev); ... (access the hardware to read the device revision) ... pm_runtime_put_sync(dev); If a failure occurs at this point, the error path calls pm_runtime_disable() to balance the pm_runtime_enable() call. To understand the problem, it should be noted that the bind handler is called when one of the component registers itself, which happens in the component's probe handler. Furthermore, as the components are children of the DSS, the device core calls pm_runtime_get_sync() on the DSS platform device before calling the component's probe handler. This increases the DSS power usage count but doesn't runtime resume the device, as runtime PM is disabled at that point. The bind handler is thus called with runtime PM disabled, with the device runtime suspended, but with the power usage count larger than 0. The pm_runtime_get_sync() call will thus further increase the power usage count and runtime resume the device. The pm_runtime_put_sync() handler will decrease the power usage count to a non-zero value and will thus not suspend the device. Finally, the pm_runtime_disable() call will disable runtime PM, preventing the pm_runtime_put() call in the device core from runtime suspending the device. The DSS device is thus left powered on. To fix this, move the initialization code from the bind handler to the probe handler. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 909474cd384cb206f33461fbd18089cf170533f8 Author: Srinivas Kandagatla Date: Thu Feb 15 12:25:09 2018 +0000 dmaengine: qcom: bam_dma: get num-channels and num-ees from dt [ Upstream commit 48d163b1aa6e7f650c0b7a4f9c61c387a6def868 ] When Linux is master of BAM, it can directly read registers to know number of supported channels, however when its remotely controlled reading these registers would trigger a crash if the BAM is not yet initialized or powered up on the remote side. This patch allows driver to read num-channels and num-ees from Device Tree for remotely controlled BAM. Signed-off-by: Srinivas Kandagatla Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7efeaf6d5193ce2d45d736a47b431a2f6202ba05 Author: Cornelia Huck Date: Thu Feb 22 15:35:43 2018 +0100 vfio-ccw: fence off transport mode [ Upstream commit 9851bc77e62499957567e7c39a5beba7d6de6296 ] vfio-ccw only supports command mode for channel programs, not transport mode. User space is supposed to already take care of that and pass us command-mode ORBs only, but better make sure and return an error to the caller instead of trying to process tcws as ccws. Reviewed-by: Dong Jia Shi Acked-by: Halil Pasic Signed-off-by: Cornelia Huck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fe2fc07d2a31f1dbdca0f601ca52d9fdb9a6758f Author: Niklas Cassel Date: Thu Feb 22 16:22:46 2018 +0100 pinctrl: artpec6: dt: add missing pin group uart5nocts [ Upstream commit 7e065fb9ccce89fe667fdbd9a177eaec59a359fc ] Add missing pin group uart5nocts (all pins except cts), which has been supported by the artpec6 pinctrl driver since its initial submission. Fixes: 00df0582eab1 ("pinctrl: Add pincontrol driver for ARTPEC-6 SoC") Signed-off-by: Niklas Cassel Reviewed-by: Rob Herring Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 72678f7a2922a719610e076eaf9f97ddc5481d7a Author: Richard Fitzgerald Date: Wed Feb 28 15:53:06 2018 +0000 pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs [ Upstream commit b89405b6102fcc3746f43697b826028caa94c823 ] When dt_to_map_one_config() is called with a pinctrl_dev passed in, it should only be using this if the node being looked up is a hog. The code was always using the passed pinctrl_dev without checking whether the dt node referred to it. A pin controller can have pinctrl-n dependencies on other pin controllers in these cases: - the pin controller hardware is external, for example I2C, so needs other pin controller(s) to be setup to communicate with the hardware device. - it is a child of a composite MFD so its of_node is shared with the parent MFD and other children of that MFD. Any part of that MFD could have dependencies on other pin controllers. Because of this, dt_to_map_one_config() can't assume that if it has a pinctrl_dev passed in then the node it looks up must be a hog. It could be a reference to some other pin controller. Signed-off-by: Richard Fitzgerald Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 39c655c5edfe629fdef92efaecd85a05b958f9a2 Author: lionel.debieve@st.com Date: Thu Feb 15 14:03:08 2018 +0100 hwrng: stm32 - add reset during probe [ Upstream commit 326ed382256475aa4b8b7eae8a2f60689fd25e78 ] Avoid issue when probing the RNG without reset if bad status has been detected previously Signed-off-by: Lionel Debieve Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 259cdaff0e91cc610cde869948bf0b90eebac11f Author: Alexey Khoroshilov Date: Sat Feb 10 13:17:27 2018 +0300 watchdog: asm9260_wdt: fix error handling in asm9260_wdt_probe() [ Upstream commit 3c829f47e33eb0398a9a14e357a05199a7be0277 ] If devm_reset_control_get_exclusive() fails, asm9260_wdt_probe() returns immediately. But clks has been already enabled at that point, so it is required to disable them or to move the code around. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 87337cb5663c31c17edaeff1d6871d335b0d96a5 Author: Govindarajulu Varadarajan Date: Thu Mar 1 11:07:23 2018 -0800 enic: enable rq before updating rq descriptors [ Upstream commit e8588e268509292550634d9a35f2723a207683b2 ] rq should be enabled before posting the buffers to rq desc. If not hw sees stale value and casuses DMAR errors. Signed-off-by: Govindarajulu Varadarajan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b3b26307208e93182df45231ef94483902cca43a Author: Yoshihiro Shimoda Date: Fri Feb 2 19:05:15 2018 +0900 dmaengine: rcar-dmac: Check the done lists in rcar_dmac_chan_get_residue() [ Upstream commit 3e081628d510b2ddbe493371d9c574d9275da17e ] This patch fixes an issue that a race condition happens between a client driver and the rcar-dmac driver: - The rcar_dmac_isr_transfer_end() is called. - The done list appears, and desc.running is the next active list. - rcar_dmac_chan_get_residue() is called by a client driver before rcar_dmac_isr_channel_thread() is called. - The rcar_dmac_chan_get_residue() will not find any descriptors. - And, the following WARNING happens: WARN(1, "No descriptor for cookie!"); The sh-sci driver with HSCIF (921,600bps) on R-Car H3 can cause this situation. So, this patch checks the done lists in rcar_dmac_chan_get_residue() and returns zero if the done lists has the argument cookie. Tested-by: Nguyen Viet Dung Signed-off-by: Yoshihiro Shimoda Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e41de468a6f4f25895242ada6d95240a3ce968d8 Author: Qi Hou Date: Tue Mar 6 09:13:37 2018 +0800 dmaengine: pl330: fix a race condition in case of threaded irqs [ Upstream commit a3ca831249ca8c4c226e4ceafee04e280152e59d ] When booting up with "threadirqs" in command line, all irq handlers of the DMA controller pl330 will be threaded forcedly. These threads will race for the same list, pl330->req_done. Before the callback, the spinlock was released. And after it, the spinlock was taken. This opened an race window where another threaded irq handler could steal the spinlock and be permitted to delete entries of the list, pl330->req_done. If the later deleted an entry that was still referred to by the former, there would be a kernel panic when the former was scheduled and tried to get the next sibling of the deleted entry. The scenario could be depicted as below: Thread: T1 pl330->req_done Thread: T2 | | | | -A-B-C-D- | Locked | | | | Waiting Del A | | | -B-C-D- | Unlocked | | | | Locked Waiting | | | | Del B | | | | -C-D- Unlocked Waiting | | | Locked | get C via B \ - Kernel panic The kernel panic looked like as below: Unable to handle kernel paging request at virtual address dead000000000108 pgd = ffffff8008c9e000 [dead000000000108] *pgd=000000027fffe003, *pud=000000027fffe003, *pmd=0000000000000000 Internal error: Oops: 96000044 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 85 Comm: irq/59-66330000 Not tainted 4.8.24-WR9.0.0.12_standard #2 Hardware name: Broadcom NS2 SVK (DT) task: ffffffc1f5cc3c00 task.stack: ffffffc1f5ce0000 PC is at pl330_irq_handler+0x27c/0x390 LR is at pl330_irq_handler+0x2a8/0x390 pc : [] lr : [] pstate: 800001c5 sp : ffffffc1f5ce3d00 x29: ffffffc1f5ce3d00 x28: 0000000000000140 x27: ffffffc1f5c530b0 x26: dead000000000100 x25: dead000000000200 x24: 0000000000418958 x23: 0000000000000001 x22: ffffffc1f5ccd668 x21: ffffffc1f5ccd590 x20: ffffffc1f5ccd418 x19: dead000000000060 x18: 0000000000000001 x17: 0000000000000007 x16: 0000000000000001 x15: ffffffffffffffff x14: ffffffffffffffff x13: ffffffffffffffff x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000840 x9 : ffffffc1f5ce0000 x8 : ffffffc1f5cc3338 x7 : ffffff8008ce2020 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : dead000000000200 x2 : dead000000000100 x1 : 0000000000000140 x0 : ffffffc1f5ccd590 Process irq/59-66330000 (pid: 85, stack limit = 0xffffffc1f5ce0020) Stack: (0xffffffc1f5ce3d00 to 0xffffffc1f5ce4000) 3d00: ffffffc1f5ce3d80 ffffff80080f09d0 ffffffc1f5ca0c00 ffffffc1f6f7c600 3d20: ffffffc1f5ce0000 ffffffc1f6f7c600 ffffffc1f5ca0c00 ffffff80080f0998 3d40: ffffffc1f5ce0000 ffffff80080f0000 0000000000000000 0000000000000000 3d60: ffffff8008ce202c ffffff8008ce2020 ffffffc1f5ccd668 ffffffc1f5c530b0 3d80: ffffffc1f5ce3db0 ffffff80080f0d70 ffffffc1f5ca0c40 0000000000000001 3da0: ffffffc1f5ce0000 ffffff80080f0cfc ffffffc1f5ce3e20 ffffff80080bf4f8 3dc0: ffffffc1f5ca0c80 ffffff8008bf3798 ffffff8008955528 ffffffc1f5ca0c00 3de0: ffffff80080f0c30 0000000000000000 0000000000000000 0000000000000000 3e00: 0000000000000000 0000000000000000 0000000000000000 ffffff80080f0b68 3e20: 0000000000000000 ffffff8008083690 ffffff80080bf420 ffffffc1f5ca0c80 3e40: 0000000000000000 0000000000000000 0000000000000000 ffffff80080cb648 3e60: ffffff8008b1c780 0000000000000000 0000000000000000 ffffffc1f5ca0c00 3e80: ffffffc100000000 ffffff8000000000 ffffffc1f5ce3e90 ffffffc1f5ce3e90 3ea0: 0000000000000000 ffffff8000000000 ffffffc1f5ce3eb0 ffffffc1f5ce3eb0 3ec0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3ee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3fa0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3fc0: 0000000000000000 0000000000000005 0000000000000000 0000000000000000 3fe0: 0000000000000000 0000000000000000 0000000275ce3ff0 0000000275ce3ff8 Call trace: Exception stack(0xffffffc1f5ce3b30 to 0xffffffc1f5ce3c60) 3b20: dead000000000060 0000008000000000 3b40: ffffffc1f5ce3d00 ffffff80084cb694 0000000000000008 0000000000000e88 3b60: ffffffc1f5ce3bb0 ffffff80080dac68 ffffffc1f5ce3b90 ffffff8008826fe4 3b80: 00000000000001c0 00000000000001c0 ffffffc1f5ce3bb0 ffffff800848dfcc 3ba0: 0000000000020000 ffffff8008b15ae4 ffffffc1f5ce3c00 ffffff800808f000 3bc0: 0000000000000010 ffffff80088377f0 ffffffc1f5ccd590 0000000000000140 3be0: dead000000000100 dead000000000200 0000000000000001 0000000000000000 3c00: 0000000000000000 ffffff8008ce2020 ffffffc1f5cc3338 ffffffc1f5ce0000 3c20: 0000000000000840 0000000000000001 0000000000000000 ffffffffffffffff 3c40: ffffffffffffffff ffffffffffffffff 0000000000000001 0000000000000007 [] pl330_irq_handler+0x27c/0x390 [] irq_forced_thread_fn+0x38/0x88 [] irq_thread+0x140/0x200 [] kthread+0xd8/0xf0 [] ret_from_fork+0x10/0x40 Code: f2a00838 f9405763 aa1c03e1 aa1503e0 (f9000443) ---[ end trace f50005726d31199c ]--- Kernel panic - not syncing: Fatal exception in interrupt SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 0-1 Kernel Offset: disabled Memory Limit: none ---[ end Kernel panic - not syncing: Fatal exception in interrupt To fix this, re-start with the list-head after dropping the lock then re-takeing it. Reviewed-by: Frank Mori Hess Tested-by: Frank Mori Hess Signed-off-by: Qi Hou Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a64948842d00b72ee19854ff96dfb77e6aad4c34 Author: Ming Lei Date: Tue Mar 6 12:07:13 2018 +0800 block: null_blk: fix 'Invalid parameters' when loading module [ Upstream commit 66231ad3e2886ba99fbf440cea44cab547e5163f ] On ARM64, the default page size has been 64K on some distributions, and we should allow ARM64 people to play null_blk. This patch fixes the issue by extend page bitmap size for supporting other non-4KB PAGE_SIZE. Cc: Bart Van Assche Cc: Shaohua Li Cc: Kyungchan Koh , Cc: weiping zhang Cc: Yi Zhang Reported-by: Yi Zhang Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f0078d2068b275ddd056fb75aeb2c3a788f09a50 Author: Dexuan Cui Date: Sun Mar 4 22:17:14 2018 -0700 tools: hv: fix compiler warnings about major/target_fname [ Upstream commit 1330fc35327f3ecdfa1aa645e7321ced7349b2cd ] This patch fixes the below warnings with new glibc and gcc: hv_vss_daemon.c:100:13: warning: In the GNU C Library, "major" is defined by . For historical compatibility, it is currently defined by as well, but we plan to remove this soon. To use "major", include directly. hv_fcopy_daemon.c:42:2: note: 'snprintf' output between 2 and 1040 bytes into a destination of size 260 Signed-off-by: Dexuan Cui Cc: Stephen Hemminger Cc: K. Y. Srinivasan Signed-off-by: K. Y. Srinivasan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f85634b7b6d0e799767eed355aa48f134d76f5f9 Author: Linus Walleij Date: Mon Mar 5 11:17:02 2018 +0100 drm/bridge: sii902x: Retry status read after DDI I2C [ Upstream commit 2e7a66a8b5ebf1b04a866e5d7c981640f7f62934 ] The following happens when connection a DVI output driven from the SiI9022 using a DVI-to-VGA adapter plug: i2c i2c-0: sendbytes: NAK bailout. i2c i2c-0: sendbytes: NAK bailout. Then no picture. Apparently the I2C engine inside the SiI9022 is not smart enough to try to fall back to DDC I2C. Or the vendor have not integrated the electronics properly. I don't know which one it is. After this, the I2C bus seems stalled and the first attempt to read the status register fails, and the code returns with negative return value, and the display fails to initialized. Instead, retry status readout five times and continue even if this fails. Tested on the ARM Versatile Express with a DVI-to-VGA connector, it now gives picture. Introduce a helper struct device *dev variable to make the code more readable. Cc: Ville Syrjälä Reviewed-by: Liviu Dudau Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20180305101702.13441-1-linus.walleij@linaro.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3b64e1cf6b929e23e7949c55637f241bbad3e48c Author: Vivek Gautam Date: Tue Jan 16 16:26:56 2018 +0530 phy: qcom-qmp: Fix phy pipe clock gating [ Upstream commit f8ba22a39e985c93e278709b1d5f20857a26b49b ] Pipe clock comes out of the phy and is available as long as the phy is turned on. Clock controller fails to gate this clock after the phy is turned off and generates a warning. / # [ 33.048561] gcc_usb3_phy_pipe_clk status stuck at 'on' [ 33.048585] ------------[ cut here ]------------ [ 33.052621] WARNING: CPU: 1 PID: 18 at ../drivers/clk/qcom/clk-branch.c:97 clk_branch_wait+0xf0/0x108 [ 33.057384] Modules linked in: [ 33.066497] CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G W 4.12.0-rc7-00024-gfe926e34c36d-dirty #96 [ 33.069451] Hardware name: Qualcomm Technologies, Inc. DB820c (DT) ... [ 33.278565] [] clk_branch_wait+0xf0/0x108 [ 33.286375] [] clk_branch2_disable+0x28/0x34 [ 33.291761] [] clk_core_disable+0x5c/0x88 [ 33.297660] [] clk_core_disable_lock+0x20/0x34 [ 33.303129] [] clk_disable+0x1c/0x24 [ 33.309384] [] qcom_qmp_phy_poweroff+0x20/0x48 [ 33.314328] [] phy_power_off+0x80/0xdc [ 33.320492] [] dwc3_core_exit+0x94/0xa0 [ 33.325784] [] dwc3_suspend_common+0x50/0x60 [ 33.331080] [] dwc3_runtime_suspend+0x48/0x6c [ 33.336810] [] pm_generic_runtime_suspend+0x28/0x38 [ 33.342627] [] __rpm_callback+0x150/0x254 [ 33.349222] [] rpm_callback+0x24/0x78 [ 33.354604] [] rpm_suspend+0xe0/0x4e4 [ 33.359813] [] pm_runtime_work+0xdc/0xf0 [ 33.365028] [] process_one_work+0x12c/0x28c [ 33.370576] [] worker_thread+0x58/0x3b8 [ 33.376393] [] kthread+0x100/0x12c [ 33.381776] [] ret_from_fork+0x10/0x50 Fix this by disabling it as the first thing in phy_exit(). Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets") Signed-off-by: Vivek Gautam Signed-off-by: Manu Gautam Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10626a0c20272741e11bfc59ccef161248bfb8fc Author: Takashi Iwai Date: Thu Mar 8 08:26:48 2018 +0100 ALSA: vmaster: Propagate slave error [ Upstream commit 2e2c177ca84aff092c3c96714b0f6a12900f3946 ] In slave_update() of vmaster code ignores the error from the slave get() callback and copies the values. It's not only about the missing error code but also that this may potentially lead to a leak of uninitialized variables when the slave get() don't clear them. This patch fixes slave_update() not to copy the potentially uninitialized values when an error is returned from the slave get() callback, and to propagate the error value properly. Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1ebc21c146b9a4b72caf712137f940b566fa90c Author: Shawn Lin Date: Thu Jan 11 10:40:26 2018 +0800 phy: rockchip-emmc: retry calpad busy trimming [ Upstream commit a4781c2a74b249cad814ceea7272997bbd20051e ] It turns out that 5us isn't enough for all cases, so let's retry some more times to wait for caldone. Signed-off-by: Shawn Lin Tested-by: Ziyuan Xu Signed-off-by: Caesar Wang Reviewed-by: Douglas Anderson Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1fadfed839130ee27bc058caff3912547e86a7b5 Author: Ivan Gorinov Date: Wed Mar 7 11:46:53 2018 -0800 x86/devicetree: Fix device IRQ settings in DT [ Upstream commit 0a5169add90e43ab45ab1ba34223b8583fcaf675 ] IRQ parameters for the SoC devices connected directly to I/O APIC lines (without PCI IRQ routing) may be specified in the Device Tree. Called from DT IRQ parser, irq_create_fwspec_mapping() calls irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg. But x86-specific DT IRQ allocation code casts @arg to of_phandle_args structure pointer and crashes trying to read the IRQ parameters. The function was not converted when the mapping descriptor was changed to irq_fwspec in the generic irqdomain code. Fixes: 11e4438ee330 ("irqdomain: Introduce a firmware-specific IRQ specifier structure") Signed-off-by: Ivan Gorinov Signed-off-by: Thomas Gleixner Cc: Mark Rutland Cc: Rob Herring Link: https://lkml.kernel.org/r/a234dee27ea60ce76141872da0d6bdb378b2a9ee.1520450752.git.ivan.gorinov@intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5e54596b33f60c64b404d4603227ba4872ea835e Author: Ivan Gorinov Date: Wed Mar 7 11:46:29 2018 -0800 x86/devicetree: Initialize device tree before using it [ Upstream commit 628df9dc5ad886b0a9b33c75a7b09710eb859ca1 ] Commit 08d53aa58cb1 added CRC32 calculation in early_init_dt_verify() and checking in late initcall of_fdt_raw_init(), making early_init_dt_verify() mandatory. The required call to early_init_dt_verify() was not added to the x86-specific implementation, causing failure to create the sysfs entry in of_fdt_raw_init(). Fixes: 08d53aa58cb1 ("of/fdt: export fdt blob as /sys/firmware/fdt") Signed-off-by: Ivan Gorinov Signed-off-by: Thomas Gleixner Cc: Mark Rutland Cc: Rob Herring Link: https://lkml.kernel.org/r/c8c7e941efc63b5d25ebf9b6350b0f3df38f6098.1520450752.git.ivan.gorinov@intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c78e4a47bc4d817fd5138ee94e07528fd25460ed Author: Andreas Gruenbacher Date: Tue Feb 20 08:03:24 2018 -0700 gfs2: Fix fallocate chunk size [ Upstream commit 174d1232ebc84fcde8f5889d1171c9c7e74a10a7 ] The chunk size of allocations in __gfs2_fallocate is calculated incorrectly. The size can collapse, causing __gfs2_fallocate to allocate one block at a time, which is very inefficient. This needs fixing in two places: In gfs2_quota_lock_check, always set ap->allowed to UINT_MAX to indicate that there is no quota limit. This fixes callers that rely on ap->allowed to be set even when quotas are off. In __gfs2_fallocate, reset max_blks to UINT_MAX in each iteration of the loop to make sure that allocation limits from one resource group won't spill over into another resource group. Signed-off-by: Andreas Gruenbacher Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c1dab7872b32f08a97d4d2ea740153bfc75939a7 Author: Bjorn Andersson Date: Tue Feb 27 16:45:25 2018 -0800 soc: qcom: wcnss_ctrl: Fix increment in NV upload [ Upstream commit 90c29ed7627b6b4aeb603ee197650173c8434512 ] hdr.len includes both the size of the header and the fragment, so using this when stepping through the firmware causes us to skip 16 bytes every chunk of 3072 bytes; causing only the first fragment to actually be valid data. Instead use fragment size steps through the firmware blob. Fixes: ea7a1f275cf0 ("soc: qcom: Introduce WCNSS_CTRL SMD client") Reported-by: Will Newton Signed-off-by: Bjorn Andersson Signed-off-by: Andy Gross Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0a3b66b55a95ab8a9e2d7a5f6a5ebe2abb1f8fba Author: Ilia Lin Date: Tue Jan 23 09:36:18 2018 +0200 arm64: dts: qcom: Fix SPI5 config on MSM8996 [ Upstream commit e723795c702b52cfceb3bb3faa63059eb4658313 ] Set correct clocks and interrupt values. Fixes the incorrect SPI master configuration. This is mandatory to make the SPI5 interface functional. Signed-off-by: Ilia Lin Signed-off-by: Andy Gross Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b9e852513fcaefc7043443857e1558d71235692e Author: Kan Liang Date: Mon Feb 12 14:20:31 2018 -0800 perf/x86/intel: Fix event update for auto-reload [ Upstream commit d31fc13fdcb20e1c317f9a7dd6273c18fbd58308 ] There is a bug when reading event->count with large PEBS enabled. Here is an example: # ./read_count 0x71f0 0x122c0 0x1000000001c54 0x100000001257d 0x200000000bdc5 In fixed period mode, the auto-reload mechanism could be enabled for PEBS events, but the calculation of event->count does not take the auto-reload values into account. Anyone who reads event->count will get the wrong result, e.g x86_pmu_read(). This bug was introduced with the auto-reload mechanism enabled since commit: 851559e35fd5 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible") Introduce intel_pmu_save_and_restart_reload() to calculate the event->count only for auto-reload. Since the counter increments a negative counter value and overflows on the sign switch, giving the interval: [-period, 0] the difference between two consequtive reads is: A) value2 - value1; when no overflows have happened in between, B) (0 - value1) + (value2 - (-period)); when one overflow happened in between, C) (0 - value1) + (n - 1) * (period) + (value2 - (-period)); when @n overflows happened in between. Here A) is the obvious difference, B) is the extension to the discrete interval, where the first term is to the top of the interval and the second term is from the bottom of the next interval and C) the extension to multiple intervals, where the middle term is the whole intervals covered. The equation for all cases is: value2 - value1 + n * period Previously the event->count is updated right before the sample output. But for case A, there is no PEBS record ready. It needs to be specially handled. Remove the auto-reload code from x86_perf_event_set_period() since we'll not longer call that function in this case. Based-on-code-from: Peter Zijlstra (Intel) Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: acme@kernel.org Fixes: 851559e35fd5 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible") Link: http://lkml.kernel.org/r/1518474035-21006-2-git-send-email-kan.liang@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 359769ca6d1676ea0afbb5fed8bf49aab6215da4 Author: Kan Liang Date: Thu Mar 1 12:54:54 2018 -0500 perf/x86/intel: Fix large period handling on Broadwell CPUs [ Upstream commit f605cfca8c39ffa2b98c06d2b9f30ba64f1e54e3 ] Large fixed period values could be truncated on Broadwell, for example: perf record -e cycles -c 10000000000 Here the fixed period is 0x2540BE400, but the period which finally applied is 0x540BE400 - which is wrong. The reason is that x86_pmu::limit_period() uses an u32 parameter, so the high 32 bits of 'period' get truncated. This bug was introduced in: commit 294fe0f52a44 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds") It's safe to use u64 instead of u32: - Although the 'left' is s64, the value of 'left' must be positive when calling limit_period(). - bdw_limit_period() only modifies the lowest 6 bits, it doesn't touch the higher 32 bits. Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: 294fe0f52a44 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds") Link: http://lkml.kernel.org/r/1519926894-3520-1-git-send-email-kan.liang@linux.intel.com [ Rewrote unacceptably bad changelog. ] Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ecaa7bd342adaad40ffcf62335d98abec3ecea0e Author: Mark Rutland Date: Thu Mar 8 08:00:09 2018 +0000 efi/arm*: Only register page tables when they exist [ Upstream commit 6b31a2fa1e8f7bc6c2a474b4a12dad7a145cf83d ] Currently the arm/arm64 runtime code registers the runtime servies pagetables with ptdump regardless of whether runtime services page tables have been created. As efi_mm.pgd is NULL in these cases, attempting to dump the efi page tables results in a NULL pointer dereference in the ptdump code: /sys/kernel/debug# cat efi_page_tables [ 479.522600] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 479.522715] Mem abort info: [ 479.522764] ESR = 0x96000006 [ 479.522850] Exception class = DABT (current EL), IL = 32 bits [ 479.522899] SET = 0, FnV = 0 [ 479.522937] EA = 0, S1PTW = 0 [ 479.528200] Data abort info: [ 479.528230] ISV = 0, ISS = 0x00000006 [ 479.528317] CM = 0, WnR = 0 [ 479.528317] user pgtable: 4k pages, 48-bit VAs, pgd = 0000000064ab0cb0 [ 479.528449] [0000000000000000] *pgd=00000000fbbe4003, *pud=00000000fb66e003, *pmd=0000000000000000 [ 479.528600] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 479.528664] Modules linked in: [ 479.528699] CPU: 0 PID: 2457 Comm: cat Not tainted 4.15.0-rc3-00065-g2ad2ee7ecb5c-dirty #7 [ 479.528799] Hardware name: FVP Base (DT) [ 479.528899] pstate: 00400009 (nzcv daif +PAN -UAO) [ 479.528941] pc : walk_pgd.isra.1+0x20/0x1d0 [ 479.529011] lr : ptdump_walk_pgd+0x30/0x50 [ 479.529105] sp : ffff00000bf4bc20 [ 479.529185] x29: ffff00000bf4bc20 x28: 0000ffff9d22e000 [ 479.529271] x27: 0000000000020000 x26: ffff80007b4c63c0 [ 479.529358] x25: 00000000014000c0 x24: ffff80007c098900 [ 479.529445] x23: ffff00000bf4beb8 x22: 0000000000000000 [ 479.529532] x21: ffff00000bf4bd70 x20: 0000000000000001 [ 479.529618] x19: ffff00000bf4bcb0 x18: 0000000000000000 [ 479.529760] x17: 000000000041a1c8 x16: ffff0000082139d8 [ 479.529800] x15: 0000ffff9d3c6030 x14: 0000ffff9d2527f4 [ 479.529924] x13: 00000000000003f3 x12: 0000000000000038 [ 479.530000] x11: 0000000000000003 x10: 0101010101010101 [ 479.530099] x9 : 0000000017e94050 x8 : 000000000000003f [ 479.530226] x7 : 0000000000000000 x6 : 0000000000000000 [ 479.530313] x5 : 0000000000000001 x4 : 0000000000000000 [ 479.530416] x3 : ffff000009069fd8 x2 : 0000000000000000 [ 479.530500] x1 : 0000000000000000 x0 : 0000000000000000 [ 479.530599] Process cat (pid: 2457, stack limit = 0x000000005d1b0e6f) [ 479.530660] Call trace: [ 479.530746] walk_pgd.isra.1+0x20/0x1d0 [ 479.530833] ptdump_walk_pgd+0x30/0x50 [ 479.530907] ptdump_show+0x10/0x20 [ 479.530920] seq_read+0xc8/0x470 [ 479.531023] full_proxy_read+0x60/0x90 [ 479.531100] __vfs_read+0x18/0x100 [ 479.531180] vfs_read+0x88/0x160 [ 479.531267] SyS_read+0x48/0xb0 [ 479.531299] el0_svc_naked+0x20/0x24 [ 479.531400] Code: 91400420 f90033a0 a90707a2 f9403fa0 (f9400000) [ 479.531499] ---[ end trace bfe8e28d8acb2b67 ]--- Segmentation fault Let's avoid this problem by only registering the tables after their successful creation, which is also less confusing when EFI runtime services are not in use. Reported-by: Will Deacon Signed-off-by: Mark Rutland Signed-off-by: Ard Biesheuvel Acked-by: Will Deacon Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180308080020.22828-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e6e5de32470b8498221640d448ae316560b43a34 Author: Maurizio Lombardi Date: Fri Mar 9 13:59:06 2018 +0100 cdrom: do not call check_disk_change() inside cdrom_open() [ Upstream commit 2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ] when mounting an ISO filesystem sometimes (very rarely) the system hangs because of a race condition between two tasks. PID: 6766 TASK: ffff88007b2a6dd0 CPU: 0 COMMAND: "mount" #0 [ffff880078447ae0] __schedule at ffffffff8168d605 #1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49 #2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995 #3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef #4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod] #5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50 #6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3 #7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs] #8 [ffff880078447da8] mount_bdev at ffffffff81202570 #9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs] #10 [ffff880078447e28] mount_fs at ffffffff81202d09 #11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f #12 [ffff880078447ea8] do_mount at ffffffff81220fee #13 [ffff880078447f28] sys_mount at ffffffff812218d6 #14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49 RIP: 00007fd9ea914e9a RSP: 00007ffd5d9bf648 RFLAGS: 00010246 RAX: 00000000000000a5 RBX: ffffffff81698c49 RCX: 0000000000000010 RDX: 00007fd9ec2bc210 RSI: 00007fd9ec2bc290 RDI: 00007fd9ec2bcf30 RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000010 R10: 00000000c0ed0001 R11: 0000000000000206 R12: 00007fd9ec2bc040 R13: 00007fd9eb6b2380 R14: 00007fd9ec2bc210 R15: 00007fd9ec2bcf30 ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b This task was trying to mount the cdrom. It allocated and configured a super_block struct and owned the write-lock for the super_block->s_umount rwsem. While exclusively owning the s_umount lock, it called sr_block_ioctl and waited to acquire the global sr_mutex lock. PID: 6785 TASK: ffff880078720fb0 CPU: 0 COMMAND: "systemd-udevd" #0 [ffff880078417898] __schedule at ffffffff8168d605 #1 [ffff880078417900] schedule at ffffffff8168dc59 #2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605 #3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838 #4 [ffff8800784179d0] down_read at ffffffff8168cde0 #5 [ffff8800784179e8] get_super at ffffffff81201cc7 #6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de #7 [ffff880078417a40] flush_disk at ffffffff8123a94b #8 [ffff880078417a88] check_disk_change at ffffffff8123ab50 #9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom] #10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod] #11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86 #12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65 #13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b #14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7 #15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf #16 [ffff880078417d00] do_last at ffffffff8120d53d #17 [ffff880078417db0] path_openat at ffffffff8120e6b2 #18 [ffff880078417e48] do_filp_open at ffffffff8121082b #19 [ffff880078417f18] do_sys_open at ffffffff811fdd33 #20 [ffff880078417f70] sys_open at ffffffff811fde4e #21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49 RIP: 00007f29438b0c20 RSP: 00007ffc76624b78 RFLAGS: 00010246 RAX: 0000000000000002 RBX: ffffffff81698c49 RCX: 0000000000000000 RDX: 00007f2944a5fa70 RSI: 00000000000a0800 RDI: 00007f2944a5fa70 RBP: 00007f2944a5f540 R8: 0000000000000000 R9: 0000000000000020 R10: 00007f2943614c40 R11: 0000000000000246 R12: ffffffff811fde4e R13: ffff880078417f78 R14: 000000000000000c R15: 00007f2944a4b010 ORIG_RAX: 0000000000000002 CS: 0033 SS: 002b This task tried to open the cdrom device, the sr_block_open function acquired the global sr_mutex lock. The call to check_disk_change() then saw an event flag indicating a possible media change and tried to flush any cached data for the device. As part of the flush, it tried to acquire the super_block->s_umount lock associated with the cdrom device. This was the same super_block as created and locked by the previous task. The first task acquires the s_umount lock and then the sr_mutex_lock; the second task acquires the sr_mutex_lock and then the s_umount lock. This patch fixes the issue by moving check_disk_change() out of cdrom_open() and let the caller take care of it. Signed-off-by: Maurizio Lombardi Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 017f2ee2067594f30f14a773eb174027535cb729 Author: Kan Liang Date: Tue Feb 20 02:11:50 2018 -0800 perf/x86/intel: Properly save/restore the PMU state in the NMI handler [ Upstream commit 82d71ed0277efc45360828af8c4e4d40e1b45352 ] The PMU is disabled in intel_pmu_handle_irq(), but cpuc->enabled is not updated accordingly. This is fine in current usage because no-one checks it - but fix it for future code: for example, the drain_pebs() will be modified to fix an auto-reload bug. Properly save/restore the old PMU state. Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: acme@kernel.org Cc: kernel test robot Link: http://lkml.kernel.org/r/6f44ee84-56f8-79f1-559b-08e371eaeb78@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8f8ebc0ba07c2412b1752ceb5c7bea2b7a4b6f24 Author: Guenter Roeck Date: Sat Mar 10 17:55:47 2018 -0800 hwmon: (pmbus/adm1275) Accept negative page register values [ Upstream commit ecb29abd4cb0670c616fb563a078f25d777ce530 ] A negative page register value means that no page needs to be selected. This is used by status register read operations and needs to be accepted. The failure to do so so results in missed status and limit registers. Fixes: da8e48ab483e1 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit afcbcb432e84ce9facebc8e238b89b2b8d810e97 Author: Guenter Roeck Date: Sat Mar 10 17:49:47 2018 -0800 hwmon: (pmbus/max8688) Accept negative page register values [ Upstream commit a46f8cd696624ef757be0311eb28f119c36778e8 ] A negative page register value means that no page needs to be selected. This is used by status register evaluations and needs to be accepted. Fixes: da8e48ab483e1 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 127b06ef520d91b6f575d4380f0fa152aee4f0f9 Author: Eric Anholt Date: Fri Mar 9 15:33:32 2018 -0800 drm/panel: simple: Fix the bus format for the Ontat panel [ Upstream commit 5651e5e094591f479adad5830ac1bc45196a39b3 ] This fixes bad color output. When I was first testing the device I had the DPI hardware set to 666 mode, but apparently in the refactor to use the bus_format information from the panel driver, I failed to actually update the panel. Signed-off-by: Eric Anholt Fixes: e8b6f561b2ee ("drm/panel: simple: Add the 7" DPI panel from Adafruit") Cc: Thierry Reding Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20180309233332.1769-1-eric@anholt.net Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ede5dd7822c6574a3e9ab0bb0d57691054671b40 Author: Peter Zijlstra Date: Fri Mar 9 12:52:04 2018 +0100 perf/core: Fix perf_output_read_group() [ Upstream commit 9e5b127d6f33468143d90c8a45ca12410e4c3fa7 ] Mark reported his arm64 perf fuzzer runs sometimes splat like: armv8pmu_read_counter+0x1e8/0x2d8 armpmu_event_update+0x8c/0x188 armpmu_read+0xc/0x18 perf_output_read+0x550/0x11e8 perf_event_read_event+0x1d0/0x248 perf_event_exit_task+0x468/0xbb8 do_exit+0x690/0x1310 do_group_exit+0xd0/0x2b0 get_signal+0x2e8/0x17a8 do_signal+0x144/0x4f8 do_notify_resume+0x148/0x1e8 work_pending+0x8/0x14 which asserts that we only call pmu::read() on ACTIVE events. The above callchain does: perf_event_exit_task() perf_event_exit_task_context() task_ctx_sched_out() // INACTIVE perf_event_exit_event() perf_event_set_state(EXIT) // EXIT sync_child_event() perf_event_read_event() perf_output_read() perf_output_read_group() leader->pmu->read() Which results in doing a pmu::read() on an !ACTIVE event. I _think_ this is 'new' since we added attr.inherit_stat, which added the perf_event_read_event() to the exit path, without that perf_event_read_output() would only trigger from samples and for @event to trigger a sample, it's leader _must_ be ACTIVE too. Still, adding this check makes it consistent with the @sub case for the siblings. Reported-and-Tested-by: Mark Rutland Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8ba9b0300c18e3d3863c3173230c297c14c80191 Author: Pierre Bourdon Date: Tue Feb 20 16:03:18 2018 +0100 max17042: propagate of_node to power supply device [ Upstream commit 66ec32fc7cd116dab5c02603ea8ec28ff92da3b5 ] max17042_get_status uses the core power_supply_am_i_supplied. That function relies on DT properties to figure out the power supply topology, and will error out without DT. Fixes max17042 battery status being reported as "unknown". Signed-off-by: Pierre Bourdon Signed-off-by: Andre Heider Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ed6244e8b280d87f71592a81b00be75502df02b7 Author: leilei.lin Date: Tue Mar 6 17:36:37 2018 +0800 perf/core: Fix installing cgroup events on CPU [ Upstream commit 33801b94741d6c3be9713c10aa627477216c21e2 ] There's two problems when installing cgroup events on CPUs: firstly list_update_cgroup_event() only tries to set cpuctx->cgrp for the first event, if that mismatches on @cgrp we'll not try again for later additions. Secondly, when we install a cgroup event into an active context, only issue an event reprogram when the event matches the current cgroup context. This avoids a pointless event reprogramming. Signed-off-by: leilei.lin [ Improved the changelog and comments. ] Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: brendan.d.gregg@gmail.com Cc: eranian@gmail.com Cc: linux-kernel@vger.kernel.org Cc: yang_oliver@hotmail.com Link: http://lkml.kernel.org/r/20180306093637.28247-1-linxiulei@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 82e93a83598be971a1d426263183cea7c853e630 Author: Chao Yu Date: Sat Jan 27 17:29:49 2018 +0800 f2fs: fix to check extent cache in f2fs_drop_extent_tree [ Upstream commit bf617f7a92edc6bb2909db2bfa4576f50b280ee5 ] If noextent_cache mount option is on, we will never initialize extent tree in inode, but still we're going to access it in f2fs_drop_extent_tree, result in kernel panic as below: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: _raw_write_lock+0xc/0x30 Call Trace: ? f2fs_drop_extent_tree+0x41/0x70 [f2fs] f2fs_fallocate+0x5a0/0xdd0 [f2fs] ? common_file_perm+0x47/0xc0 ? apparmor_file_permission+0x1a/0x20 vfs_fallocate+0x15b/0x290 SyS_fallocate+0x44/0x70 do_syscall_64+0x6e/0x160 entry_SYSCALL64_slow_path+0x25/0x25 This patch fixes to check extent cache status before using in f2fs_drop_extent_tree. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc8cf0e7aa37f5e9143a63851489013b15c9ab8c Author: Chao Yu Date: Wed Jan 31 09:30:34 2018 +0800 f2fs: fix to clear CP_TRIMMED_FLAG [ Upstream commit cd36d7a17f9da68be9aa67185ba3ad7969934a19 ] Once CP_TRIMMED_FLAG is set, after a reboot, we will never issue discard before LBA becomes invalid again, fix it by clearing the flag in checkpoint without CP_TRIMMED reason. Fixes: 1f43e2ad7bff ("f2fs: introduce CP_TRIMMED_FLAG to avoid unneeded discard") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 393e472db4c85eb7f1f698569994bc60c1fc61be Author: Chao Yu Date: Sun Feb 25 23:38:21 2018 +0800 f2fs: fix to set KEEP_SIZE bit in f2fs_zero_range [ Upstream commit 17cd07ae95073c298af92c1ba14ac58ce84de33b ] As Jayashree Mohan reported: A simple workload to reproduce this would be : 1. create foo 2. Write (8K - 16K) // foo size = 16K now 3. fsync() 4. falloc zero_range , keep_size (4202496 - 4210688) // foo size must be 16K 5. fdatasync() Crash now On recovery, we see that the file size is 4210688 and not 16K, which violates the semantics of keep_size flag. We have a test case to reproduce this using CrashMonkey on 4.15 kernel. Try this out by simply running : ./c_harness -f /dev/sda -d /dev/cow_ram0 -t f2fs -e 102400 -P -v tests/generic_468_zero.so The root cause is that we miss to set KEEP_SIZE bit correctly in zero_range when zeroing block cross EOF with FALLOC_FL_KEEP_SIZE, let's fix this missing case. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d71b8b0d37da25e7fe4186e1c3d873a946f371a3 Author: Vaibhav Jain Date: Thu Feb 15 21:19:24 2018 +0530 cxl: Check if PSL data-cache is available before issue flush request [ Upstream commit 94322ed8e857e3b2a33cf75118051af9baaa110f ] PSL9D doesn't have a data-cache that needs to be flushed before resetting the card. However when cxl tries to flush data-cache on such a card, it times-out as PSL_Control register never indicates flush operation complete due to missing data-cache. This is usually indicated in the kernel logs with this message: "WARNING: cache flush timed out" To fix this the patch checks PSL_Debug register CDC-Field(BIT:27) which indicates the absence of a data-cache and sets a flag 'no_data_cache' in 'struct cxl_native' to indicate this. When cxl_data_cache_flush() is called it checks the flag and if set bails out early without requesting a data-cache flush operation to the PSL. Signed-off-by: Vaibhav Jain Acked-by: Andrew Donnellan Acked-by: Frederic Barrat Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bf3a501c1dc0bac5cdf231151157f43c2f434ab1 Author: Alistair Popple Date: Fri Mar 2 16:18:45 2018 +1100 powerpc/powernv/npu: Fix deadlock in mmio_invalidate() [ Upstream commit 2b74e2a9b39df40a2b489af2d24079617c61ee0e ] When sending TLB invalidates to the NPU we need to send extra flushes due to a hardware issue. The original implementation would lock the all the ATSD MMIO registers sequentially before unlocking and relocking each of them sequentially to do the extra flush. This introduced a deadlock as it is possible for one thread to hold one ATSD register whilst waiting for another register to be freed while the other thread is holding that register waiting for the one in the first thread to be freed. For example if there are two threads and two ATSD registers: Thread A Thread B ---------------------- Acquire 1 Acquire 2 Release 1 Acquire 1 Wait 1 Wait 2 Both threads will be stuck waiting to acquire a register resulting in an RCU stall warning or soft lockup. This patch solves the deadlock by refactoring the code to ensure registers are not released between flushes and to ensure all registers are either acquired or released together and in order. Fixes: bbd5ff50afff ("powerpc/powernv/npu-dma: Add explicit flush when sending an ATSD") Signed-off-by: Alistair Popple Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dc81e7182747fdc01268295c58d2ba138970ecbb Author: Mathieu Malaterre Date: Sun Feb 25 18:22:29 2018 +0100 powerpc: Add missing prototype for arch_irq_work_raise() [ Upstream commit f5246862f82f1e16bbf84cda4cddf287672b30fe ] In commit 4f8b50bbbe63 ("irq_work, ppc: Fix up arch hooks") a new function arch_irq_work_raise() was added without a prototype in header irq_work.h. Fix the following warning (treated as error in W=1): arch/powerpc/kernel/time.c:523:6: error: no previous prototype for ‘arch_irq_work_raise’ Signed-off-by: Mathieu Malaterre Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 903c66e35fb70aaa48fba43cc6af73c130b7e6ff Author: Christophe JAILLET Date: Mon Mar 12 21:15:08 2018 +0100 drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()' [ Upstream commit e770f6bf18182bc3af6ceec30189b6c323cbc157 ] 'drm_vblank_init()' can fail. So handle this (unlikely) error. Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Christophe JAILLET Acked-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/6cbf3d70ac3904489c7194c895225c4103aebb96.1520885192.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b4d7f0dae8c1b2196dda89eca2ddd90d18e6ae56 Author: Christophe JAILLET Date: Mon Mar 12 21:15:10 2018 +0100 drm/meson: Fix some error handling paths in 'meson_drv_bind_master()' [ Upstream commit 2c18107b9d58972588cd45d89b8f58d0f033c110 ] If one of these functions fail, we whould free 'drm', as alreadry done in the other error handling paths, below and above. Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Christophe JAILLET Acked-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/df47e03d36c2cf7bc37ec3105fc47c16555bd946.1520885192.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6eaf0dd1d9d50251657e76a080447b4aeab97c6a Author: Kamlakant Patel Date: Tue Mar 13 16:32:27 2018 +0530 ipmi_ssif: Fix kernel panic at msg_done_handler [ Upstream commit f002612b9d86613bc6fde0a444e0095225f6053e ] This happens when BMC doesn't return any data and the code is trying to print the value of data[2]. Getting following crash: [ 484.728410] Unable to handle kernel NULL pointer dereference at virtual address 00000002 [ 484.736496] pgd = ffff0000094a2000 [ 484.739885] [00000002] *pgd=00000047fcffe003, *pud=00000047fcffd003, *pmd=0000000000000000 [ 484.748158] Internal error: Oops: 96000005 [#1] SMP [...] [ 485.101451] Call trace: [...] [ 485.188473] [] msg_done_handler+0x668/0x700 [ipmi_ssif] [ 485.195249] [] ipmi_ssif_thread+0x110/0x128 [ipmi_ssif] [ 485.202038] [] kthread+0x108/0x138 [ 485.206994] [] ret_from_fork+0x10/0x30 [ 485.212294] Code: aa1903e1 aa1803e0 b900227f 95fef6a5 (39400aa3) Adding a check to validate the data len before printing data[2] to fix this issue. Signed-off-by: Kamlakant Patel Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b5c7dedc8426e6010ae1b6ec64927eaac508449f Author: Milton Miller Date: Fri Mar 9 15:58:19 2018 -0600 watchdog: aspeed: Fix translation of reset mode to ctrl register [ Upstream commit d2fc8db691bf3197d43b2afb553311a9bf257bff ] Assert RESET_SYSTEM bit for any reset and set MODE field from reset type. The watchdog control register has a RESET_SYSTEM bit that is really closer to activate a reset, and RESET_SYSTEM_MODE field that chooses how much to reset. Before this patch, a node without these optional property would do a SOC reset, but a node with properties requesting a cpu or SOC reset would do nothing and a node requesting a system reset would do a SOC reset. Fixes: b7f0b8ad25f3 ("drivers/watchdog: ASPEED reference dev tree properties for config") Signed-off-by: Milton Miller Signed-off-by: Eddie James Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e2906fc86978af29963c40bbeaa7989c50f91ef9 Author: Brian Norris Date: Fri Mar 9 19:46:06 2018 -0800 watchdog: dw: RMW the control register [ Upstream commit a81abbb412341e9e3b2d42ed7d310cf71fbb84a8 ] RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length of pulse to issue for system reset. We shouldn't clobber this value, because that might make the system reset ineffective. On RK3399, we're seeing that a value of 000b (meaning 2 cycles) yields an unreliable (partial?) reset, and so we only fully reset after the watchdog fires a second time. If we retain the system default (010b, or 8 clock cycles), then the watchdog reset is much more reliable. Read-modify-write retains the system value and improves reset reliability. It seems we were intentionally clobbering the response mode previously, to ensure we performed a system reset (we don't support an interrupt notification), so retain that explicitly. Signed-off-by: Brian Norris Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e2b3fa0ce98ffa5ec168b849713870877ac051ef Author: Rafael J. Wysocki Date: Sat Mar 3 10:53:24 2018 +0100 PCI: Restore config space on runtime resume despite being unbound [ Upstream commit 5775b843a619b3c93f946e2b55a208d9f0f48b59 ] We leave PCI devices not bound to a driver in D0 during runtime suspend. But they may have a parent which is bound and can be transitioned to D3cold at runtime. Once the parent goes to D3cold, the unbound child may go to D3cold as well. When the child goes to D3cold, its internal state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost. One example are recent hybrid graphics laptops which cut power to the discrete GPU when the root port above it goes to ACPI power state D3. Users may provoke this by unbinding the GPU driver and allowing runtime PM on the GPU via sysfs: The PM core will then treat the GPU as "suspended", which in turn allows the root port to runtime suspend, causing the power resources listed in its _PR3 object to be powered off. The GPU's BARs will be uninitialized when a driver later probes it. Another example are hybrid graphics laptops where the GPU itself (rather than the root port) is capable of runtime suspending to D3cold. If the GPU's integrated HDA controller is not bound and the GPU's driver decides to runtime suspend to D3cold, the HDA controller's BARs will be uninitialized when a driver later probes it. Fix by saving and restoring config space over a runtime suspend cycle even if the device is not bound. Acked-by: Bjorn Helgaas Tested-by: Peter Wu # Nvidia Optimus Tested-by: Lukas Wunner # MacBook Pro Signed-off-by: Rafael J. Wysocki [lukas: add commit message, bikeshed code comments for clarity] Signed-off-by: Lukas Wunner Link: https://patchwork.freedesktop.org/patch/msgid/92fb6e6ae2730915eb733c08e2f76c6a313e3860.1520068884.git.lukas@wunner.de Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 12c663e4f8e446afb747e7748c73ddb6be6eee68 Author: Mathias Kresin Date: Thu May 11 08:18:24 2017 +0200 MIPS: ath79: Fix AR724X_PLL_REG_PCIE_CONFIG offset [ Upstream commit 05454c1bde91fb013c0431801001da82947e6b5a ] According to the QCA u-boot source the "PCIE Phase Lock Loop Configuration (PCIE_PLL_CONFIG)" register is for all SoCs except the QCA955X and QCA956X at offset 0x10. Since the PCIE PLL config register is only defined for the AR724x fix only this value. The value is wrong since the day it was added and isn't used by any driver yet. Signed-off-by: Mathias Kresin Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16048/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2a0bc4ad7c6370b84a0a03df37a53ca17a2b47d5 Author: Ursula Braun Date: Wed Mar 14 11:01:00 2018 +0100 net/smc: pay attention to MAX_ORDER for CQ entries [ Upstream commit c9f4c6cf53bfafb639386a4c094929f13f573e04 ] smc allocates a certain number of CQ entries for used RoCE devices. For mlx5 devices the chosen constant number results in a large allocation causing this warning: [13355.124656] WARNING: CPU: 3 PID: 16535 at mm/page_alloc.c:3883 __alloc_pages_nodemask+0x2be/0x10c0 [13355.124657] Modules linked in: smc_diag(O) smc(O) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ip6table_filter ip6_tables iptable_filter mlx5_ib ib_core sunrpc mlx5_core s390_trng rng_core ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common ptp pps_core eadm_sch dm_multipath dm_mod vhost_net tun vhost tap sch_fq_codel kvm ip_tables x_tables autofs4 [last unloaded: smc] [13355.124672] CPU: 3 PID: 16535 Comm: kworker/3:0 Tainted: G O 4.14.0uschi #1 [13355.124673] Hardware name: IBM 3906 M04 704 (LPAR) [13355.124675] Workqueue: events smc_listen_work [smc] [13355.124677] task: 00000000e2f22100 task.stack: 0000000084720000 [13355.124678] Krnl PSW : 0704c00180000000 000000000029da76 (__alloc_pages_nodemask+0x2be/0x10c0) [13355.124681] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 [13355.124682] Krnl GPRS: 0000000000000000 00550e00014080c0 0000000000000000 0000000000000001 [13355.124684] 000000000029d8b6 00000000f3bfd710 0000000000000000 00000000014080c0 [13355.124685] 0000000000000009 00000000ec277a00 0000000000200000 0000000000000000 [13355.124686] 0000000000000000 00000000000001ff 000000000029d8b6 0000000084723720 [13355.124708] Krnl Code: 000000000029da6a: a7110200 tmll %r1,512 000000000029da6e: a774ff29 brc 7,29d8c0 #000000000029da72: a7f40001 brc 15,29da74 >000000000029da76: a7f4ff25 brc 15,29d8c0 000000000029da7a: a7380000 lhi %r3,0 000000000029da7e: a7f4fef1 brc 15,29d860 000000000029da82: 5820f0c4 l %r2,196(%r15) 000000000029da86: a53e0048 llilh %r3,72 [13355.124720] Call Trace: [13355.124722] ([<000000000029d8b6>] __alloc_pages_nodemask+0xfe/0x10c0) [13355.124724] [<000000000013bd1e>] s390_dma_alloc+0x6e/0x148 [13355.124733] [<000003ff802eeba6>] mlx5_dma_zalloc_coherent_node+0x8e/0xe0 [mlx5_core] [13355.124740] [<000003ff802eee18>] mlx5_buf_alloc_node+0x70/0x108 [mlx5_core] [13355.124744] [<000003ff804eb410>] mlx5_ib_create_cq+0x558/0x898 [mlx5_ib] [13355.124749] [<000003ff80407d40>] ib_create_cq+0x48/0x88 [ib_core] [13355.124751] [<000003ff80109fba>] smc_ib_setup_per_ibdev+0x52/0x118 [smc] [13355.124753] [<000003ff8010bcb6>] smc_conn_create+0x65e/0x728 [smc] [13355.124755] [<000003ff801081a2>] smc_listen_work+0x2d2/0x540 [smc] [13355.124756] [<0000000000162c66>] process_one_work+0x1be/0x440 [13355.124758] [<0000000000162f40>] worker_thread+0x58/0x458 [13355.124759] [<0000000000169e7e>] kthread+0x14e/0x168 [13355.124760] [<00000000009ce8be>] kernel_thread_starter+0x6/0xc [13355.124762] [<00000000009ce8b8>] kernel_thread_starter+0x0/0xc [13355.124762] Last Breaking-Event-Address: [13355.124764] [<000000000029da72>] __alloc_pages_nodemask+0x2ba/0x10c0 [13355.124764] ---[ end trace 34be38b581c0b585 ]--- This patch reduces the smc constant for the maximum number of allocated completion queue entries SMC_MAX_CQE by 2 to avoid high round up values in the mlx5 code, and reduces the number of allocated completion queue entries even more, if the final allocation for an mlx5 device hits the MAX_ORDER limit. Reported-by: Ihnken Menssen Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 289e6fa33b0b0d59b6eb45d6fc7e58d15ab01e04 Author: Christophe Jaillet Date: Tue Mar 13 19:36:58 2018 +0100 spi: bcm-qspi: fIX some error handling paths [ Upstream commit bc3cc75281b3c2b1c5355d88d147b66a753bb9a5 ] For some reason, commit c0368e4db4a3 ("spi: bcm-qspi: Fix use after free in bcm_qspi_probe() in error path") has updated some gotos, but not all of them. This looks spurious, so fix it. Fixes: fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver") Signed-off-by: Christophe JAILLET Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1fae5e92788c0b9bc3b632a2de9ed6ef9333af32 Author: Christophe Jaillet Date: Tue Mar 13 21:33:11 2018 +0100 regulator: gpio: Fix some error handling paths in 'gpio_regulator_probe()' [ Upstream commit ed8cffda27dea6fd3dafb3ee881c5a786edac9ca ] Re-order error handling code and gotos to avoid leaks in error handling paths. Fixes: 9f946099fe19 ("regulator: gpio: fix parsing of gpio list") Signed-off-by: Christophe JAILLET Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9fe2e97e6f2da8fb47bf842741cf9d508c9897f8 Author: Leo Yan Date: Tue Mar 13 11:24:30 2018 -0600 coresight: Use %px to print pcsr instead of %p [ Upstream commit 831c326fcd0e8e2a6ece952f898a1ec9b1dc1004 ] Commit ad67b74d2469 ("printk: hash addresses printed with %p") lets printk specifier %p to hash all addresses before printing, this was resulting in the high 32 bits of pcsr can only output zeros. So module cannot completely print pc value and it's pointless for debugging purpose. This patch fixes this by using %px to print pcsr instead. Cc: Mathieu Poirier Signed-off-by: Leo Yan Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 12b29e1cfe6a8965a87234f9995318998f79375d Author: Oded Gabbay Date: Thu Mar 15 10:08:35 2018 +0200 drm/amdkfd: add missing include of mm.h [ Upstream commit 7420f482ea5163bf6dae39a5c7628d5397cd6307 ] This patch fixes kernel build in ARCH=frv Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 739c8e70889a50363c4a74813509925f392df839 Author: Parav Pandit Date: Tue Mar 13 16:06:14 2018 +0200 IB/core: Honor port_num while resolving GID for IB link layer [ Upstream commit 563c4ba3bd2b8b0b21c65669ec2226b1cfa1138b ] ah_attr contains the port number to which cm_id is bound. However, while searching for GID table for matching GID entry, the port number is ignored. This could cause the wrong GID to be used when the ah_attr is converted to an AH. Reviewed-by: Daniel Jurgens Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7166fb17475879647f513ea84e9f96b430beee70 Author: Thomas Richter Date: Thu Mar 8 15:57:35 2018 +0100 perf stat: Fix core dump when flag T is used [ Upstream commit fca32340a5e8b896f57d41fd94b8b1701df25eb1 ] Executing command 'perf stat -T -- ls' dumps core on x86 and s390. Here is the call back chain (done on x86): # gdb ./perf .... (gdb) r stat -T -- ls ... Program received signal SIGSEGV, Segmentation fault. 0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6 #1 0x00007ffff56ae484 in asprintf () from /lib64/libc.so.6 #2 0x00000000004f1982 in __parse_events_add_pmu (parse_state=0x7fffffffd580, list=0xbfb970, name=0xbf3ef0 "cpu", head_config=0xbfb930, auto_merge_stats=false) at util/parse-events.c:1233 #3 0x00000000004f1c8e in parse_events_add_pmu (parse_state=0x7fffffffd580, list=0xbfb970, name=0xbf3ef0 "cpu", head_config=0xbfb930) at util/parse-events.c:1288 #4 0x0000000000537ce3 in parse_events_parse (_parse_state=0x7fffffffd580, scanner=0xbf4210) at util/parse-events.y:234 #5 0x00000000004f2c7a in parse_events__scanner (str=0x6b66c0 "task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}", parse_state=0x7fffffffd580, start_token=258) at util/parse-events.c:1673 #6 0x00000000004f2e23 in parse_events (evlist=0xbe9990, str=0x6b66c0 "task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}", err=0x0) at util/parse-events.c:1713 #7 0x000000000044e137 in add_default_attributes () at builtin-stat.c:2281 #8 0x000000000044f7b5 in cmd_stat (argc=1, argv=0x7fffffffe3b0) at builtin-stat.c:2828 #9 0x00000000004c8b0f in run_builtin (p=0xab01a0 , argc=4, argv=0x7fffffffe3b0) at perf.c:297 #10 0x00000000004c8d7c in handle_internal_command (argc=4, argv=0x7fffffffe3b0) at perf.c:349 #11 0x00000000004c8ece in run_argv (argcp=0x7fffffffe20c, argv=0x7fffffffe200) at perf.c:393 #12 0x00000000004c929c in main (argc=4, argv=0x7fffffffe3b0) at perf.c:537 (gdb) It turns out that a NULL pointer is referenced. Here are the function calls: ... cmd_stat() +---> add_default_attributes() +---> parse_events(evsel_list, transaction_attrs, NULL); 3rd parameter set to NULL Function parse_events(xx, xx, struct parse_events_error *err) dives into a bison generated scanner and creates parser state information for it first: struct parse_events_state parse_state = { .list = LIST_HEAD_INIT(parse_state.list), .idx = evlist->nr_entries, .error = err, <--- NULL POINTER !!! .evlist = evlist, }; Now various functions inside the bison scanner are called to end up in __parse_events_add_pmu(struct parse_events_state *parse_state, ..) with first parameter being a pointer to above structure definition. Now the PMU event name is not found (because being executed in a VM) and this function tries to create an error message with asprintf(&parse_state->error.str, ....) which references a NULL pointer and dumps core. Fix this by providing a pointer to the necessary error information instead of NULL. Technically only the else part is needed to avoid the core dump, just lets be safe... Signed-off-by: Thomas Richter Cc: Heiko Carstens Cc: Hendrik Brueckner Cc: Martin Schwidefsky Link: http://lkml.kernel.org/r/20180308145735.64717-1-tmricht@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8cde08971b4165b5831fc555edf98464f1d10662 Author: Yisheng Xie Date: Mon Mar 12 19:25:56 2018 +0800 perf top: Fix top.call-graph config option reading [ Upstream commit a3a4a3b37c9b911af4c375b2475cea0fd2b84d38 ] When trying to add the "call-graph" variable for top into the .perfconfig file, like: [top] call-graph = fp I that perf_top_config() do not parse this variable. Fix it by calling perf_default_config() when the top.call-graph variable is set. Signed-off-by: Yisheng Xie Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan Fixes: b8cbb349061e ("perf config: Bring perf_default_config to the very beginning at main()") Link: http://lkml.kernel.org/r/1520853957-36106-1-git-send-email-xieyisheng1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 25b69a422b592edd2739fab9150f5d29955043f7 Author: Vitaly Kuznetsov Date: Fri Feb 9 14:01:33 2018 +0100 KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use [ Upstream commit 0bcc3fb95b97ac2ca223a5a870287b37f56265ac ] Devices which use level-triggered interrupts under Windows 2016 with Hyper-V role enabled don't work: Windows disables EOI broadcast in SPIV unconditionally. Our in-kernel IOAPIC implementation emulates an old IOAPIC version which has no EOI register so EOI never happens. The issue was discovered and discussed a while ago: https://www.spinics.net/lists/kvm/msg148098.html While this is a guest OS bug (it should check that IOAPIC has the required capabilities before disabling EOI broadcast) we can workaround it in KVM: advertising DIRECTED_EOI with in-kernel IOAPIC makes little sense anyway. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 982f8f14e704ad07e4093e208723157312620b27 Author: Gregory CLEMENT Date: Wed Mar 14 18:03:40 2018 +0100 i2c: mv64xxx: Apply errata delay only in standard mode [ Upstream commit 31184d8c6ea49ea0676d100cdd7e1f102ad025b5 ] The errata FE-8471889 description has been updated. There is still a timing violation for repeated start. But the errata now states that it was only the case for the Standard mode (100 kHz), in Fast mode (400 kHz) there is no issue. This patch limit the errata fix to the Standard mode. It has been tesed successfully on the clearfog (Aramda 388 based board). Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d1b1e7902af7344b5bd99234931df3e1fb1cbe9 Author: Arjun Vynipadath Date: Thu Mar 15 17:34:14 2018 +0530 cxgb4: Fix queue free path of ULD drivers [ Upstream commit d7cb44496a9bb458632cb3c18acb08949c210448 ] Setting sge_uld_rxq_info to NULL in free_queues_uld(). We are referencing sge_uld_rxq_info in cxgb_up(). This will fix a panic when interface is brought up after a ULDq creation failure. Fixes: 94cdb8bb993a (cxgb4: Add support for dynamic allocation of resources for ULD) Signed-off-by: Arjun Vynipadath Signed-off-by: Casey Leedom Signed-off-by: Ganesh Goudhar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1d1646c408f62148fd2bbc399927bdc5381cb3ba Author: Seunghun Han Date: Wed Mar 14 16:12:56 2018 -0700 ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c [ Upstream commit 97f3c0a4b0579b646b6b10ae5a3d59f0441cc12c ] I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.464168] ACPI: Added _OSI(Module Device) >[ 0.467022] ACPI: Added _OSI(Processor Device) >[ 0.469376] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.471647] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.477997] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174) >[ 0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461) >[ 0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node ffff88021710a618), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.497683] ACPI: Interpreter enabled >[ 0.499385] ACPI: (supports S0) >[ 0.501151] ACPI: Using IOAPIC for interrupt routing >[ 0.503342] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174) >[ 0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461) >[ 0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node ffff88021710ab18), AE_AML_INTERNAL (20170303/psparse-543) >[ 0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC (20170303/bus-991) >[ 0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.526795] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.529668] Call Trace: >[ 0.530811] ? dump_stack+0x5c/0x81 >[ 0.532240] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.533905] ? acpi_os_delete_cache+0xa/0x10 >[ 0.535497] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.537237] ? acpi_terminate+0xa/0x14 >[ 0.538701] ? acpi_init+0x2af/0x34f >[ 0.540008] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.541593] ? do_one_initcall+0x4e/0x1a0 >[ 0.543008] ? kernel_init_freeable+0x19e/0x21f >[ 0.546202] ? rest_init+0x80/0x80 >[ 0.547513] ? kernel_init+0xa/0x100 >[ 0.548817] ? ret_from_fork+0x25/0x30 >[ 0.550587] vgaarb: loaded >[ 0.551716] EDAC MC: Ver: 3.0.0 >[ 0.553744] PCI: Probing PCI hardware >[ 0.555038] PCI host bridge to bus 0000:00 > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ns_evaluate() function only removes Info->return_object in AE_CTRL_RETURN_VALUE case. But, when errors occur, the status value is not AE_CTRL_RETURN_VALUE, and Info->return_object is also not null. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Signed-off-by: Seunghun Han Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c827ed01821da3357ce2781c386c1d8471349fdd Author: Bob Moore Date: Wed Mar 14 16:13:01 2018 -0700 ACPICA: Fix memory leak on unusual memory leak [ Upstream commit 1c29c372b2d1d2415601041532745ce859f24126 ] Fixes a single-object memory leak on a store-to-reference method invocation. ACPICA BZ 1439. Signed-off-by: Bob Moore Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bf9b263b3e75184bfde4b5e578f2a83132f3e2b9 Author: Erik Schmauss Date: Wed Mar 14 16:13:08 2018 -0700 ACPICA: Events: add a return on failure from acpi_hw_register_read [ Upstream commit b4c0de312613ca676db5bd7e696a44b56795612a ] This ensures that acpi_ev_fixed_event_detect() does not use fixed_status and and fixed_enable as uninitialized variables. Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 601ae35b3f19ea673a1ed6d416f25c2e084886cf Author: Icenowy Zheng Date: Fri Mar 16 22:02:12 2018 +0800 dt-bindings: add device tree binding for Allwinner H6 main CCU [ Upstream commit 2e08e4d2ff488424919d69dd211ac860a019ac1d ] The Allwinner H6 main CCU uses the internal oscillator of the SoC, which is different with old SoCs' main CCU. Add device tree binding for the Allwinner H6 main CCU. Signed-off-by: Icenowy Zheng Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 35a4f782b521c583cab615fba04bde9b4d4ed205 Author: Christophe JAILLET Date: Wed Mar 14 20:56:37 2018 +0100 remoteproc: imx_rproc: Fix an error handling path in 'imx_rproc_probe()' [ Upstream commit de6f83f85be94e0b7d0d324c29ccc9d78a6bb4e7 ] If 'of_device_get_match_data()' fails, we must undo the previous 'rproc_alloc()' call. Fixes: a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver") Signed-off-by: Christophe JAILLET Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a092479bb4f302d5e51a21d0d18e74aa6ea5837 Author: Coly Li Date: Sun Mar 18 17:36:15 2018 -0700 bcache: quit dc->writeback_thread when BCACHE_DEV_DETACHING is set [ Upstream commit fadd94e05c02afec7b70b0b14915624f1782f578 ] In patch "bcache: fix cached_dev->count usage for bch_cache_set_error()", cached_dev_get() is called when creating dc->writeback_thread, and cached_dev_put() is called when exiting dc->writeback_thread. This modification works well unless people detach the bcache device manually by 'echo 1 > /sys/block/bcache/bcache/detach' Because this sysfs interface only calls bch_cached_dev_detach() which wakes up dc->writeback_thread but does not stop it. The reason is, before patch "bcache: fix cached_dev->count usage for bch_cache_set_error()", inside bch_writeback_thread(), if cache is not dirty after writeback, cached_dev_put() will be called here. And in cached_dev_make_request() when a new write request makes cache from clean to dirty, cached_dev_get() will be called there. Since we don't operate dc->count in these locations, refcount d->count cannot be dropped after cache becomes clean, and cached_dev_detach_finish() won't be called to detach bcache device. This patch fixes the issue by checking whether BCACHE_DEV_DETACHING is set inside bch_writeback_thread(). If this bit is set and cache is clean (no existing writeback_keys), break the while-loop, call cached_dev_put() and quit the writeback thread. Please note if cache is still dirty, even BCACHE_DEV_DETACHING is set the writeback thread should continue to perform writeback, this is the original design of manually detach. It is safe to do the following check without locking, let me explain why, + if (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) && + (!atomic_read(&dc->has_dirty) || !dc->writeback_running)) { If the kenrel thread does not sleep and continue to run due to conditions are not updated in time on the running CPU core, it just consumes more CPU cycles and has no hurt. This should-sleep-but-run is safe here. We just focus on the should-run-but-sleep condition, which means the writeback thread goes to sleep in mistake while it should continue to run. 1, First of all, no matter the writeback thread is hung or not, kthread_stop() from cached_dev_detach_finish() will wake up it and terminate by making kthread_should_stop() return true. And in normal run time, bit on index BCACHE_DEV_DETACHING is always cleared, the condition !test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) is always true and can be ignored as constant value. 2, If one of the following conditions is true, the writeback thread should go to sleep, "!atomic_read(&dc->has_dirty)" or "!dc->writeback_running)" each of them independently controls the writeback thread should sleep or not, let's analyse them one by one. 2.1 condition "!atomic_read(&dc->has_dirty)" If dc->has_dirty is set from 0 to 1 on another CPU core, bcache will call bch_writeback_queue() immediately or call bch_writeback_add() which indirectly calls bch_writeback_queue() too. In bch_writeback_queue(), wake_up_process(dc->writeback_thread) is called. It sets writeback thread's task state to TASK_RUNNING and following an implicit memory barrier, then tries to wake up the writeback thread. In writeback thread, its task state is set to TASK_INTERRUPTIBLE before doing the condition check. If other CPU core sets the TASK_RUNNING state after writeback thread setting TASK_INTERRUPTIBLE, the writeback thread will be scheduled to run very soon because its state is not TASK_INTERRUPTIBLE. If other CPU core sets the TASK_RUNNING state before writeback thread setting TASK_INTERRUPTIBLE, the implict memory barrier of wake_up_process() will make sure modification of dc->has_dirty on other CPU core is updated and observed on the CPU core of writeback thread. Therefore the condition check will correctly be false, and continue writeback code without sleeping. 2.2 condition "!dc->writeback_running)" dc->writeback_running can be changed via sysfs file, every time it is modified, a following bch_writeback_queue() is alwasy called. So the change is always observed on the CPU core of writeback thread. If dc->writeback_running is changed from 0 to 1 on other CPU core, this condition check will observe the modification and allow writeback thread to continue to run without sleeping. Now we can see, even without a locking protection, multiple conditions check is safe here, no deadlock or process hang up will happen. I compose a separte patch because that patch "bcache: fix cached_dev->count usage for bch_cache_set_error()" already gets a "Reviewed-by:" from Hannes Reinecke. Also this fix is not trivial and good for a separate patch. Signed-off-by: Coly Li Reviewed-by: Michael Lyle Cc: Hannes Reinecke Cc: Huijun Tang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 590e13a68177074c66261c7e39efb99639be4344 Author: Michael Schmitz Date: Sat Mar 3 12:04:13 2018 +1300 zorro: Set up z->dev.dma_mask for the DMA API [ Upstream commit 55496d3fe2acd1a365c43cbd613a20ecd4d74395 ] The generic DMA API uses dev->dma_mask to check the DMA addressable memory bitmask, and warns if no mask is set or even allocated. Set z->dev.dma_coherent_mask on Zorro bus scan, and make z->dev.dma_mask to point to z->dev.dma_coherent_mask so device drivers that need DMA have everything set up to avoid warnings from dma_alloc_coherent(). Drivers can still use dma_set_mask_and_coherent() to explicitly set their DMA bit mask. Signed-off-by: Michael Schmitz [geert: Handle Zorro II with 24-bit address space] Acked-by: Christoph Hellwig Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5e8f4ec7899b2c5cfe778ef9cbdd0b23fff4f612 Author: Honggang Li Date: Fri Mar 16 10:37:13 2018 +0800 IB/mlx5: Set the default active rate and width to QDR and 4X [ Upstream commit 7672ed33c4c15dbe9d56880683baaba4227cf940 ] Before commit f1b65df5a232 ("IB/mlx5: Add support for active_width and active_speed in RoCE"), the mlx5_ib driver set the default active_width and active_speed to IB_WIDTH_4X and IB_SPEED_QDR. When the RoCE port is down, the RoCE port does not negotiate the active width with the remote side, causing the active width to be zero. When running userspace ibstat to view the port status, ibstat will panic as it reads an invalid width from sys file. This patch restores the original behavior. Fixes: f1b65df5a232 ("IB/mlx5: Add support for active_width and active_speed in RoCE"). Signed-off-by: Honggang Li Reviewed-by: Hal Rosenstock Reviewed-by: Noa Osherovich Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a8b1c46af586914b42773b4181052cc3c7cb0d3 Author: Chunyu Hu Date: Mon Mar 5 13:40:38 2018 +0800 cpufreq: cppc_cpufreq: Fix cppc_cpufreq_init() failure path [ Upstream commit 55b55abc17f238c61921360e61dde90dd9a326d1 ] Kmemleak reported the below leak. When cppc_cpufreq_init went into failure path, the cpu mask is not freed. After fix, this report is gone. And to avaoid potential NULL pointer reference, check the cpu value first. unreferenced object 0xffff800fd5ea4880 (size 128): comm "swapper/0", pid 1, jiffies 4294939510 (age 668.680s) hex dump (first 32 bytes): 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 .... ........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __kmalloc_node+0x278/0x634 [] alloc_cpumask_var_node+0x28/0x60 [] zalloc_cpumask_var+0x14/0x1c [] cppc_cpufreq_init+0xd0/0x19c [] do_one_initcall+0xec/0x15c [] kernel_init_freeable+0x1f4/0x2a4 [] kernel_init+0x18/0x10c [] ret_from_fork+0x10/0x18 [] 0xffffffffffffffff Signed-off-by: Chunyu Hu Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f69b52965de0b8e39dc93e4f7ab6e8a38bd7d17a Author: Yong Wu Date: Sun Mar 18 09:52:54 2018 +0800 iommu/mediatek: Fix protect memory setting [ Upstream commit 70ca608b2ec6dafa6bb1c2b0691852fc78f8f717 ] In MediaTek's IOMMU design, When a iommu translation fault occurs (HW can NOT translate the destination address to a valid physical address), the IOMMU HW output the dirty data into a special memory to avoid corrupting the main memory, this is called "protect memory". the register(0x114) for protect memory is a little different between mt8173 and mt2712. In the mt8173, bit[30:6] in the register represents [31:7] of the physical address. In the 4GB mode, the register bit[31] should be 1. While in the mt2712, the bits don't shift. bit[31:7] in the register represents [31:7] in the physical address, and bit[1:0] in the register represents bit[33:32] of the physical address if it has. Fixes: e6dec9230862 ("iommu/mediatek: Add mt2712 IOMMU support") Reported-by: Honghui Zhang Signed-off-by: Yong Wu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8c8f0b1f597d039e90f08510975b9e8d53e0ed99 Author: Thomas Hellstrom Date: Thu Mar 22 10:35:18 2018 +0100 drm/vmwgfx: Unpin the screen object backup buffer when not used [ Upstream commit 20fb5a635a0c8478ac98f15cfafc2ea83df29565 ] We were relying on the pinned screen object backup buffer to be destroyed when not used. But if we hold a copy of the atomic state, like when hibernating, the backup buffer might not be destroyed since it's refcounted by the atomic state. This causes us to hibernate with a buffer pinned in VRAM. Fix this by only having the buffer pinned when it is actually used by a screen object. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul Reviewed-by: Sinclair Yeh Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 791a1ef7df367bdb78f9e09421b320a2411d284d Author: Eric Sandeen Date: Thu Mar 22 11:59:00 2018 -0400 ext4: don't complain about incorrect features when probing [ Upstream commit 0d9366d67bcf066b028e57d09c9a86ce879bcc28 ] If mount is auto-probing for filesystem type, it will try various filesystems in order, with the MS_SILENT flag set. We get that flag as the silent arg to ext4_fill_super. If we're probing (silent==1) then don't complain about feature incompatibilities that are found if it looks like it's actually a different valid extN type - failed probes should be silent in this case. If the on-disk features are unknown even to ext4, then complain. Reported-by: Joakim Tjernlund Tested-by: Joakim Tjernlund Signed-off-by: Eric Sandeen Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1891e0bb60b4285624db5fe05b2af6d8c9079ec0 Author: Philipp Puschmann Date: Fri Mar 23 10:22:15 2018 +0100 arm: dts: socfpga: fix GIC PPI warning [ Upstream commit 6d97d5aba08b26108f95dc9fb7bbe4d9436c769c ] Fixes the warning "GIC: PPI13 is secure or misconfigured" by changing the interrupt type from level_low to edge_raising Signed-off-by: Philipp Puschmann Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b5fb65c559ec042ace497323395535efca3db337 Author: Jay Vosburgh Date: Thu Mar 22 14:42:41 2018 +0000 virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS [ Upstream commit bda7fab54828bbef2164bb23c0f6b1a7d05cc718 ] The operstate update logic will leave an interface in the default UNKNOWN operstate if the interface carrier state never changes from the default carrier up state set at creation. This includes the case of an explicit call to netif_carrier_on, as the carrier on to on transition has no effect on operstate. This affects virtio-net for the case that the virtio peer does not support VIRTIO_NET_F_STATUS (the feature that provides carrier state updates). Without this feature, the virtio specification states that "the link should be assumed active," so, logically, the operstate should be UP instead of UNKNOWN. This has impact on user space applications that use the operstate to make availability decisions for the interface. Resolve this by changing the virtio probe logic slightly to call netif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS cases, and then the existing call to netif_carrier_on for the "without" case will cause an operstate transition. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Ben Hutchings Signed-off-by: Jay Vosburgh Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a54e06d490a1fa42abbdfa83e3e8881e45dd798e Author: Milton Miller Date: Thu Mar 15 11:02:06 2018 -0500 watchdog: aspeed: Allow configuring for alternate boot [ Upstream commit 6ffa3402211acc30e47e691e14d62f3fd065a54e ] Allow the device tree to specify a watchdog to fallover to the alternate boot source. The aspeeed watchdog can set a latch directing flash chip select 0 to chip select 1, allowing boot from an alternate media if the watchdog is not reset in time. On the ast2400 bank 1 also goes to flash bank 1, while on the ast2500 the chip selects are swapped. Also clear the secondary boot bit during the machine restart operation. Otherwise, the system will switch to the alternate boot after every reboot, which is not desired. Signed-off-by: Milton Miller Signed-off-by: Eddie James Reviewed-by: Joel Stanley Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd2399b49de48637772e22aa4b30ee019a5f0076 Author: Petr Vorel Date: Fri Mar 23 14:41:08 2018 +0100 ima: Fallback to the builtin hash algorithm [ Upstream commit ab60368ab6a452466885ef4edf0cefd089465132 ] IMA requires having it's hash algorithm be compiled-in due to it's early use. The default IMA algorithm is protected by Kconfig to be compiled-in. The ima_hash kernel parameter allows to choose the hash algorithm. When the specified algorithm is not available or available as a module, IMA initialization fails, which leads to a kernel panic (mknodat syscall calls ima_post_path_mknod()). Therefore as fallback we force IMA to use the default builtin Kconfig hash algorithm. Fixed crash: $ grep CONFIG_CRYPTO_MD4 .config CONFIG_CRYPTO_MD4=m [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-2.3-default root=UUID=74ae8202-9ca7-4e39-813b-22287ec52f7a video=1024x768-16 plymouth.ignore-serial-consoles console=ttyS0 console=tty resume=/dev/disk/by-path/pci-0000:00:07.0-part3 splash=silent showopts ima_hash=md4 ... [ 1.545190] ima: Can not allocate md4 (reason: -2) ... [ 2.610120] BUG: unable to handle kernel NULL pointer dereference at (null) [ 2.611903] IP: ima_match_policy+0x23/0x390 [ 2.612967] PGD 0 P4D 0 [ 2.613080] Oops: 0000 [#1] SMP [ 2.613080] Modules linked in: autofs4 [ 2.613080] Supported: Yes [ 2.613080] CPU: 0 PID: 1 Comm: systemd Not tainted 4.12.14-2.3-default #1 [ 2.613080] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 [ 2.613080] task: ffff88003e2d0040 task.stack: ffffc90000190000 [ 2.613080] RIP: 0010:ima_match_policy+0x23/0x390 [ 2.613080] RSP: 0018:ffffc90000193e88 EFLAGS: 00010296 [ 2.613080] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000004 [ 2.613080] RDX: 0000000000000010 RSI: 0000000000000001 RDI: ffff880037071728 [ 2.613080] RBP: 0000000000008000 R08: 0000000000000000 R09: 0000000000000000 [ 2.613080] R10: 0000000000000008 R11: 61c8864680b583eb R12: 00005580ff10086f [ 2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000008000 [ 2.613080] FS: 00007f5c1da08940(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 [ 2.613080] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.613080] CR2: 0000000000000000 CR3: 0000000037002000 CR4: 00000000003406f0 [ 2.613080] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.613080] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.613080] Call Trace: [ 2.613080] ? shmem_mknod+0xbf/0xd0 [ 2.613080] ima_post_path_mknod+0x1c/0x40 [ 2.613080] SyS_mknod+0x210/0x220 [ 2.613080] entry_SYSCALL_64_fastpath+0x1a/0xa5 [ 2.613080] RIP: 0033:0x7f5c1bfde570 [ 2.613080] RSP: 002b:00007ffde1c90dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000085 [ 2.613080] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5c1bfde570 [ 2.613080] RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00005580ff10086f [ 2.613080] RBP: 00007ffde1c91040 R08: 00005580ff10086f R09: 0000000000000000 [ 2.613080] R10: 0000000000104000 R11: 0000000000000246 R12: 00005580ffb99660 [ 2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000002 [ 2.613080] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 57 41 56 44 8d 14 09 41 55 41 54 55 53 44 89 d3 09 cb 48 83 ec 38 48 8b 05 c5 03 29 01 <4c> 8b 20 4c 39 e0 0f 84 d7 01 00 00 4c 89 44 24 08 89 54 24 20 [ 2.613080] RIP: ima_match_policy+0x23/0x390 RSP: ffffc90000193e88 [ 2.613080] CR2: 0000000000000000 [ 2.613080] ---[ end trace 9a9f0a8a73079f6a ]--- [ 2.673052] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 2.673052] [ 2.675337] Kernel Offset: disabled [ 2.676405] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 Signed-off-by: Petr Vorel Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bc72e4fcc12a4b983666d3909edde2a14f1fb870 Author: Jiandi An Date: Tue Mar 6 23:26:26 2018 -0600 ima: Fix Kconfig to select TPM 2.0 CRB interface [ Upstream commit fac37c628fd5d68fd7298d9b57ae8601ee1b4723 ] TPM_CRB driver provides TPM CRB 2.0 support. If it is built as a module, the TPM chip is registered after IMA init. tpm_pcr_read() in IMA fails and displays the following message even though eventually there is a TPM chip on the system. ima: No TPM chip found, activating TPM-bypass! (rc=-19) Fix IMA Kconfig to select TPM_CRB so TPM_CRB driver is built in the kernel and initializes before IMA. Signed-off-by: Jiandi An Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d7b13824c390805830e0ac8d8f89f0903272e234 Author: Arjun Vynipadath Date: Fri Mar 23 15:25:10 2018 +0530 cxgb4: Setup FW queues before registering netdev [ Upstream commit 843bd7db79c861b49e2912d723625f5fa8e94502 ] When NetworkManager is enabled, there are chances that interface up is called even before probe completes. This means we have not yet allocated the FW sge queues, hence rest of ingress queue allocation wont be proper. Fix this by calling setup_fw_sge_queues() before register_netdev(). Fixes: 0fbc81b3ad51 ('chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's') Signed-off-by: Arjun Vynipadath Signed-off-by: Casey Leedom Signed-off-by: Ganesh Goudar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aa5a781f59fba7e525f197a0b92613b1da7bdcd2 Author: Sebastian Gottschall Date: Sat Mar 3 05:10:44 2018 +0100 ath9k: fix crash in spectral scan [ Upstream commit 221b6ec69ed9c56b6cd9a124a387a9472f14284e ] Fixes crash seen on arm smp systems (gateworks ventana imx6): Unable to handle kernel NULL pointer dereference at virtual address 00000014 pgd = 80004000 [00000014] *pgd=00000000 Internal error: Oops - BUG: 17 [#1] PREEMPT SMP ARM Modules linked in: ip6table_filter nf_conntrack_ipv6 ip6_tables nf_log_ipv6 nf_defrag_ipv6 shortcut_fe ipcomp6 xfrm_ipcomp xfrm6_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet ip6_tunnel tunnel6 mip6 ah6 esp6 xfrm_algo sit ip_tunnel tunnel4 ipv6 ath10k_pci ath10k_core ath9k ath mac80211 cfg80211 compat ath_pci ath_hal(P) caamalg authencesn authenc caamrng caamhash caam_jr caam cdc_ncm usbnet usbcore sky2 imx2_wdt CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: P 4.9.85 #19 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) task: bf064980 task.stack: bf07c000 PC is at relay_buf_full+0xc/0x30 LR is at _674+0x740/0xf10 [ath9k] pc : [<8018bce0>] lr : [<7f1aa604>] psr: 80000013 sp : bf07dbf0 ip : bf07dc00 fp : bf07dbfc r10: 0000003f r9 : bf130e00 r8 : 809044b0 r7 : 00000000 r6 : be67a9f0 r5 : 00000000 r4 : 809043e4 r3 : c0864c24 r2 : 00000000 r1 : 00000004 r0 : 00000000 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 4e6a004a DAC: 00000055 Process ksoftirqd/0 (pid: 3, stack limit = 0xbf07c210) Stack: (0xbf07dbf0 to 0xbf07e000) dbe0: bf07dd04 bf07dc00 7f1aa604 8018bce0 dc00: 00004014 be59e010 bf07dc34 bf07dc18 7f1a7084 7f19c07c be59c010 be6470a0 dc20: 0000096c be648954 bf07dc6c bf07dc38 7f1c286c bf07dd90 bf07dc5c bf07dc48 dc40: 8029ea4c 0000003c 00000001 be59c010 00000094 00000000 00000000 00000000 dc60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dc80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dca0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dcc0: 00000000 00000000 00000000 00000000 00000000 00000000 8010ef24 00000030 dce0: be94f5e8 be6485a0 bddf0200 be59c010 be6465a0 be6415a0 bf07ddf4 bf07dd08 dd00: 7f1cf800 7f1aa55c 1fc38c4c 00000000 bf07dd58 cccccccd 66666667 be640bc0 dd20: bf07dd54 be6415a0 1fc38c4c 00000000 00000000 be59c038 be67a9c0 be59e010 dd40: be67a9f0 be647170 8090c904 be59c010 00000000 00000001 1fc38e84 00000000 dd60: be640bc0 bddf0200 00000200 00000010 0000003f 00000002 20000013 be59c010 dd80: 8092d940 bf7ca2c0 bf07ddb4 bf07dd98 1fc38c4c 2602003f 0100ff1b 80ff1b00 dda0: 00808080 00000000 00000000 80808080 80808080 80808080 80808080 00008080 ddc0: 00000000 00000000 7f1b62b8 00000002 be6470ec be6470f0 00000000 bf07de98 dde0: 8092d940 be6415a0 bf07de94 bf07ddf8 7f1d1ed8 7f1cf1fc 00000000 00000000 de00: bf7cc4c0 00000400 be6470f0 bf07de18 8015165c be59c010 8090453c 8090453c de20: bf07dec4 be6465a0 8014f614 80148884 0000619a 00000001 bf07c000 00000100 de40: bf07de78 00000001 7f327850 00000002 afb50401 bf064980 bf07de9c bf07de68 de60: bf064a00 803cc668 bf064a00 be6470b4 be6470b8 80844180 00000000 bf07de98 de80: 8092d940 bf07c000 bf07dec4 bf07de98 80124d18 7f1d1c44 80124c94 00000000 dea0: 00000006 80902098 80902080 40000006 00000100 bf07c000 bf07df24 bf07dec8 dec0: 8012501c 80124ca0 bf7cc4c0 bf064980 be95e1c0 04208040 80902d00 000061c7 dee0: 0000000a 80600b54 8092d940 808441f8 80902080 bf07dec8 bf03b200 bf07c000 df00: bf03b200 8090fe54 00000000 00000000 00000000 00000000 bf07df34 bf07df28 df20: 80125148 80124f28 bf07df5c bf07df38 8013deb4 8012511c 00000000 bf03b240 df40: bf03b200 8013dc90 00000000 00000000 bf07dfac bf07df60 8013ad40 8013dc9c df60: 70448040 00000001 00000000 bf03b200 00000000 00030003 bf07df78 bf07df78 df80: 00000000 00000000 bf07df88 bf07df88 bf03b240 8013ac48 00000000 00000000 dfa0: 00000000 bf07dfb0 80107760 8013ac54 00000000 00000000 00000000 00000000 dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 8c120004 1190ad04 Backtrace: [<8018bcd4>] (relay_buf_full) from [<7f1aa604>] (_674+0x740/0xf10 [ath9k]) [<7f1aa550>] (_674 [ath9k]) from [<7f1cf800>] (_582+0x14b4/0x3708 [ath9k]) r10:be6415a0 r9:be6465a0 r8:be59c010 r7:bddf0200 r6:be6485a0 r5:be94f5e8 r4:00000030 [<7f1cf1f0>] (_582 [ath9k]) from [<7f1d1ed8>] (_735+0x2a0/0xec4 [ath9k]) r10:be6415a0 r9:8092d940 r8:bf07de98 r7:00000000 r6:be6470f0 r5:be6470ec r4:00000002 [<7f1d1c38>] (_735 [ath9k]) from [<80124d18>] (tasklet_action+0x84/0xf8) r10:bf07c000 r9:8092d940 r8:bf07de98 r7:00000000 r6:80844180 r5:be6470b8 r4:be6470b4 [<80124c94>] (tasklet_action) from [<8012501c>] (__do_softirq+0x100/0x1f4) r10:bf07c000 r9:00000100 r8:40000006 r7:80902080 r6:80902098 r5:00000006 r4:00000000 r3:80124c94 [<80124f1c>] (__do_softirq) from [<80125148>] (run_ksoftirqd+0x38/0x4c) r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:8090fe54 r5:bf03b200 r4:bf07c000 [<80125110>] (run_ksoftirqd) from [<8013deb4>] (smpboot_thread_fn+0x224/0x260) [<8013dc90>] (smpboot_thread_fn) from [<8013ad40>] (kthread+0xf8/0x100) r9:00000000 r8:00000000 r7:8013dc90 r6:bf03b200 r5:bf03b240 r4:00000000 [<8013ac48>] (kthread) from [<80107760>] (ret_from_fork+0x14/0x34) r7:00000000 r6:00000000 r5:8013ac48 r4:bf03b240 Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5901014) ---[ end trace dddf11ac9111b272 ]--- Kernel panic - not syncing: Fatal exception in interrupt CPU1: stopping CPU: 1 PID: 0 Comm: swapper/1 Tainted: P D 4.9.85 #19 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [<8010a708>] (dump_backtrace) from [<8010a99c>] (show_stack+0x18/0x1c) r7:bf093f58 r6:20000193 r5:809168e8 r4:00000000 [<8010a984>] (show_stack) from [<802a09c4>] (dump_stack+0x94/0xa8) [<802a0930>] (dump_stack) from [<8010d184>] (handle_IPI+0xe8/0x180) r7:bf093f58 r6:00000000 r5:00000001 r4:808478c4 [<8010d09c>] (handle_IPI) from [<801013e8>] (gic_handle_irq+0x78/0x7c) r7:f4000100 r6:bf093f58 r5:f400010c r4:8090467c [<80101370>] (gic_handle_irq) from [<8010b378>] (__irq_svc+0x58/0x8c) Exception stack(0xbf093f58 to 0xbf093fa0) 3f40: bf7d62a0 00000000 3f60: 0010a5f4 80113460 bf092000 809043e4 00000002 80904434 bf092008 412fc09a 3f80: 00000000 bf093fb4 bf093fb8 bf093fa8 8010804c 80108050 60000013 ffffffff r9:bf092000 r8:bf092008 r7:bf093f8c r6:ffffffff r5:60000013 r4:80108050 [<80108014>] (arch_cpu_idle) from [<80553c2c>] (default_idle_call+0x30/0x34) [<80553bfc>] (default_idle_call) from [<80158394>] (cpu_startup_entry+0xc4/0xfc) [<801582d0>] (cpu_startup_entry) from [<8010ce40>] (secondary_start_kernel+0x168/0x174) r7:8092d2f8 r4:80913568 [<8010ccd8>] (secondary_start_kernel) from [<10101488>] (0x10101488) r5:00000055 r4:4f07806a Rebooting in 10 seconds.. Reboot failed -- System halted Signed-off-by: Sebastian Gottschall Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 085ec7d554c176a167825100f47e721dae5fbec4 Author: Jarosław Janik Date: Sun Mar 11 19:51:56 2018 +0100 nvme-pci: disable APST for Samsung NVMe SSD 960 EVO + ASUS PRIME Z370-A [ Upstream commit 467c77d4cbefaaf65e2f44fe102d543a52fcae5b ] Yet another "incompatible" Samsung NVMe SSD 960 EVO and Asus motherboard combination. 960 EVO device disappears from PCIe bus within few minutes after boot-up when APST is in use and never gets back. Forcing NVME_QUIRK_NO_APST is the only way to make this drive work with this particular motherboard. NVME_QUIRK_NO_DEEPEST_PS doesn't work, upgrading motherboard's BIOS didn't help either. Since this is a desktop motherboard, the only drawback of not using APST is increased device temperature. Signed-off-by: Jarosław Janik Signed-off-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7e5487b3990de1445d172b739b1924fb1f4d95a9 Author: Karthikeyan Periyasamy Date: Mon Mar 12 17:09:40 2018 +0530 ath10k: Fix kernel panic while using worker (ath10k_sta_rc_update_wk) [ Upstream commit 8b2d93dd22615cb7f3046a5a2083a6f8bb8052ed ] When attempt to run worker (ath10k_sta_rc_update_wk) after the station object (ieee80211_sta) delete will trigger the kernel panic. This problem arise in AP + Mesh configuration, Where the current node AP VAP and neighbor node mesh VAP MAC address are same. When the current mesh node try to establish the mesh link with neighbor node, driver peer creation for the neighbor mesh node fails due to duplication MAC address. Already the AP VAP created with same MAC address. It is caused by the following scenario steps. Steps: 1. In above condition, ath10k driver sta_state callback (ath10k_sta_state) fails to do the state change for a station from IEEE80211_STA_NOTEXIST to IEEE80211_STA_NONE due to peer creation fails. Sta_state callback is called from ieee80211_add_station() to handle the new station (neighbor mesh node) request from the wpa_supplicant. 2. Concurrently ath10k receive the sta_rc_update callback notification from the mesh_neighbour_update() to handle the beacon frames of the above neighbor mesh node. since its atomic callback, ath10k driver queue the work (ath10k_sta_rc_update_wk) to handle rc update. 3. Due to driver sta_state callback fails (step 1), mac80211 free the station object. 4. When the worker (ath10k_sta_rc_update_wk) scheduled to run, it will access the station object which is already deleted. so it will trigger kernel panic. Added the peer exist check in sta_rc_update callback before queue the work. Kernel Panic log: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0204000 [00000000] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 1 PID: 1833 Comm: kworker/u4:2 Not tainted 3.14.77 #1 task: dcef0000 ti: d72b6000 task.ti: d72b6000 PC is at pwq_activate_delayed_work+0x10/0x40 LR is at pwq_activate_delayed_work+0xc/0x40 pc : [] lr : [] psr: 40000193 sp : d72b7f18 ip : 0000007a fp : d72b6000 r10: 00000000 r9 : dd404414 r8 : d8c31998 r7 : d72b6038 r6 : 00000004 r5 : d4907ec8 r4 : dcee1300 r3 : ffffffe0 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: 595bc06a DAC: 00000015 ... Process kworker/u4:2 (pid: 1833, stack limit = 0xd72b6238) Stack: (0xd72b7f18 to 0xd72b8000) 7f00: 00000001 dcee1300 7f20: 00000001 c02410dc d8c31980 dd404400 dd404400 c0242790 d8c31980 00000089 7f40: 00000000 d93e1340 00000000 d8c31980 c0242568 00000000 00000000 00000000 7f60: 00000000 c02474dc 00000000 00000000 000000f8 d8c31980 00000000 00000000 7f80: d72b7f80 d72b7f80 00000000 00000000 d72b7f90 d72b7f90 d72b7fac d93e1340 7fa0: c0247404 00000000 00000000 c0208d20 00000000 00000000 00000000 00000000 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [] (pwq_activate_delayed_work) from [] (pwq_dec_nr_in_flight+0x58/0xc4) [] (pwq_dec_nr_in_flight) from [] (worker_thread+0x228/0x360) [] (worker_thread) from [] (kthread+0xd8/0xec) [] (kthread) from [] (ret_from_fork+0x14/0x34) Code: e92d4038 e1a05000 ebffffbc[69210.619376] SMP: failed to stop secondary CPUs Rebooting in 3 seconds.. Signed-off-by: Karthikeyan Periyasamy Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5db7e1bb6a132625d7c7f9d5b259d26c959388e1 Author: Alexey Khoroshilov Date: Sat Mar 24 00:36:46 2018 +0300 watchdog: davinci_wdt: fix error handling in davinci_wdt_probe() [ Upstream commit d66e53649c18377edc08d48901e658e4fd491d46 ] clk_disable_unprepare() was added to one error path, but there is another one. The patch makes sure clk is disabled at the both of them. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc7bcbb940278a9fa81c6e5cbd4402a275cd131c Author: Leon Romanovsky Date: Tue Jan 2 16:49:56 2018 +0200 net/mlx5: Protect from command bit overflow [ Upstream commit 957f6ba8adc7be401a74ccff427e4cfd88d3bfcb ] The system with CONFIG_UBSAN enabled on produces the following error during driver initialization. The reason to it that max_reg_cmds can be larger enough to cause to "1 << max_reg_cmds" overflow the unsigned long. ================================================================================ UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx5/core/cmd.c:1805:42 signed integer overflow: -2147483648 - 1 cannot be represented in type 'int' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00032-g06cda2358d9b-dirty #724 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Call Trace: dump_stack+0xe9/0x18f ? dma_virt_alloc+0x81/0x81 ubsan_epilogue+0xe/0x4e handle_overflow+0x187/0x20c mlx5_cmd_init+0x73a/0x12b0 mlx5_load_one+0x1c3d/0x1d30 init_one+0xd02/0xf10 pci_device_probe+0x26c/0x3b0 driver_probe_device+0x622/0xb40 __driver_attach+0x175/0x1b0 bus_for_each_dev+0xef/0x190 bus_add_driver+0x2db/0x490 driver_register+0x16b/0x1e0 __pci_register_driver+0x177/0x1b0 init+0x6d/0x92 do_one_initcall+0x15b/0x270 kernel_init_freeable+0x2d8/0x3d0 kernel_init+0x14/0x190 ret_from_fork+0x24/0x30 ================================================================================ Signed-off-by: Leon Romanovsky Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d018d551e7b23b6ab8e1faf95fc6409a0232c53b Author: Michael Ellerman Date: Fri Mar 23 20:44:27 2018 +1100 selftests: Print the test we're running to /dev/kmsg [ Upstream commit 88893cf787d3062c631cc20b875068eb11756e03 ] Some tests cause the kernel to print things to the kernel log buffer (ie. printk), in particular oops and warnings etc. However when running all the tests in succession it's not always obvious which test(s) caused the kernel to print something. We can narrow it down by printing which test directory we're running in to /dev/kmsg, if it's writable. Example output: [ 170.149149] kselftest: Running tests in powerpc [ 305.300132] kworker/dying (71) used greatest stack depth: 7776 bytes left [ 808.915456] kselftest: Running tests in pstore Signed-off-by: Michael Ellerman Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit faace30e6e6a8f1b93532938351c7e06dd6759e7 Author: Frank Asseg Date: Mon Mar 12 19:57:06 2018 +0100 tools/thermal: tmon: fix for segfault [ Upstream commit 6c59f64b7ecf2bccbe73931d7d573d66ed13b537 ] Fixes a segfault occurring when e.g. is pressed multiple times in the ncurses tmon application. The segfault is caused by incrementing cur_thermal_record in the main function without checking if it's value reached NR_THERMAL_RECORD immediately. Since the boundary check only occurred in update_thermal_data a race condition existed, which lead to an attempted read beyond the last element of the trec array. The fix was implemented by moving the cur_thermal_record incrementation to the update_thermal_data function using a temporary variable on which the boundary condition is checked before updating cur_thread_record, so that the variable is never incremented beyond the trec array's boundary. It seems the segfault does not occur on every machine: On a HP EliteBook G4 the segfault happens, while it does not happen on a Thinkpad T540p. Signed-off-by: Frank Asseg Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b652092f8e99af83623664c6238daf700acd3c22 Author: Amitkumar Karwar Date: Tue Mar 20 19:10:41 2018 +0530 rsi: fix kernel panic observed on 64bit machine [ Upstream commit 864db4d5085349fcfa1f260b5bcd2adde3d7f2ed ] Following kernel panic is observed on 64bit machine while loading the driver. It is fixed if we pass dynamically allocated memory to SDIO for DMA. BUG: unable to handle kernel paging request at ffffeb04000172e0 IP: sg_miter_stop+0x56/0x70 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Modules linked in: rsi_sdio(OE+) rsi_91x(OE) btrsi(OE) rfcomm bluetooth ecdh_generic mac80211 mmc_block fuse xt_CHECKSUM iptable_mangle drm_kms_helper mmc_core serio_raw drm firewire_ohci tg3 CPU: 0 PID: 4003 Comm: insmod Tainted: G OE 4.16.0-rc1+ #27 Hardware name: Dell Inc. Latitude E5500 /0DW634, BIOS A19 06/13/2013 RIP: 0010:sg_miter_stop+0x56/0x70 RSP: 0018:ffff88007d003e78 EFLAGS: 00010002 RAX: 0000000000000003 RBX: 0000000000000004 RCX: 0000000000000000 RDX: ffffeb04000172c0 RSI: ffff88002f58002c RDI: ffff88007d003e80 RBP: 0000000000000004 R08: ffff88007d003e80 R09: 0000000000000008 R10: 0000000000000003 R11: 0000000000000001 R12: 0000000000000004 R13: ffff88002f580028 R14: 0000000000000000 R15: 0000000000000004 FS: 00007f35c29db700(0000) GS:ffff88007d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffeb04000172e0 CR3: 000000007038e000 CR4: 00000000000406f0 Call Trace: sg_copy_buffer+0xc6/0xf0 sdhci_tasklet_finish+0x170/0x260 [sdhci] tasklet_action+0xf4/0x100 __do_softirq+0xef/0x26e irq_exit+0xbe/0xd0 do_IRQ+0x4a/0xc0 common_interrupt+0xa2/0xa2 Signed-off-by: Amitkumar Karwar Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 31dbd9cfcb2342c5105610421191467995fac7ad Author: Michael Ellerman Date: Wed Mar 21 17:10:24 2018 +0530 powerpc/perf: Fix kernel address leak via sampling registers [ Upstream commit e1ebd0e5b9d0a10ba65e63a3514b6da8c6a5a819 ] Current code in power_pmu_disable() does not clear the sampling registers like Sampling Instruction Address Register (SIAR) and Sampling Data Address Register (SDAR) after disabling the PMU. Since these are userspace readable and could contain kernel addresses, add code to explicitly clear the content of these registers. Also add a "context synchronizing instruction" to enforce no further updates to these registers as suggested by Power ISA v3.0B. From section 9.4, on page 1108: "If an mtspr instruction is executed that changes the value of a Performance Monitor register other than SIAR, SDAR, and SIER, the change is not guaranteed to have taken effect until after a subsequent context synchronizing instruction has been executed (see Chapter 11. "Synchronization Requirements for Context Alterations" on page 1133)." Signed-off-by: Madhavan Srinivasan [mpe: Massage change log and add ISA reference] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6a0a9f0ab8a95395d280eb581df26f983d0b4064 Author: Madhavan Srinivasan Date: Wed Mar 21 17:10:25 2018 +0530 powerpc/perf: Prevent kernel address leak to userspace via BHRB buffer [ Upstream commit bb19af816025d495376bd76bf6fbcf4244f9a06d ] The current Branch History Rolling Buffer (BHRB) code does not check for any privilege levels before updating the data from BHRB. This could leak kernel addresses to userspace even when profiling only with userspace privileges. Add proper checks to prevent it. Acked-by: Balbir Singh Signed-off-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 68a38cedff764feb87353f90d1ad9b70afdd635e Author: Guenter Roeck Date: Mon Mar 26 19:50:31 2018 -0700 hwmon: (nct6775) Fix writing pwmX_mode [ Upstream commit 415eb2a1aaa4881cf85bd86c683356fdd8094a23 ] pwmX_mode is defined in the ABI as 0=DC mode, 1=pwm mode. The chip register bit is set to 1 for DC mode. This got mixed up, and writing 1 into pwmX_mode resulted in DC mode enabled. Fix it up by using the ABI definition throughout the driver for consistency. Fixes: 77eb5b3703d99 ("hwmon: (nct6775) Add support for pwm, pwm_mode, ... ") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dbce9e41161cef5365ebd17f8597ea7e986977c1 Author: Helge Deller Date: Sun Mar 25 14:04:22 2018 +0200 parisc/pci: Switch LBA PCI bus from Hard Fail to Soft Fail mode [ Upstream commit b845f66f78bf42a4ce98e5cfe0e94fab41dd0742 ] Carlo Pisani noticed that his C3600 workstation behaved unstable during heavy I/O on the PCI bus with a VIA VT6421 IDE/SATA PCI card. To avoid such instability, this patch switches the LBA PCI bus from Hard Fail mode into Soft Fail mode. In this mode the bus will return -1UL for timed out MMIO transactions, which is exactly how the x86 (and most other architectures) PCI busses behave. This patch is based on a proposal by Grant Grundler and Kyle McMartin 10 years ago: https://www.spinics.net/lists/linux-parisc/msg01027.html Cc: Carlo Pisani Cc: Kyle McMartin Reviewed-by: Grant Grundler Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f37519543460fc8fee53d21589d40acdeb3d35d3 Author: Luca Coelho Date: Mon Dec 18 20:13:07 2017 +0200 iwlwifi: mvm: check if mac80211_queue is valid in iwl_mvm_disable_txq [ Upstream commit 9a233bb8025105db9a60b5d761005cc5a6c77f3d ] Sometimes iwl_mvm_disable_txq() may be called with mac80211_queue == IEEE80211_INVAL_HW_QUEUE, and this would cause us to use BIT(0xFF) which is way too large for the u16 we used to store it in hw_queue_to_mac820211. If this happens the following UBSAN warning will be generated: [ 167.185167] UBSAN: Undefined behaviour in drivers/net/wireless/intel/iwlwifi/mvm/utils.c:838:5 [ 167.185171] shift exponent 255 is too large for 64-bit type 'long unsigned int' Fix that by checking that it is not IEEE80211_INVAL_HW_QUEUE and, while at it, add a warning if the queue number is larger than IEEE80211_MAX_QUEUES. Fixes: 34e10860ae8d ("iwlwifi: mvm: remove references to queue_info in new TX path") Reported-by: Paul Menzel Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6a020bb3c62022ea44b8118ad14d113c96a8b93d Author: Greg Ungerer Date: Wed Mar 28 17:12:18 2018 +1000 m68k: set dma and coherent masks for platform FEC ethernets [ Upstream commit f61e64310b75733d782e930d1fb404b84699eed6 ] As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask") the Freescale FEC driver is issuing the following warning on driver initialization on ColdFire systems: WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20 Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4 Stack from 41833dd8: 41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000 400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d 40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000 00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000 Call Trace: [<40025534>] 0x40025534 [<4004e514>] 0x4004e514 [<400255de>] 0x400255de [<40159e20>] 0x40159e20 [<40159e20>] 0x40159e20 It is not fatal, the driver and the system continue to function normally. As per the warning the coherent_dma_mask is not set on this device. There is nothing special about the DMA memory coherency on this hardware so we can just set the mask to 32bits in the platform data for the FEC ethernet devices. Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 80fceaf3f16a02cc82209a4f9e6d8cfa46ba1d60 Author: Alexander Shishkin Date: Thu Mar 1 10:15:32 2018 +0200 intel_th: Use correct method of finding hub [ Upstream commit 9ad577087165478c9d9be82b15ed9bf2db5835f5 ] Since commit 8edc514b01e9 ("intel_th: Make SOURCE devices children of the root device") the hub is not the parent of SOURCE devices any more, so the new helper function should be used for that instead of always using the parent. The intel_th_set_output() path, however, still uses the old logic, leading to the hub driver structure being aliased with something else, like struct pci_driver or struct acpi_driver, and an incorrect call to an address inferred from that, potentially resulting in a crash. Fixes: 8edc514b01e9 ("intel_th: Make SOURCE devices children of the root device") Signed-off-by: Alexander Shishkin Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1366b31d18297ff1879f0becf941425503408447 Author: Sebastian Andrzej Siewior Date: Thu Mar 22 16:22:33 2018 +0100 iommu/amd: Take into account that alloc_dev_data() may return NULL [ Upstream commit 39ffe39545cd5cb5b8cee9f0469165cf24dc62c2 ] find_dev_data() does not check whether the return value alloc_dev_data() is NULL. This was okay once because the pointer was returned once as-is. Since commit df3f7a6e8e85 ("iommu/amd: Use is_attach_deferred call-back") the pointer may be used within find_dev_data() so a NULL check is required. Cc: Baoquan He Fixes: df3f7a6e8e85 ("iommu/amd: Use is_attach_deferred call-back") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6bc2bf6023dde77b77f183e89c7690cb3f4f0f2d Author: Anilkumar Kolli Date: Wed Mar 28 12:19:40 2018 +0300 ath10k: advertize beacon_int_min_gcd [ Upstream commit 8ebee73b574ad3dd1f14d461f65ceaffbd637650 ] This patch fixes regression caused by 0c317a02ca98 ("cfg80211: support virtual interfaces with different beacon intervals"), with this change cfg80211 expects the driver to advertize 'beacon_int_min_gcd' to support different beacon intervals in multivap scenario. This support is added for, QCA988X/QCA99X0/QCA9984/QCA4019. Verifed AP + mesh bring up on QCA9984 with beacon interval 100msec and 1000msec respectively. Frimware: firmware-5.bin_10.4-3.5.3-00053 Fixes: 0c317a02ca98 ("cfg80211: support virtual interfaces with different beacon intervals") Signed-off-by: Anilkumar Kolli Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9c222c497ba27164c71d985635e016424543ed18 Author: Harry Morris Date: Wed Mar 28 11:54:27 2018 +0100 ieee802154: ca8210: fix uninitialised data read [ Upstream commit 86674a97f5055f4c7f406563408096e8cf9364ff ] In ca8210_test_int_user_write() a user can request the transfer of a frame with a length field (command.length) that is longer than the actual buffer provided (len). In this scenario the driver will copy the buffer contents into the uninitialised command[] buffer, then transfer bytes over the SPI even though only bytes had been populated, potentially leaking sensitive kernel memory. Also the first 6 bytes of the command buffer must be initialised in case a malformed, short packet is written and the uninitialised bytes are read in ca8210_test_check_upstream. Reported-by: Domen Puncer Kugler Signed-off-by: Harry Morris Tested-by: Harry Morris Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c3a2a8782059272dfaa355072683d584c08e94a2 Author: Michael Ellerman Date: Fri Mar 30 23:27:25 2018 +1100 powerpc/mpic: Check if cpu_possible() in mpic_physmask() [ Upstream commit 0834d627fbea00c1444075eb3e448e1974da452d ] In mpic_physmask() we loop over all CPUs up to 32, then get the hard SMP processor id of that CPU. Currently that's possibly walking off the end of the paca array, but in a future patch we will change the paca array to be an array of pointers, and in that case we will get a NULL for missing CPUs and oops. eg: Unable to handle kernel paging request for data at address 0x88888888888888b8 Faulting instruction address: 0xc00000000004e380 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP .mpic_set_affinity+0x60/0x1a0 LR .irq_do_set_affinity+0x48/0x100 Fix it by checking the CPU is possible, this also fixes the code if there are gaps in the CPU numbering which probably never happens on mpic systems but who knows. Debugged-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc2de796926b6086634833fcd8705d0d3c94cb1a Author: Lenny Szubowicz Date: Tue Mar 27 09:56:40 2018 -0400 ACPI: acpi_pad: Fix memory leak in power saving threads [ Upstream commit 8b29d29abc484d638213dd79a18a95ae7e5bb402 ] Fix once per second (round_robin_time) memory leak of about 1 KB in each acpi_pad kernel idling thread that is activated. Found by testing with kmemleak. Signed-off-by: Lenny Szubowicz Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d023498fef3506790a939f0b6cc63f5eca228a25 Author: Aaro Koskinen Date: Fri Mar 16 22:17:28 2018 +0200 drivers: macintosh: rack-meter: really fix bogus memsets [ Upstream commit e283655b5abe26462d53d5196f186c5e8863af3b ] We should zero an array using sizeof instead of number of elements. Fixes the following compiler (GCC 7.3.0) warnings: drivers/macintosh/rack-meter.c: In function 'rackmeter_do_pause': drivers/macintosh/rack-meter.c:157:2: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] drivers/macintosh/rack-meter.c:158:2: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] Fixes: 4f7bef7a9f69 ("drivers: macintosh: rack-meter: fix bogus memsets") Reported-by: Stephen Rothwell Signed-off-by: Aaro Koskinen Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8effa2182d02291345a066bb191750755add7fc4 Author: Dan Carpenter Date: Thu Mar 29 12:01:53 2018 +0300 xen/acpi: off by one in read_acpi_id() [ Upstream commit c37a3c94775855567b90f91775b9691e10bd2806 ] If acpi_id is == nr_acpi_bits, then we access one element beyond the end of the acpi_psd[] array or we set one bit beyond the end of the bit map when we do __set_bit(acpi_id, acpi_id_present); Fixes: 59a568029181 ("xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.") Signed-off-by: Dan Carpenter Reviewed-by: Joao Martins Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 637b9b187f4e024979e9ca401042eee2b5390a1e Author: David Howells Date: Fri Mar 30 21:04:44 2018 +0100 rxrpc: Don't treat call aborts as conn aborts [ Upstream commit 57b0c9d49b94bbeb53649b7fbd264603c1ebd585 ] If a call-level abort is received for the previous call to complete on a connection channel, then that abort is queued for the connection processor to handle. Unfortunately, the connection processor then assumes without checking that the abort is connection-level (ie. callNumber is 0) and distributes it over all active calls on that connection, thereby incorrectly aborting them. Fix this by discarding aborts aimed at a completed call. Further, discard all packets aimed at a call that's complete if there's currently an active call on a channel, since the DATA packets associated with the new call automatically terminate the old call. Fixes: 18bfeba50dfd ("rxrpc: Perform terminal call ACK/ABORT retransmission from conn processor") Reported-by: Marc Dionne Signed-off-by: David Howells Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a9fabcd3440357e45b4b52f47478d57858cede4 Author: David Howells Date: Fri Mar 30 21:04:43 2018 +0100 rxrpc: Fix Tx ring annotation after initial Tx failure [ Upstream commit 03877bf6a30cca7d4bc3ffabd3c3e9464a7a1a19 ] rxrpc calls have a ring of packets that are awaiting ACK or retransmission and a parallel ring of annotations that tracks the state of those packets. If the initial transmission of a packet on the underlying UDP socket fails then the packet annotation is marked for resend - but the setting of this mark accidentally erases the last-packet mark also stored in the same annotation slot. If this happens, a call won't switch out of the Tx phase when all the packets have been transmitted. Fix this by retaining the last-packet mark and only altering the packet state. Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Signed-off-by: David Howells Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 204bfcda824428b3a298eae8e87875bbd435a3c1 Author: Qu Wenruo Date: Tue Dec 19 15:44:54 2017 +0800 btrfs: qgroup: Fix root item corruption when multiple same source snapshots are created with quota enabled [ Upstream commit 4d31778aa2fa342f5f92ca4025b293a1729161d1 ] When multiple pending snapshots referring to the same source subvolume are executed, enabled quota will cause root item corruption, where root items are using old bytenr (no backref in extent tree). This can be triggered by fstests btrfs/152. The cause is when source subvolume is still dirty, extra commit (simplied transaction commit) of qgroup_account_snapshot() can skip dirty roots not recorded in current transaction, making root item of source subvolume not updated. Fix it by forcing recording source subvolume in current transaction before qgroup sub-transaction commit. Reported-by: Justin Maggard Signed-off-by: Qu Wenruo Reviewed-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit de00d57294820dc171cf5393afe5a06600d09fb8 Author: Jeff Mahoney Date: Fri Mar 16 14:36:27 2018 -0400 btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers [ Upstream commit 8a5a916d9a35e13576d79cc16e24611821b13e34 ] While running btrfs/011, I hit the following lockdep splat. This is the important bit: pcpu_alloc+0x1ac/0x5e0 __percpu_counter_init+0x4e/0xb0 btrfs_init_fs_root+0x99/0x1c0 [btrfs] btrfs_get_fs_root.part.54+0x5b/0x150 [btrfs] resolve_indirect_refs+0x130/0x830 [btrfs] find_parent_nodes+0x69e/0xff0 [btrfs] btrfs_find_all_roots_safe+0xa0/0x110 [btrfs] btrfs_find_all_roots+0x50/0x70 [btrfs] btrfs_qgroup_prepare_account_extents+0x53/0x90 [btrfs] btrfs_commit_transaction+0x3ce/0x9b0 [btrfs] The percpu_counter_init call in btrfs_alloc_subvolume_writers uses GFP_KERNEL, which we can't do during transaction commit. This switches it to GFP_NOFS. ======================================================== WARNING: possible irq lock inversion dependency detected 4.12.14-kvmsmall #8 Tainted: G W -------------------------------------------------------- kswapd0/50 just changed the state of lock: (&delayed_node->mutex){+.+.-.}, at: [] __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs] but this lock took another, RECLAIM_FS-unsafe lock in the past: (pcpu_alloc_mutex){+.+.+.} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Chain exists of: &delayed_node->mutex --> &found->groups_sem --> pcpu_alloc_mutex Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pcpu_alloc_mutex); local_irq_disable(); lock(&delayed_node->mutex); lock(&found->groups_sem); lock(&delayed_node->mutex); *** DEADLOCK *** 2 locks held by kswapd0/50: #0: (shrinker_rwsem){++++..}, at: [] shrink_slab+0x7f/0x5b0 #1: (&type->s_umount_key#30){+++++.}, at: [] trylock_super+0x16/0x50 the shortest dependencies between 2nd lock and 1st lock: -> (pcpu_alloc_mutex){+.+.+.} ops: 4904 { HARDIRQ-ON-W at: __mutex_lock+0x4e/0x8c0 pcpu_alloc+0x1ac/0x5e0 alloc_kmem_cache_cpus.isra.70+0x25/0xa0 __do_tune_cpucache+0x2c/0x220 do_tune_cpucache+0x26/0xc0 enable_cpucache+0x6d/0xf0 kmem_cache_init_late+0x42/0x75 start_kernel+0x343/0x4cb x86_64_start_kernel+0x127/0x134 secondary_startup_64+0xa5/0xb0 SOFTIRQ-ON-W at: __mutex_lock+0x4e/0x8c0 pcpu_alloc+0x1ac/0x5e0 alloc_kmem_cache_cpus.isra.70+0x25/0xa0 __do_tune_cpucache+0x2c/0x220 do_tune_cpucache+0x26/0xc0 enable_cpucache+0x6d/0xf0 kmem_cache_init_late+0x42/0x75 start_kernel+0x343/0x4cb x86_64_start_kernel+0x127/0x134 secondary_startup_64+0xa5/0xb0 RECLAIM_FS-ON-W at: __kmalloc+0x47/0x310 pcpu_extend_area_map+0x2b/0xc0 pcpu_alloc+0x3ec/0x5e0 alloc_kmem_cache_cpus.isra.70+0x25/0xa0 __do_tune_cpucache+0x2c/0x220 do_tune_cpucache+0x26/0xc0 enable_cpucache+0x6d/0xf0 __kmem_cache_create+0x1bf/0x390 create_cache+0xba/0x1b0 kmem_cache_create+0x1f8/0x2b0 ksm_init+0x6f/0x19d do_one_initcall+0x50/0x1b0 kernel_init_freeable+0x201/0x289 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 INITIAL USE at: __mutex_lock+0x4e/0x8c0 pcpu_alloc+0x1ac/0x5e0 alloc_kmem_cache_cpus.isra.70+0x25/0xa0 setup_cpu_cache+0x2f/0x1f0 __kmem_cache_create+0x1bf/0x390 create_boot_cache+0x8b/0xb1 kmem_cache_init+0xa1/0x19e start_kernel+0x270/0x4cb x86_64_start_kernel+0x127/0x134 secondary_startup_64+0xa5/0xb0 } ... key at: [] pcpu_alloc_mutex+0x70/0xa0 ... acquired at: pcpu_alloc+0x1ac/0x5e0 __percpu_counter_init+0x4e/0xb0 btrfs_init_fs_root+0x99/0x1c0 [btrfs] btrfs_get_fs_root.part.54+0x5b/0x150 [btrfs] resolve_indirect_refs+0x130/0x830 [btrfs] find_parent_nodes+0x69e/0xff0 [btrfs] btrfs_find_all_roots_safe+0xa0/0x110 [btrfs] btrfs_find_all_roots+0x50/0x70 [btrfs] btrfs_qgroup_prepare_account_extents+0x53/0x90 [btrfs] btrfs_commit_transaction+0x3ce/0x9b0 [btrfs] transaction_kthread+0x176/0x1b0 [btrfs] kthread+0x102/0x140 ret_from_fork+0x3a/0x50 -> (&fs_info->commit_root_sem){++++..} ops: 1566382 { HARDIRQ-ON-W at: down_write+0x3e/0xa0 cache_block_group+0x287/0x420 [btrfs] find_free_extent+0x106c/0x12d0 [btrfs] btrfs_reserve_extent+0xd8/0x170 [btrfs] cow_file_range.isra.66+0x133/0x470 [btrfs] run_delalloc_range+0x121/0x410 [btrfs] writepage_delalloc.isra.50+0xfe/0x180 [btrfs] __extent_writepage+0x19a/0x360 [btrfs] extent_write_cache_pages.constprop.56+0x249/0x3e0 [btrfs] extent_writepages+0x4d/0x60 [btrfs] do_writepages+0x1a/0x70 __filemap_fdatawrite_range+0xa7/0xe0 btrfs_rename+0x5ee/0xdb0 [btrfs] vfs_rename+0x52a/0x7e0 SyS_rename+0x351/0x3b0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 HARDIRQ-ON-R at: down_read+0x35/0x90 caching_thread+0x57/0x560 [btrfs] normal_work_helper+0x1c0/0x5e0 [btrfs] process_one_work+0x1e0/0x5c0 worker_thread+0x44/0x390 kthread+0x102/0x140 ret_from_fork+0x3a/0x50 SOFTIRQ-ON-W at: down_write+0x3e/0xa0 cache_block_group+0x287/0x420 [btrfs] find_free_extent+0x106c/0x12d0 [btrfs] btrfs_reserve_extent+0xd8/0x170 [btrfs] cow_file_range.isra.66+0x133/0x470 [btrfs] run_delalloc_range+0x121/0x410 [btrfs] writepage_delalloc.isra.50+0xfe/0x180 [btrfs] __extent_writepage+0x19a/0x360 [btrfs] extent_write_cache_pages.constprop.56+0x249/0x3e0 [btrfs] extent_writepages+0x4d/0x60 [btrfs] do_writepages+0x1a/0x70 __filemap_fdatawrite_range+0xa7/0xe0 btrfs_rename+0x5ee/0xdb0 [btrfs] vfs_rename+0x52a/0x7e0 SyS_rename+0x351/0x3b0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 SOFTIRQ-ON-R at: down_read+0x35/0x90 caching_thread+0x57/0x560 [btrfs] normal_work_helper+0x1c0/0x5e0 [btrfs] process_one_work+0x1e0/0x5c0 worker_thread+0x44/0x390 kthread+0x102/0x140 ret_from_fork+0x3a/0x50 INITIAL USE at: down_write+0x3e/0xa0 cache_block_group+0x287/0x420 [btrfs] find_free_extent+0x106c/0x12d0 [btrfs] btrfs_reserve_extent+0xd8/0x170 [btrfs] cow_file_range.isra.66+0x133/0x470 [btrfs] run_delalloc_range+0x121/0x410 [btrfs] writepage_delalloc.isra.50+0xfe/0x180 [btrfs] __extent_writepage+0x19a/0x360 [btrfs] extent_write_cache_pages.constprop.56+0x249/0x3e0 [btrfs] extent_writepages+0x4d/0x60 [btrfs] do_writepages+0x1a/0x70 __filemap_fdatawrite_range+0xa7/0xe0 btrfs_rename+0x5ee/0xdb0 [btrfs] vfs_rename+0x52a/0x7e0 SyS_rename+0x351/0x3b0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 } ... key at: [] __key.61970+0x0/0xfffffffffff9aa88 [btrfs] ... acquired at: cache_block_group+0x287/0x420 [btrfs] find_free_extent+0x106c/0x12d0 [btrfs] btrfs_reserve_extent+0xd8/0x170 [btrfs] btrfs_alloc_tree_block+0x12f/0x4c0 [btrfs] btrfs_create_tree+0xbb/0x2a0 [btrfs] btrfs_create_uuid_tree+0x37/0x140 [btrfs] open_ctree+0x23c0/0x2660 [btrfs] btrfs_mount+0xd36/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 btrfs_mount+0x18c/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 do_mount+0x1c1/0xcc0 SyS_mount+0x7e/0xd0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 -> (&found->groups_sem){++++..} ops: 2134587 { HARDIRQ-ON-W at: down_write+0x3e/0xa0 __link_block_group+0x34/0x130 [btrfs] btrfs_read_block_groups+0x33d/0x7b0 [btrfs] open_ctree+0x2054/0x2660 [btrfs] btrfs_mount+0xd36/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 btrfs_mount+0x18c/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 do_mount+0x1c1/0xcc0 SyS_mount+0x7e/0xd0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 HARDIRQ-ON-R at: down_read+0x35/0x90 btrfs_calc_num_tolerated_disk_barrier_failures+0x113/0x1f0 [btrfs] open_ctree+0x207b/0x2660 [btrfs] btrfs_mount+0xd36/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 btrfs_mount+0x18c/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 do_mount+0x1c1/0xcc0 SyS_mount+0x7e/0xd0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 SOFTIRQ-ON-W at: down_write+0x3e/0xa0 __link_block_group+0x34/0x130 [btrfs] btrfs_read_block_groups+0x33d/0x7b0 [btrfs] open_ctree+0x2054/0x2660 [btrfs] btrfs_mount+0xd36/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 btrfs_mount+0x18c/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 do_mount+0x1c1/0xcc0 SyS_mount+0x7e/0xd0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 SOFTIRQ-ON-R at: down_read+0x35/0x90 btrfs_calc_num_tolerated_disk_barrier_failures+0x113/0x1f0 [btrfs] open_ctree+0x207b/0x2660 [btrfs] btrfs_mount+0xd36/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 btrfs_mount+0x18c/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 do_mount+0x1c1/0xcc0 SyS_mount+0x7e/0xd0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 INITIAL USE at: down_write+0x3e/0xa0 __link_block_group+0x34/0x130 [btrfs] btrfs_read_block_groups+0x33d/0x7b0 [btrfs] open_ctree+0x2054/0x2660 [btrfs] btrfs_mount+0xd36/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 btrfs_mount+0x18c/0xf90 [btrfs] mount_fs+0x3a/0x160 vfs_kern_mount+0x66/0x150 do_mount+0x1c1/0xcc0 SyS_mount+0x7e/0xd0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 } ... key at: [] __key.59101+0x0/0xfffffffffff9ab78 [btrfs] ... acquired at: find_free_extent+0xcb4/0x12d0 [btrfs] btrfs_reserve_extent+0xd8/0x170 [btrfs] btrfs_alloc_tree_block+0x12f/0x4c0 [btrfs] __btrfs_cow_block+0x110/0x5b0 [btrfs] btrfs_cow_block+0xd7/0x290 [btrfs] btrfs_search_slot+0x1f6/0x960 [btrfs] btrfs_lookup_inode+0x2a/0x90 [btrfs] __btrfs_update_delayed_inode+0x65/0x210 [btrfs] btrfs_commit_inode_delayed_inode+0x121/0x130 [btrfs] btrfs_evict_inode+0x3fe/0x6a0 [btrfs] evict+0xc4/0x190 __dentry_kill+0xbf/0x170 dput+0x2ae/0x2f0 SyS_rename+0x2a6/0x3b0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 -> (&delayed_node->mutex){+.+.-.} ops: 5580204 { HARDIRQ-ON-W at: __mutex_lock+0x4e/0x8c0 btrfs_delayed_update_inode+0x46/0x6e0 [btrfs] btrfs_update_inode+0x83/0x110 [btrfs] btrfs_dirty_inode+0x62/0xe0 [btrfs] touch_atime+0x8c/0xb0 do_generic_file_read+0x818/0xb10 __vfs_read+0xdc/0x150 vfs_read+0x8a/0x130 SyS_read+0x45/0xa0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 SOFTIRQ-ON-W at: __mutex_lock+0x4e/0x8c0 btrfs_delayed_update_inode+0x46/0x6e0 [btrfs] btrfs_update_inode+0x83/0x110 [btrfs] btrfs_dirty_inode+0x62/0xe0 [btrfs] touch_atime+0x8c/0xb0 do_generic_file_read+0x818/0xb10 __vfs_read+0xdc/0x150 vfs_read+0x8a/0x130 SyS_read+0x45/0xa0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 IN-RECLAIM_FS-W at: __mutex_lock+0x4e/0x8c0 __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs] btrfs_evict_inode+0x22c/0x6a0 [btrfs] evict+0xc4/0x190 dispose_list+0x35/0x50 prune_icache_sb+0x42/0x50 super_cache_scan+0x139/0x190 shrink_slab+0x262/0x5b0 shrink_node+0x2eb/0x2f0 kswapd+0x2eb/0x890 kthread+0x102/0x140 ret_from_fork+0x3a/0x50 INITIAL USE at: __mutex_lock+0x4e/0x8c0 btrfs_delayed_update_inode+0x46/0x6e0 [btrfs] btrfs_update_inode+0x83/0x110 [btrfs] btrfs_dirty_inode+0x62/0xe0 [btrfs] touch_atime+0x8c/0xb0 do_generic_file_read+0x818/0xb10 __vfs_read+0xdc/0x150 vfs_read+0x8a/0x130 SyS_read+0x45/0xa0 do_syscall_64+0x79/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 } ... key at: [] __key.56935+0x0/0xfffffffffff96b78 [btrfs] ... acquired at: __lock_acquire+0x264/0x11c0 lock_acquire+0xbd/0x1e0 __mutex_lock+0x4e/0x8c0 __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs] btrfs_evict_inode+0x22c/0x6a0 [btrfs] evict+0xc4/0x190 dispose_list+0x35/0x50 prune_icache_sb+0x42/0x50 super_cache_scan+0x139/0x190 shrink_slab+0x262/0x5b0 shrink_node+0x2eb/0x2f0 kswapd+0x2eb/0x890 kthread+0x102/0x140 ret_from_fork+0x3a/0x50 stack backtrace: CPU: 1 PID: 50 Comm: kswapd0 Tainted: G W 4.12.14-kvmsmall #8 SLE15 (unreleased) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0x78/0xb7 print_irq_inversion_bug.part.38+0x19f/0x1aa check_usage_forwards+0x102/0x120 ? ret_from_fork+0x3a/0x50 ? check_usage_backwards+0x110/0x110 mark_lock+0x16c/0x270 __lock_acquire+0x264/0x11c0 ? pagevec_lookup_entries+0x1a/0x30 ? truncate_inode_pages_range+0x2b3/0x7f0 lock_acquire+0xbd/0x1e0 ? __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs] __mutex_lock+0x4e/0x8c0 ? __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs] ? __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs] ? btrfs_evict_inode+0x1f6/0x6a0 [btrfs] __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs] btrfs_evict_inode+0x22c/0x6a0 [btrfs] evict+0xc4/0x190 dispose_list+0x35/0x50 prune_icache_sb+0x42/0x50 super_cache_scan+0x139/0x190 shrink_slab+0x262/0x5b0 shrink_node+0x2eb/0x2f0 kswapd+0x2eb/0x890 kthread+0x102/0x140 ? mem_cgroup_shrink_node+0x2c0/0x2c0 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x3a/0x50 Signed-off-by: Jeff Mahoney Reviewed-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 92efba91a792a942d01014760750ad0013d30cb2 Author: Filipe Manana Date: Mon Mar 26 23:59:12 2018 +0100 Btrfs: fix copy_items() return value when logging an inode [ Upstream commit 8434ec46c6e3232cebc25a910363b29f5c617820 ] When logging an inode, at tree-log.c:copy_items(), if we call btrfs_next_leaf() at the loop which checks for the need to log holes, we need to make sure copy_items() returns the value 1 to its caller and not 0 (on success). This is because the path the caller passed was released and is now different from what is was before, and the caller expects a return value of 0 to mean both success and that the path has not changed, while a return value of 1 means both success and signals the caller that it can not reuse the path, it has to perform another tree search. Even though this is a case that should not be triggered on normal circumstances or very rare at least, its consequences can be very unpredictable (especially when replaying a log tree). Fixes: 16e7549f045d ("Btrfs: incompatible format change to remove hole extents") Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d7255626a0823ffc6d88d61faa67b65324ae03cc Author: Qu Wenruo Date: Tue Mar 27 20:44:18 2018 +0800 btrfs: tests/qgroup: Fix wrong tree backref level [ Upstream commit 3c0efdf03b2d127f0e40e30db4e7aa0429b1b79a ] The extent tree of the test fs is like the following: BTRFS info (device (null)): leaf 16327509003777336587 total ptrs 1 free space 3919 item 0 key (4096 168 4096) itemoff 3944 itemsize 51 extent refs 1 gen 1 flags 2 tree block key (68719476736 0 0) level 1 ^^^^^^^ ref#0: tree block backref root 5 And it's using an empty tree for fs tree, so there is no way that its level can be 1. For REAL (created by mkfs) fs tree backref with no skinny metadata, the result should look like: item 3 key (30408704 EXTENT_ITEM 4096) itemoff 3845 itemsize 51 refs 1 gen 4 flags TREE_BLOCK tree block key (256 INODE_ITEM 0) level 0 ^^^^^^^ tree block backref root 5 Fix the level to 0, so it won't break later tree level checker. Fixes: faa2dbf004e8 ("Btrfs: add sanity tests for new qgroup accounting code") Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27a913cc91773b099a5c264ab1a701e0d883ea2c Author: Nicholas Piggin Date: Tue Mar 27 01:01:16 2018 +1000 powerpc/64s: sreset panic if there is no debugger or crash dump handlers [ Upstream commit d40b6768e45bd9213139b2d91d30c7692b6007b1 ] system_reset_exception does most of its own crash handling now, invoking the debugger or crash dumps if they are registered. If not, then it goes through to die() to print stack traces, and then is supposed to panic (according to comments). However after die() prints oopses, it does its own handling which doesn't allow system_reset_exception to panic (e.g., it may just kill the current process). This patch causes sreset exceptions to return from die after it prints messages but before acting. This also stops die from invoking the debugger on 0x100 crashes. system_reset_exception similarly calls the debugger. It had been thought this was harmless (because if the debugger was disabled, neither call would fire, and if it was enabled the first call would return). However in some cases like xmon 'X' command, the debugger returns 0, which currently causes it to be entered again (first in system_reset_exception, then in die), which is confusing. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 305f25c1ed53c1458b3049afc0979bc23ba5d55a Author: Florian Fainelli Date: Sun Apr 1 10:26:29 2018 -0700 net: bgmac: Correctly annotate register space [ Upstream commit 16a1c0646e55c3345bce8e4edfc06ad119d27c04 ] All the members: base, idm_base and nicpm_base should be annotated with __iomem since they are pointers to register space. This fixes a bunch of sparse reported warnings. Fixes: f6a95a24957a ("net: ethernet: bgmac: Add platform device support") Fixes: dd5c5d037f5e ("net: ethernet: bgmac: add NS2 support") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 435290f7a40a2bf033616309137b92cf0c61015d Author: Florian Fainelli Date: Sun Apr 1 10:26:30 2018 -0700 net: bgmac: Fix endian access in bgmac_dma_tx_ring_free() [ Upstream commit 60d6e6f0b9e422dd01aeda39257ee0428e5e2a3f ] bgmac_dma_tx_ring_free() assigns the ctl1 word which is a litle endian 32-bit word without using proper accessors, fix this, and because a length cannot be negative, use unsigned int while at it. Fixes: 9cde94506eac ("bgmac: implement scatter/gather support") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a6cd791d6c116c150ed7f73ef4795cb3110d20a Author: David S. Miller Date: Tue Apr 3 08:24:35 2018 -0700 sparc64: Make atomic_xchg() an inline function rather than a macro. [ Upstream commit d13864b68e41c11e4231de90cf358658f6ecea45 ] This avoids a lot of -Wunused warnings such as: ==================== kernel/debug/debug_core.c: In function ‘kgdb_cpu_enter’: ./arch/sparc/include/asm/cmpxchg_64.h:55:22: warning: value computed is not used [-Wunused-value] #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) ./arch/sparc/include/asm/atomic_64.h:86:30: note: in expansion of macro ‘xchg’ #define atomic_xchg(v, new) (xchg(&((v)->counter), new)) ^~~~ kernel/debug/debug_core.c:508:4: note: in expansion of macro ‘atomic_xchg’ atomic_xchg(&kgdb_active, cpu); ^~~~~~~~~~~ ==================== Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 22f1bde5d1bf2950b749808483d8c929aff5d17e Author: David Howells Date: Wed Apr 4 13:41:26 2018 +0100 fscache: Fix hanging wait on page discarded by writeback [ Upstream commit 2c98425720233ae3e135add0c7e869b32913502f ] If the fscache asynchronous write operation elects to discard a page that's pending storage to the cache because the page would be over the store limit then it needs to wake the page as someone may be waiting on completion of the write. The problem is that the store limit may be updated by a different asynchronous operation - and so may miss the write - and that the store limit may not even get updated until later by the netfs. Fix the kernel hang by making fscache_write_op() mark as written any pages that are over the limit. Signed-off-by: David Howells Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6d03ff166926c7b0d70b6184bb694d684e23f6b5 Author: Alexander Graf Date: Wed Apr 4 00:19:35 2018 +0200 lan78xx: Connect phy early [ Upstream commit 92571a1aae40d291158d16e7142637908220f470 ] When using wicked with a lan78xx device attached to the system, we end up with ethtool commands issued on the device before an ifup got issued. That lead to the following crash: Unable to handle kernel NULL pointer dereference at virtual address 0000039c pgd = ffff800035b30000 [0000039c] *pgd=0000000000000000 Internal error: Oops: 96000004 [#1] SMP Modules linked in: [...] Supported: Yes CPU: 3 PID: 638 Comm: wickedd Tainted: G E 4.12.14-0-default #1 Hardware name: raspberrypi rpi/rpi, BIOS 2018.03-rc2 02/21/2018 task: ffff800035e74180 task.stack: ffff800036718000 PC is at phy_ethtool_ksettings_get+0x20/0x98 LR is at lan78xx_get_link_ksettings+0x44/0x60 [lan78xx] pc : [] lr : [] pstate: 20000005 sp : ffff80003671bb20 x29: ffff80003671bb20 x28: ffff800035e74180 x27: ffff000008912000 x26: 000000000000001d x25: 0000000000000124 x24: ffff000008f74d00 x23: 0000004000114809 x22: 0000000000000000 x21: ffff80003671bbd0 x20: 0000000000000000 x19: ffff80003671bbd0 x18: 000000000000040d x17: 0000000000000001 x16: 0000000000000000 x15: 0000000000000000 x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000020 x11: 0101010101010101 x10: fefefefefefefeff x9 : 7f7f7f7f7f7f7f7f x8 : fefefeff31677364 x7 : 0000000080808080 x6 : ffff80003671bc9c x5 : ffff80003671b9f8 x4 : ffff80002c296190 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff80003671bbd0 x0 : ffff80003671bc00 Process wickedd (pid: 638, stack limit = 0xffff800036718000) Call trace: Exception stack(0xffff80003671b9e0 to 0xffff80003671bb20) b9e0: ffff80003671bc00 ffff80003671bbd0 0000000000000000 0000000000000000 ba00: ffff80002c296190 ffff80003671b9f8 ffff80003671bc9c 0000000080808080 ba20: fefefeff31677364 7f7f7f7f7f7f7f7f fefefefefefefeff 0101010101010101 ba40: 0000000000000020 0000000000000000 ffffffffffffffff 0000000000000000 ba60: 0000000000000000 0000000000000001 000000000000040d ffff80003671bbd0 ba80: 0000000000000000 ffff80003671bbd0 0000000000000000 0000004000114809 baa0: ffff000008f74d00 0000000000000124 000000000000001d ffff000008912000 bac0: ffff800035e74180 ffff80003671bb20 ffff000000dcca84 ffff80003671bb20 bae0: ffff0000086f7f30 0000000020000005 ffff80002c296000 ffff800035223900 bb00: 0000ffffffffffff 0000000000000000 ffff80003671bb20 ffff0000086f7f30 [] phy_ethtool_ksettings_get+0x20/0x98 [] lan78xx_get_link_ksettings+0x44/0x60 [lan78xx] [] ethtool_get_settings+0x68/0x210 [] dev_ethtool+0x214/0x2180 [] dev_ioctl+0x400/0x630 [] sock_do_ioctl+0x70/0x88 [] sock_ioctl+0x208/0x368 [] do_vfs_ioctl+0xb0/0x848 [] SyS_ioctl+0x8c/0xa8 Exception stack(0xffff80003671bec0 to 0xffff80003671c000) bec0: 0000000000000009 0000000000008946 0000fffff4e841d0 0000aa0032687465 bee0: 0000aaaafa2319d4 0000fffff4e841d4 0000000032687465 0000000032687465 bf00: 000000000000001d 7f7fff7f7f7f7f7f 72606b622e71ff4c 7f7f7f7f7f7f7f7f bf20: 0101010101010101 0000000000000020 ffffffffffffffff 0000ffff7f510c68 bf40: 0000ffff7f6a9d18 0000ffff7f44ce30 000000000000040d 0000ffff7f6f98f0 bf60: 0000fffff4e842c0 0000000000000001 0000aaaafa2c2e00 0000ffff7f6ab000 bf80: 0000fffff4e842c0 0000ffff7f62a000 0000aaaafa2b9f20 0000aaaafa2c2e00 bfa0: 0000fffff4e84818 0000fffff4e841a0 0000ffff7f5ad0cc 0000fffff4e841a0 bfc0: 0000ffff7f44ce3c 0000000080000000 0000000000000009 000000000000001d bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 The culprit is quite simple: The driver tries to access the phy left and right, but only actually has a working reference to it when the device is up. The fix thus is quite simple too: Get a reference to the phy on probe already and keep it even when the device is going down. With this patch applied, I can successfully run wicked on my system and bring the interface up and down as many times as I want, without getting NULL pointer dereferences in between. Signed-off-by: Alexander Graf Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 80b8f3da4912b58bea729a37328af07e86cb8f0f Author: Sean Christopherson Date: Fri Mar 23 09:34:00 2018 -0700 KVM: VMX: raise internal error for exception during invalid protected mode state [ Upstream commit add5ff7a216ee545a214013f26d1ef2f44a9c9f8 ] Exit to userspace with KVM_INTERNAL_ERROR_EMULATION if we encounter an exception in Protected Mode while emulating guest due to invalid guest state. Unlike Big RM, KVM doesn't support emulating exceptions in PM, i.e. PM exceptions are always injected via the VMCS. Because we will never do VMRESUME due to emulation_required, the exception is never realized and we'll keep emulating the faulting instruction over and over until we receive a signal. Exit to userspace iff there is a pending exception, i.e. don't exit simply on a requested event. The purpose of this check and exit is to aid in debugging a guest that is in all likelihood already doomed. Invalid guest state in PM is extremely limited in normal operation, e.g. it generally only occurs for a few instructions early in BIOS, and any exception at this time is all but guaranteed to be fatal. Non-vectored interrupts, e.g. INIT, SIPI and SMI, can be cleanly handled/emulated, while checking for vectored interrupts, e.g. INTR and NMI, without hitting false positives would add a fair amount of complexity for almost no benefit (getting hit by lightning seems more likely than encountering this specific scenario). Add a WARN_ON_ONCE to vmx_queue_exception() if we try to inject an exception via the VMCS and emulation_required is true. Signed-off-by: Sean Christopherson Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fd97bbca67fc03dfc3c35c5ed3122e20a86c50a5 Author: Sai Praneeth Date: Wed Apr 4 12:34:19 2018 -0700 x86/mm: Fix bogus warning during EFI bootup, use boot_cpu_has() instead of this_cpu_has() in build_cr3_noflush() [ Upstream commit 162ee5a8ab49be40d253f90e94aef712470a3a24 ] Linus reported the following boot warning: WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/tlbflush.h:134 load_new_mm_cr3+0x114/0x170 [...] Call Trace: switch_mm_irqs_off+0x267/0x590 switch_mm+0xe/0x20 efi_switch_mm+0x3e/0x50 efi_enter_virtual_mode+0x43f/0x4da start_kernel+0x3bf/0x458 secondary_startup_64+0xa5/0xb0 ... after merging: 03781e40890c: x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3 When the platform supports PCID and if CONFIG_DEBUG_VM=y is enabled, build_cr3_noflush() (called via switch_mm()) does a sanity check to see if X86_FEATURE_PCID is set. Presently, build_cr3_noflush() uses "this_cpu_has(X86_FEATURE_PCID)" to perform the check but this_cpu_has() works only after SMP is initialized (i.e. per cpu cpu_info's should be populated) and this happens to be very late in the boot process (during rest_init()). As efi_runtime_services() are called during (early) kernel boot time and run time, modify build_cr3_noflush() to use boot_cpu_has() all the time. As suggested by Dave Hansen, this should be OK because all CPU's have same capabilities on x86. With this change the warning is fixed. ( Dave also suggested that we put a warning in this_cpu_has() if it's used early in the boot process. This is still work in progress as it affects MCE. ) Reported-by: Linus Torvalds Signed-off-by: Sai Praneeth Prakhya Cc: Andrew Morton Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Dave Hansen Cc: Lee Chun-Yi Cc: Matt Fleming Cc: Michael S. Tsirkin Cc: Peter Zijlstra Cc: Peter Zijlstra Cc: Ravi Shankar Cc: Ricardo Neri Cc: Thomas Gleixner Cc: Tony Luck Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1522870459-7432-1-git-send-email-sai.praneeth.prakhya@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3aeaeecda057abae909e2f15f2ec433cb032944f Author: Davidlohr Bueso Date: Mon Apr 2 09:49:54 2018 -0700 sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning [ Upstream commit d29a20645d5e929aa7e8616f28e5d8e1c49263ec ] While running rt-tests' pi_stress program I got the following splat: rq->clock_update_flags < RQCF_ACT_SKIP WARNING: CPU: 27 PID: 0 at kernel/sched/sched.h:960 assert_clock_updated.isra.38.part.39+0x13/0x20 [...] enqueue_top_rt_rq+0xf4/0x150 ? cpufreq_dbs_governor_start+0x170/0x170 sched_rt_rq_enqueue+0x65/0x80 sched_rt_period_timer+0x156/0x360 ? sched_rt_rq_enqueue+0x80/0x80 __hrtimer_run_queues+0xfa/0x260 hrtimer_interrupt+0xcb/0x220 smp_apic_timer_interrupt+0x62/0x120 apic_timer_interrupt+0xf/0x20 [...] do_idle+0x183/0x1e0 cpu_startup_entry+0x5f/0x70 start_secondary+0x192/0x1d0 secondary_startup_64+0xa5/0xb0 We can get rid of it be the "traditional" means of adding an update_rq_clock() call after acquiring the rq->lock in do_sched_rt_period_timer(). The case for the RT task throttling (which this workload also hits) can be ignored in that the skip_update call is actually bogus and quite the contrary (the request bits are removed/reverted). By setting RQCF_UPDATED we really don't care if the skip is happening or not and will therefore make the assert_clock_updated() check happy. Signed-off-by: Davidlohr Bueso Reviewed-by: Matt Fleming Acked-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Mike Galbraith Cc: Thomas Gleixner Cc: dave@stgolabs.net Cc: linux-kernel@vger.kernel.org Cc: rostedt@goodmis.org Link: http://lkml.kernel.org/r/20180402164954.16255-1-dave@stgolabs.net Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit be6a5ad51a53a467fe9f5abac823143483cde392 Author: Nicholas Piggin Date: Thu Apr 5 16:10:00 2018 +1000 powerpc/64s/idle: Fix restore of AMOR on POWER9 after deep sleep [ Upstream commit c1b25a17d24925b0961c319cfc3fd7e1dc778914 ] POWER8 restores AMOR when waking from deep sleep, but POWER9 does not, because it does not go through the subcore restore. Have POWER9 restore it in core restore. Fixes: ee97b6b99f42 ("powerpc/mm/radix: Setup AMOR in HV mode to allow key 0") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 839c27f7137630ead3ad7460a2573632ebaff968 Author: Jun Piao Date: Thu Apr 5 16:18:48 2018 -0700 ocfs2/dlm: don't handle migrate lockres if already in shutdown [ Upstream commit bb34f24c7d2c98d0c81838a7700e6068325b17a0 ] We should not handle migrate lockres if we are already in 'DLM_CTXT_IN_SHUTDOWN', as that will cause lockres remains after leaving dlm domain. At last other nodes will get stuck into infinite loop when requsting lock from us. The problem is caused by concurrency umount between nodes. Before receiveing N1's DLM_BEGIN_EXIT_DOMAIN_MSG, N2 has picked up N1 as the migrate target. So N2 will continue sending lockres to N1 even though N1 has left domain. N1 N2 (owner) touch file access the file, and get pr lock begin leave domain and pick up N1 as new owner begin leave domain and migrate all lockres done begin migrate lockres to N1 end leave domain, but the lockres left unexpectedly, because migrate task has passed [piaojun@huawei.com: v3] Link: http://lkml.kernel.org/r/5A9CBD19.5020107@huawei.com Link: http://lkml.kernel.org/r/5A99F028.2090902@huawei.com Signed-off-by: Jun Piao Reviewed-by: Yiwen Jiang Reviewed-by: Joseph Qi Reviewed-by: Changwei Ge Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9ebe297713af6ba8f014f6bece853a16bd2c40f8 Author: Mikhail Malygin Date: Mon Apr 2 12:26:59 2018 +0300 IB/rxe: Fix for oops in rxe_register_device on ppc64le arch [ Upstream commit efc365e7290d040fbd43f60b0e97653489a739d4 ] On ppc64le arch rxe_add command causes oops in kernel log: [ 92.495140] Oops: Kernel access of bad area, sig: 11 [#1] [ 92.499710] SMP NR_CPUS=2048 NUMA pSeries [ 92.499792] Modules linked in: ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E) nf_conntrack_netlink(E) nfnetlink(E) xfrm_user(E) iptable _nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) xt_addrtype(E) iptable_filter(E) ip_tables(E) xt_conntrack(E) x_tables(E) nf_nat(E) nf_conntrack(E) br_netfilter(E) bridge(E) stp(E) llc(E) overlay(E) af_packet(E) rpcrdma(E) ib_isert(E) iscsi_target_mod(E) i b_iser(E) libiscsi(E) ib_srpt(E) target_core_mod(E) ib_srp(E) ib_ipoib(E) rdma_ucm(E) ib_ucm(E) ib_uverbs(E) ib_umad(E) bochs_drm(E) tt m(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) drm(E) agpgart(E) virtio_rng(E) virtio_console(E) rtc_ generic(E) dm_ec(OEN) ttln_rdma(OEN) rdma_cm(E) configfs(E) iw_cm(E) ib_cm(E) rdma_rxe(E) ip6_udp_tunnel(E) udp_tunnel(E) ib_core(E) ql a2xxx(E) [ 92.499832] scsi_transport_fc(E) nvme_fc(E) nvme_fabrics(E) nvme_core(E) ipmi_watchdog(E) ipmi_ssif(E) ipmi_poweroff(E) ipmi_powernv(EX) ipmi_devintf(E) ipmi_msghandler(E) dummy(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_service_time(E) scsi_transport_iscsi(E) sd_mod(E) sr_mod(E) cdrom(E) hid_generic(E) usbhid(E) virtio_blk(E) virtio_scsi(E) virtio_net(E) ibmvscsi(EX) scsi_transport_srp(E) xhci_pci(E) xhci_hcd(E) usbcore(E) usb_common(E) virtio_pci(E) virtio_ring(E) virtio(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E) [ 92.499834] Supported: No, Unsupported modules are loaded [ 92.499839] CPU: 3 PID: 5576 Comm: sh Tainted: G OE NX 4.4.120-ttln.17-default #1 [ 92.499841] task: c0000000afe8a490 ti: c0000000beba8000 task.ti: c0000000beba8000 [ 92.499842] NIP: c00000000008ba3c LR: c000000000027644 CTR: c00000000008ba10 [ 92.499844] REGS: c0000000bebab750 TRAP: 0300 Tainted: G OE NX (4.4.120-ttln.17-default) [ 92.499850] MSR: 8000000000009033 CR: 28424428 XER: 20000000 [ 92.499871] CFAR: 0000000000002424 DAR: 0000000000000208 DSISR: 40000000 SOFTE: 1 GPR00: c000000000027644 c0000000bebab9d0 c000000000f09700 0000000000000000 GPR04: d0000000043d7192 0000000000000002 000000000000001a fffffffffffffffe GPR08: 000000000000009c c00000000008ba10 d0000000043e5848 d0000000043d3828 GPR12: c00000000008ba10 c000000007a02400 0000000010062e38 0000010020388860 GPR16: 0000000000000000 0000000000000000 00000100203885f0 00000000100f6c98 GPR20: c0000000b3f1fcc0 c0000000b3f1fc48 c0000000b3f1fbd0 c0000000b3f1fb58 GPR24: c0000000b3f1fae0 c0000000b3f1fa68 00000000000005dc c0000000b3f1f9f0 GPR28: d0000000043e5848 c0000000b3f1f900 c0000000b3f1f320 c0000000b3f1f000 [ 92.499881] NIP [c00000000008ba3c] dma_get_required_mask_pSeriesLP+0x2c/0x1a0 [ 92.499885] LR [c000000000027644] dma_get_required_mask+0x44/0xac [ 92.499886] Call Trace: [ 92.499891] [c0000000bebab9d0] [c0000000bebaba30] 0xc0000000bebaba30 (unreliable) [ 92.499894] [c0000000bebaba10] [c000000000027644] dma_get_required_mask+0x44/0xac [ 92.499904] [c0000000bebaba30] [d0000000043cb4b4] rxe_register_device+0xc4/0x430 [rdma_rxe] [ 92.499910] [c0000000bebabab0] [d0000000043c06c8] rxe_add+0x448/0x4e0 [rdma_rxe] [ 92.499915] [c0000000bebabb30] [d0000000043d28dc] rxe_net_add+0x4c/0xf0 [rdma_rxe] [ 92.499921] [c0000000bebabb60] [d0000000043d305c] rxe_param_set_add+0x6c/0x1ac [rdma_rxe] [ 92.499924] [c0000000bebabbf0] [c0000000000e78c0] param_attr_store+0xa0/0x180 [ 92.499927] [c0000000bebabc70] [c0000000000e6448] module_attr_store+0x48/0x70 [ 92.499932] [c0000000bebabc90] [c000000000391f60] sysfs_kf_write+0x70/0xb0 [ 92.499935] [c0000000bebabcb0] [c000000000390f1c] kernfs_fop_write+0x18c/0x1e0 [ 92.499939] [c0000000bebabd00] [c0000000002e22ac] __vfs_write+0x4c/0x1d0 [ 92.499942] [c0000000bebabd90] [c0000000002e2f94] vfs_write+0xc4/0x200 [ 92.499945] [c0000000bebabde0] [c0000000002e488c] SyS_write+0x6c/0x110 [ 92.499948] [c0000000bebabe30] [c000000000009384] system_call+0x38/0xe4 [ 92.499949] Instruction dump: [ 92.499954] 4e800020 3c4c00e8 3842dcf0 7c0802a6 f8010010 60000000 7c0802a6 fba1ffe8 [ 92.499958] fbc1fff0 fbe1fff8 f8010010 f821ffc1 7c7e1b78 2fa90000 419e0078 [ 92.499962] ---[ end trace bed077e15eb420cf ]--- It fails in dma_get_required_mask, that has ppc-specific implementation, and fail if provided device argument is NULL Signed-off-by: Mikhail Malygin Reviewed-by: Yonatan Cohen Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 370b3353f4f8090bfaf332908ef8c05c9f2f8fc8 Author: Nikolay Borisov Date: Thu Apr 5 10:40:15 2018 +0300 btrfs: Fix possible softlock on single core machines [ Upstream commit 1e1c50a929bc9e49bc3f9935b92450d9e69f8158 ] do_chunk_alloc implements a loop checking whether there is a pending chunk allocation and if so causes the caller do loop. Generally this loop is executed only once, however testing with btrfs/072 on a single core vm machines uncovered an extreme case where the system could loop indefinitely. This is due to a missing cond_resched when loop which doesn't give a chance to the previous chunk allocator finish its job. The fix is to simply add the missing cond_resched. Fixes: 6d74119f1a3e ("Btrfs: avoid taking the chunk_mutex in do_chunk_alloc") Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit acfd8e886566bd92d0f07d1938e0eaf461a97762 Author: Liu Bo Date: Tue Apr 3 01:59:47 2018 +0800 Btrfs: fix NULL pointer dereference in log_dir_items [ Upstream commit 80c0b4210a963e31529e15bf90519708ec947596 ] 0, 1 and <0 can be returned by btrfs_next_leaf(), and when <0 is returned, path->nodes[0] could be NULL, log_dir_items lacks such a check for <0 and we may run into a null pointer dereference panic. Fixes: e02119d5a7b4 ("Btrfs: Add a write ahead tree log to optimize synchronous operations") Reviewed-by: Nikolay Borisov Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit afef64b10877479b2f34c915aa0c12ff333ec3c7 Author: Liu Bo Date: Tue Apr 3 01:59:48 2018 +0800 Btrfs: bail out on error during replay_dir_deletes [ Upstream commit b98def7ca6e152ee55e36863dddf6f41f12d1dc6 ] If errors were returned by btrfs_next_leaf(), replay_dir_deletes needs to bail out, otherwise @ret would be forced to be 0 after 'break;' and the caller won't be aware of it. Fixes: e02119d5a7b4 ("Btrfs: Add a write ahead tree log to optimize synchronous operations") Reviewed-by: Nikolay Borisov Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5ade3c9618f65d650eb70177beabff87822d015a Author: Yang Shi Date: Thu Apr 5 16:22:35 2018 -0700 mm: thp: fix potential clearing to referenced flag in page_idle_clear_pte_refs_one() [ Upstream commit f0849ac0b8e072073ec5fcc7fadd05a77434364e ] For PTE-mapped THP, the compound THP has not been split to normal 4K pages yet, the whole THP is considered referenced if any one of sub page is referenced. When walking PTE-mapped THP by pvmw, all relevant PTEs will be checked to retrieve referenced bit. But, the current code just returns the result of the last PTE. If the last PTE has not referenced, the referenced flag will be cleared. Just set referenced when ptep{pmdp}_clear_young_notify() returns true. Link: http://lkml.kernel.org/r/1518212451-87134-1-git-send-email-yang.shi@linux.alibaba.com Signed-off-by: Yang Shi Reported-by: Gang Deng Suggested-by: Kirill A. Shutemov Reviewed-by: Andrew Morton Cc: "Kirill A. Shutemov" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d700626fb57dab12b58b57ea541592c21f87ee8 Author: Huang Ying Date: Thu Apr 5 16:23:20 2018 -0700 mm: fix races between address_space dereference and free in page_evicatable [ Upstream commit e92bb4dd9673945179b1fc738c9817dd91bfb629 ] When page_mapping() is called and the mapping is dereferenced in page_evicatable() through shrink_active_list(), it is possible for the inode to be truncated and the embedded address space to be freed at the same time. This may lead to the following race. CPU1 CPU2 truncate(inode) shrink_active_list() ... page_evictable(page) truncate_inode_page(mapping, page); delete_from_page_cache(page) spin_lock_irqsave(&mapping->tree_lock, flags); __delete_from_page_cache(page, NULL) page_cache_tree_delete(..) ... mapping = page_mapping(page); page->mapping = NULL; ... spin_unlock_irqrestore(&mapping->tree_lock, flags); page_cache_free_page(mapping, page) put_page(page) if (put_page_testzero(page)) -> false - inode now has no pages and can be freed including embedded address_space mapping_unevictable(mapping) test_bit(AS_UNEVICTABLE, &mapping->flags); - we've dereferenced mapping which is potentially already free. Similar race exists between swap cache freeing and page_evicatable() too. The address_space in inode and swap cache will be freed after a RCU grace period. So the races are fixed via enclosing the page_mapping() and address_space usage in rcu_read_lock/unlock(). Some comments are added in code to make it clear what is protected by the RCU read lock. Link: http://lkml.kernel.org/r/20180212081227.1940-1-ying.huang@intel.com Signed-off-by: "Huang, Ying" Reviewed-by: Jan Kara Reviewed-by: Andrew Morton Cc: Mel Gorman Cc: Minchan Kim Cc: "Huang, Ying" Cc: Johannes Weiner Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 763111d9f337140ce1976b66140f93c791122a26 Author: Claudio Imbrenda Date: Thu Apr 5 16:25:41 2018 -0700 mm/ksm: fix interaction with THP [ Upstream commit 77da2ba0648a4fd52e5ff97b8b2b8dd312aec4b0 ] This patch fixes a corner case for KSM. When two pages belong or belonged to the same transparent hugepage, and they should be merged, KSM fails to split the page, and therefore no merging happens. This bug can be reproduced by: * making sure ksm is running (in case disabling ksmtuned) * enabling transparent hugepages * allocating a THP-aligned 1-THP-sized buffer e.g. on amd64: posix_memalign(&p, 1<<21, 1<<21) * filling it with the same values e.g. memset(p, 42, 1<<21) * performing madvise to make it mergeable e.g. madvise(p, 1<<21, MADV_MERGEABLE) * waiting for KSM to perform a few scans The expected outcome is that the all the pages get merged (1 shared and the rest sharing); the actual outcome is that no pages get merged (1 unshared and the rest volatile) The reason of this behaviour is that we increase the reference count once for both pages we want to merge, but if they belong to the same hugepage (or compound page), the reference counter used in both cases is the one of the head of the compound page. This means that split_huge_page will find a value of the reference counter too high and will fail. This patch solves this problem by testing if the two pages to merge belong to the same hugepage when attempting to merge them. If so, the hugepage is split safely. This means that the hugepage is not split if not necessary. Link: http://lkml.kernel.org/r/1521548069-24758-1-git-send-email-imbrenda@linux.vnet.ibm.com Signed-off-by: Claudio Imbrenda Co-authored-by: Gerald Schaefer Reviewed-by: Andrew Morton Cc: Andrea Arcangeli Cc: Minchan Kim Cc: Kirill A. Shutemov Cc: Hugh Dickins Cc: Christian Borntraeger Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 378a1e49f9d1279f8f4bcd2bc3283f2b733dc15f Author: Thomas Falcon Date: Fri Apr 6 18:37:03 2018 -0500 ibmvnic: Zero used TX descriptor counter on reset [ Upstream commit 41f714672f93608751dbd2fa2291d476a8ff0150 ] The counter that tracks used TX descriptors pending completion needs to be zeroed as part of a device reset. This change fixes a bug causing transmit queues to be stopped unnecessarily and in some cases a transmit queue stall and timeout reset. If the counter is not reset, the remaining descriptors will not be "removed", effectively reducing queue capacity. If the queue is over half full, it will cause the queue to stall if stopped. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d04e5e72dfe925f0a72a755bea7ce2665ee1e788 Author: Esben Haabendal Date: Sun Apr 8 22:17:01 2018 +0200 dp83640: Ensure against premature access to PHY registers after reset [ Upstream commit 76327a35caabd1a932e83d6a42b967aa08584e5d ] The datasheet specifies a 3uS pause after performing a software reset. The default implementation of genphy_soft_reset() does not provide this, so implement soft_reset with the needed pause. Signed-off-by: Esben Haabendal Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4be06bc0916d4fdffadf9a62ff88d119b0702697 Author: Sandipan Das Date: Wed Apr 4 23:34:18 2018 +0530 perf clang: Add support for recent clang versions [ Upstream commit 7854e499f33fd9c7e63288692ffb754d9b1d02fd ] The clang API calls used by perf have changed in recent releases and builds succeed with libclang-3.9 only. This introduces compatibility with libclang-4.0 and above. Without this patch, we will see the following compilation errors with libclang-4.0+: util/c++/clang.cpp: In function ‘clang::CompilerInvocation* perf::createCompilerInvocation(llvm::opt::ArgStringList, llvm::StringRef&, clang::DiagnosticsEngine&)’: util/c++/clang.cpp:62:33: error: ‘IK_C’ was not declared in this scope Opts.Inputs.emplace_back(Path, IK_C); ^~~~ util/c++/clang.cpp: In function ‘std::unique_ptr perf::getModuleFromSource(llvm::opt::ArgStringList, llvm::StringRef, llvm::IntrusiveRefCntPtr)’: util/c++/clang.cpp:75:26: error: no matching function for call to ‘clang::CompilerInstance::setInvocation(clang::CompilerInvocation*)’ Clang.setInvocation(&*CI); ^ In file included from util/c++/clang.cpp:14:0: /usr/include/clang/Frontend/CompilerInstance.h:231:8: note: candidate: void clang::CompilerInstance::setInvocation(std::shared_ptr) void setInvocation(std::shared_ptr Value); ^~~~~~~~~~~~~ Committer testing: Tested on Fedora 27 after installing the clang-devel and llvm-devel packages, versions: # rpm -qa | egrep llvm\|clang llvm-5.0.1-6.fc27.x86_64 clang-libs-5.0.1-5.fc27.x86_64 clang-5.0.1-5.fc27.x86_64 clang-tools-extra-5.0.1-5.fc27.x86_64 llvm-libs-5.0.1-6.fc27.x86_64 llvm-devel-5.0.1-6.fc27.x86_64 clang-devel-5.0.1-5.fc27.x86_64 # Make sure you don't have some older version lying around in /usr/local, etc, then: $ make LIBCLANGLLVM=1 -C tools/perf install-bin And in the end perf will be linked agains these libraries: # ldd ~/bin/perf | egrep -i llvm\|clang libclangAST.so.5 => /lib64/libclangAST.so.5 (0x00007f8bb2eb4000) libclangBasic.so.5 => /lib64/libclangBasic.so.5 (0x00007f8bb29e3000) libclangCodeGen.so.5 => /lib64/libclangCodeGen.so.5 (0x00007f8bb23f7000) libclangDriver.so.5 => /lib64/libclangDriver.so.5 (0x00007f8bb2060000) libclangFrontend.so.5 => /lib64/libclangFrontend.so.5 (0x00007f8bb1d06000) libclangLex.so.5 => /lib64/libclangLex.so.5 (0x00007f8bb1a3e000) libclangTooling.so.5 => /lib64/libclangTooling.so.5 (0x00007f8bb17d4000) libclangEdit.so.5 => /lib64/libclangEdit.so.5 (0x00007f8bb15c5000) libclangSema.so.5 => /lib64/libclangSema.so.5 (0x00007f8bb0cc9000) libclangAnalysis.so.5 => /lib64/libclangAnalysis.so.5 (0x00007f8bb0a23000) libclangParse.so.5 => /lib64/libclangParse.so.5 (0x00007f8bb0725000) libclangSerialization.so.5 => /lib64/libclangSerialization.so.5 (0x00007f8bb039a000) libLLVM-5.0.so => /lib64/libLLVM-5.0.so (0x00007f8bace98000) libclangASTMatchers.so.5 => /lib64/../lib64/libclangASTMatchers.so.5 (0x00007f8bab735000) libclangFormat.so.5 => /lib64/../lib64/libclangFormat.so.5 (0x00007f8bab4b2000) libclangRewrite.so.5 => /lib64/../lib64/libclangRewrite.so.5 (0x00007f8bab2a1000) libclangToolingCore.so.5 => /lib64/../lib64/libclangToolingCore.so.5 (0x00007f8bab08e000) # Signed-off-by: Sandipan Das Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Naveen N. Rao Fixes: 00b86691c77c ("perf clang: Add builtin clang support ant test case") Link: http://lkml.kernel.org/r/20180404180419.19056-2-sandipan@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ee7c28b280b8c6be717f39a7b092cf4f587e3bbe Author: Sandipan Das Date: Wed Apr 4 23:34:17 2018 +0530 perf tools: Fix perf builds with clang support [ Upstream commit c2fb54a183cfe77c6fdc9d71e2d5299c1c302a6e ] For libclang, some distro packages provide static libraries (.a) while some provide shared libraries (.so). Currently, perf code can only be linked with static libraries. This makes perf build possible for both cases. Signed-off-by: Sandipan Das Cc: Jiri Olsa Cc: Naveen N. Rao Fixes: d58ac0bf8d1e ("perf build: Add clang and llvm compile and linking support") Link: http://lkml.kernel.org/r/20180404180419.19056-1-sandipan@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6689a4c7b9ed838821c72c976896eb74457f665f Author: Anshuman Khandual Date: Thu Mar 29 11:53:37 2018 +0530 powerpc/fscr: Enable interrupts earlier before calling get_user() [ Upstream commit 709b973c844c0b4d115ac3a227a2e5a68722c912 ] The function get_user() can sleep while trying to fetch instruction from user address space and causes the following warning from the scheduler. BUG: sleeping function called from invalid context Though interrupts get enabled back but it happens bit later after get_user() is called. This change moves enabling these interrupts earlier covering the function get_user(). While at this, lets check for kernel mode and crash as this interrupt should not have been triggered from the kernel context. Signed-off-by: Anshuman Khandual Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 96fdc64d8eda887ae1a290b4f11f67a4a942d949 Author: Shunyong Yang Date: Fri Apr 6 10:43:49 2018 +0800 cpufreq: CPPC: Initialize shared perf capabilities of CPUs [ Upstream commit 8913315e9459b146e5888ab5138e10daa061b885 ] When multiple CPUs are related in one cpufreq policy, the first online CPU will be chosen by default to handle cpufreq operations. Let's take cpu0 and cpu1 as an example. When cpu0 is offline, policy->cpu will be shifted to cpu1. cpu1's perf capabilities should be initialized. Otherwise, perf capabilities are 0s and speed change can not take effect. This patch copies perf capabilities of the first online CPU to other shared CPUs when policy shared type is CPUFREQ_SHARED_TYPE_ANY. Acked-by: Viresh Kumar Signed-off-by: Shunyong Yang Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8bff7ca99fda1914baa1db377f34890969bf7f17 Author: Carlos Maiolino Date: Tue Apr 10 22:39:04 2018 -0700 Force log to disk before reading the AGF during a fstrim [ Upstream commit 8c81dd46ef3c416b3b95e3020fb90dbd44e6140b ] Forcing the log to disk after reading the agf is wrong, we might be calling xfs_log_force with XFS_LOG_SYNC with a metadata lock held. This can cause a deadlock when racing a fstrim with a filesystem shutdown. The deadlock has been identified due a miscalculation bug in device-mapper dm-thin, which returns lack of space to its users earlier than the device itself really runs out of space, changing the device-mapper volume into an error state. The problem happened while filling the filesystem with a single file, triggering the bug in device-mapper, consequently causing an IO error and shutting down the filesystem. If such file is removed, and fstrim executed before the XFS finishes the shut down process, the fstrim process will end up holding the buffer lock, and going to sleep on the cil wait queue. At this point, the shut down process will try to wake up all the threads waiting on the cil wait queue, but for this, it will try to hold the same buffer log already held my the fstrim, locking up the filesystem. Signed-off-by: Carlos Maiolino Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 28143fe3e3e20530e19557d173430818e838aec4 Author: Jens Axboe Date: Wed Apr 11 11:26:09 2018 -0600 sr: get/drop reference to device in revalidate and check_events [ Upstream commit 2d097c50212e137e7b53ffe3b37561153eeba87d ] We can't just use scsi_cd() to get the scsi_cd structure, we have to grab a live reference to the device. For both callbacks, we're not inside an open where we already hold a reference to the device. This fixes device removal/addition under concurrent device access, which otherwise could result in the below oops. NULL pointer dereference at 0000000000000010 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: sr 12:0:0:0: [sr2] scsi-1 drive scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl sr 12:0:0:0: Attached scsi CD-ROM sr2 sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc sr 12:0:0:0: Attached scsi generic sg7 type 5 igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650 Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016 RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292 RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66 RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000 RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000 FS: 00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __invalidate_device+0x48/0x60 check_disk_change+0x4c/0x60 sr_block_open+0x16/0xd0 [sr_mod] __blkdev_get+0xb9/0x450 ? iget5_locked+0x1c0/0x1e0 blkdev_get+0x11e/0x320 ? bdget+0x11d/0x150 ? _raw_spin_unlock+0xa/0x20 ? bd_acquire+0xc0/0xc0 do_dentry_open+0x1b0/0x320 ? inode_permission+0x24/0xc0 path_openat+0x4e6/0x1420 ? cpumask_any_but+0x1f/0x40 ? flush_tlb_mm_range+0xa0/0x120 do_filp_open+0x8c/0xf0 ? __seccomp_filter+0x28/0x230 ? _raw_spin_unlock+0xa/0x20 ? __handle_mm_fault+0x7d6/0x9b0 ? list_lru_add+0xa8/0xc0 ? _raw_spin_unlock+0xa/0x20 ? __alloc_fd+0xaf/0x160 ? do_sys_open+0x1a6/0x230 do_sys_open+0x1a6/0x230 do_syscall_64+0x5a/0x100 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Reviewed-by: Lee Duncan Reviewed-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3a0de65acdd98c181364c368ef99e3b4c1b1ded9 Author: Xidong Wang Date: Tue Apr 10 16:29:34 2018 -0700 z3fold: fix memory leak [ Upstream commit 1ec6995d1290bfb87cc3a51f0836c889e857cef9 ] In z3fold_create_pool(), the memory allocated by __alloc_percpu() is not released on the error path that pool->compact_wq , which holds the return value of create_singlethread_workqueue(), is NULL. This will result in a memory leak bug. [akpm@linux-foundation.org: fix oops on kzalloc() failure, check __alloc_percpu() retval] Link: http://lkml.kernel.org/r/1522803111-29209-1-git-send-email-wangxidong_97@163.com Signed-off-by: Xidong Wang Reviewed-by: Andrew Morton Cc: Vitaly Wool Cc: Mike Rapoport Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2ab7738102ad2ac77f1afafe916accff5683e9b2 Author: Tom Abraham Date: Tue Apr 10 16:29:48 2018 -0700 swap: divide-by-zero when zero length swap file on ssd [ Upstream commit a06ad633a37c64a0cd4c229fc605cee8725d376e ] Calling swapon() on a zero length swap file on SSD can lead to a divide-by-zero. Although creating such files isn't possible with mkswap and they woud be considered invalid, it would be better for the swapon code to be more robust and handle this condition gracefully (return -EINVAL). Especially since the fix is small and straightforward. To help with wear leveling on SSD, the swapon syscall calculates a random position in the swap file using modulo p->highest_bit, which is set to maxpages - 1 in read_swap_header. If the swap file is zero length, read_swap_header sets maxpages=1 and last_page=0, resulting in p->highest_bit=0 and we divide-by-zero when we modulo p->highest_bit in swapon syscall. This can be prevented by having read_swap_header return zero if last_page is zero. Link: http://lkml.kernel.org/r/5AC747C1020000A7001FA82C@prv-mh.provo.novell.com Signed-off-by: Thomas Abraham Reported-by: Reviewed-by: Andrew Morton Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9c9844d9c9d042df472dddae5a042d963cfc603f Author: Danilo Krummrich Date: Tue Apr 10 16:31:38 2018 -0700 fs/proc/proc_sysctl.c: fix potential page fault while unregistering sysctl table [ Upstream commit a0b0d1c345d0317efe594df268feb5ccc99f651e ] proc_sys_link_fill_cache() does not take currently unregistering sysctl tables into account, which might result into a page fault in sysctl_follow_link() - add a check to fix it. This bug has been present since v3.4. Link: http://lkml.kernel.org/r/20180228013506.4915-1-danilokrummrich@dk-develop.de Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between sysctl_table_sets") Signed-off-by: Danilo Krummrich Acked-by: Kees Cook Reviewed-by: Andrew Morton Cc: "Luis R . Rodriguez" Cc: "Eric W. Biederman" Cc: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 59bdc587231c5d468f76978c0cd9512740115722 Author: Dave Hansen Date: Fri Apr 6 13:55:14 2018 -0700 x86/mm: Do not forbid _PAGE_RW before init for __ro_after_init [ Upstream commit 639d6aafe437a7464399d2a77d006049053df06f ] __ro_after_init data gets stuck in the .rodata section. That's normally fine because the kernel itself manages the R/W properties. But, if we run __change_page_attr() on an area which is __ro_after_init, the .rodata checks will trigger and force the area to be immediately read-only, even if it is early-ish in boot. This caused problems when trying to clear the _PAGE_GLOBAL bit for these area in the PTI code: it cleared _PAGE_GLOBAL like I asked, but also took it up on itself to clear _PAGE_RW. The kernel then oopses the next time it wrote to a __ro_after_init data structure. To fix this, add the kernel_set_to_readonly check, just like we have for kernel text, just a few lines below in this function. Signed-off-by: Dave Hansen Acked-by: Kees Cook Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Arjan van de Ven Cc: Borislav Petkov Cc: Dan Williams Cc: David Woodhouse Cc: Greg Kroah-Hartman Cc: Hugh Dickins Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Linus Torvalds Cc: Nadav Amit Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180406205514.8D898241@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c1af6891982ead3d9e651df6ab9c2296339bd890 Author: Joerg Roedel Date: Wed Apr 11 17:24:38 2018 +0200 x86/pgtable: Don't set huge PUD/PMD on non-leaf entries [ Upstream commit e3e288121408c3abeed5af60b87b95c847143845 ] The pmd_set_huge() and pud_set_huge() functions are used from the generic ioremap() code to establish large mappings where this is possible. But the generic ioremap() code does not check whether the PMD/PUD entries are already populated with a non-leaf entry, so that any page-table pages these entries point to will be lost. Further, on x86-32 with SHARED_KERNEL_PMD=0, this causes a BUG_ON() in vmalloc_sync_one() when PMD entries are synced from swapper_pg_dir to the current page-table. This happens because the PMD entry from swapper_pg_dir was promoted to a huge-page entry while the current PGD still contains the non-leaf entry. Because both entries are present and point to a different page, the BUG_ON() triggers. This was actually triggered with pti-x32 enabled in a KVM virtual machine by the graphics driver. A real and better fix for that would be to improve the page-table handling in the generic ioremap() code. But that is out-of-scope for this patch-set and left for later work. Reported-by: David H. Gutteridge Signed-off-by: Joerg Roedel Reviewed-by: Thomas Gleixner Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: David Laight Cc: Denys Vlasenko Cc: Eduardo Valentin Cc: Greg KH Cc: Jiri Kosina Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Linus Torvalds Cc: Pavel Machek Cc: Peter Zijlstra Cc: Waiman Long Cc: Will Deacon Cc: aliguori@amazon.com Cc: daniel.gruss@iaik.tugraz.at Cc: hughd@google.com Cc: keescook@google.com Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180411152437.GC15462@8bytes.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c527ab91f021bfc3041f3a43238d79cff16e7e7f Author: Filipe Manana Date: Thu Apr 5 22:55:12 2018 +0100 Btrfs: fix loss of prealloc extents past i_size after fsync log replay [ Upstream commit 471d557afed155b85da237ec46c549f443eeb5de ] Currently if we allocate extents beyond an inode's i_size (through the fallocate system call) and then fsync the file, we log the extents but after a power failure we replay them and then immediately drop them. This behaviour happens since about 2009, commit c71bf099abdd ("Btrfs: Avoid orphan inodes cleanup while replaying log"), because it marks the inode as an orphan instead of dropping any extents beyond i_size before replaying logged extents, so after the log replay, and while the mount operation is still ongoing, we find the inode marked as an orphan and then perform a truncation (drop extents beyond the inode's i_size). Because the processing of orphan inodes is still done right after replaying the log and before the mount operation finishes, the intention of that commit does not make any sense (at least as of today). However reverting that behaviour is not enough, because we can not simply discard all extents beyond i_size and then replay logged extents, because we risk dropping extents beyond i_size created in past transactions, for example: add prealloc extent beyond i_size fsync - clears the flag BTRFS_INODE_NEEDS_FULL_SYNC from the inode transaction commit add another prealloc extent beyond i_size fsync - triggers the fast fsync path power failure In that scenario, we would drop the first extent and then replay the second one. To fix this just make sure that all prealloc extents beyond i_size are logged, and if we find too many (which is far from a common case), fallback to a full transaction commit (like we do when logging regular extents in the fast fsync path). Trivial reproducer: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ xfs_io -f -c "pwrite -S 0xab 0 256K" /mnt/foo $ sync $ xfs_io -c "falloc -k 256K 1M" /mnt/foo $ xfs_io -c "fsync" /mnt/foo # mount to replay log $ mount /dev/sdb /mnt # at this point the file only has one extent, at offset 0, size 256K A test case for fstests follows soon, covering multiple scenarios that involve adding prealloc extents with previous shrinking truncates and without such truncates. Fixes: c71bf099abdd ("Btrfs: Avoid orphan inodes cleanup while replaying log") Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f2924e32dcf27b2267f2fd5f10482685386d47f6 Author: Liu Bo Date: Sat Mar 31 06:11:56 2018 +0800 Btrfs: clean up resources during umount after trans is aborted [ Upstream commit af7227338135d2f1b1552bf9a6d43e02dcba10b9 ] Currently if some fatal errors occur, like all IO get -EIO, resources would be cleaned up when a) transaction is being committed or b) BTRFS_FS_STATE_ERROR is set However, in some rare cases, resources may be left alone after transaction gets aborted and umount may run into some ASSERT(), e.g. ASSERT(list_empty(&block_group->dirty_list)); For case a), in btrfs_commit_transaciton(), there're several places at the beginning where we just call btrfs_end_transaction() without cleaning up resources. For case b), it is possible that the trans handle doesn't have any dirty stuff, then only trans hanlde is marked as aborted while BTRFS_FS_STATE_ERROR is not set, so resources remain in memory. This makes btrfs also check BTRFS_FS_STATE_TRANS_ABORTED to make sure that all resources won't stay in memory after umount. Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1908ca222b3656f7607e5bde4fe350c6051791f0 Author: Johannes Thumshirn Date: Thu Apr 12 09:16:06 2018 -0600 nvme: don't send keep-alives to the discovery controller [ Upstream commit 74c6c71530847808d4e3be7b205719270efee80c ] NVMe over Fabrics 1.0 Section 5.2 "Discovery Controller Properties and Command Support" Figure 31 "Discovery Controller – Admin Commands" explicitly listst all commands but "Get Log Page" and "Identify" as reserved, but NetApp report the Linux host is sending Keep Alive commands to the discovery controller, which is a violation of the Spec. We're already checking for discovery controllers when configuring the keep alive timeout but when creating a discovery controller we're not hard wiring the keep alive timeout to 0 and thus remain on NVME_DEFAULT_KATO for the discovery controller. This can be easily remproduced when issuing a direct connect to the discovery susbsystem using: 'nvme connect [...] --nqn=nqn.2014-08.org.nvmexpress.discovery' Signed-off-by: Johannes Thumshirn Fixes: 07bfcd09a288 ("nvme-fabrics: add a generic NVMe over Fabrics library") Reported-by: Martin George Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 145b7e06de33bafc7662f356f8bc25e1db285b3f Author: Jean Delvare Date: Fri Apr 13 15:37:59 2018 +0200 firmware: dmi_scan: Fix UUID length safety check [ Upstream commit 90fe6f8ff00a07641ca893d64f75ca22ce77cca2 ] The test which ensures that the DMI type 1 structure is long enough to hold the UUID is off by one. It would fail if the structure is exactly 24 bytes long, while that's sufficient to hold the UUID. I don't expect this bug to cause problem in practice because all implementations I have seen had length 8, 25 or 27 bytes, in line with the SMBIOS specifications. But let's fix it still. Signed-off-by: Jean Delvare Fixes: a814c3597a6b ("firmware: dmi_scan: Check DMI structure length") Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d9179b4aa407ee3c6408616f334b55484b1cb034 Author: Rich Felker Date: Thu Mar 15 20:01:36 2018 -0400 sh: fix debug trap failure to process signals before return to user [ Upstream commit 96a598996f6ac518ac79839ecbb17c91af91f4f7 ] When responding to a debug trap (breakpoint) in userspace, the kernel's trap handler raised SIGTRAP but returned from the trap via a code path that ignored pending signals, resulting in an infinite loop re-executing the trapping instruction. Signed-off-by: Rich Felker Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4ee9130f64238677cdff5948812426c1c75c0c5f Author: Yelena Krivosheev Date: Fri Mar 30 12:05:31 2018 +0200 net: mvneta: fix enable of all initialized RXQs [ Upstream commit e81b5e01c14add8395dfba7130f8829206bb507d ] In mvneta_port_up() we enable relevant RX and TX port queues by write queues bit map to an appropriate register. q_map must be ZERO in the beginning of this process. Signed-off-by: Yelena Krivosheev Acked-by: Thomas Petazzoni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 206199412baeba06745b03a7950895f26f95c14b Author: Toshiaki Makita Date: Thu Mar 29 19:05:30 2018 +0900 vlan: Fix vlan insertion for packets without ethernet header [ Upstream commit c769accdf3d8a103940bea2979b65556718567e9 ] In some situation vlan packets do not have ethernet headers. One example is packets from tun devices. Users can specify vlan protocol in tun_pi field instead of IP protocol. When we have a vlan device with reorder_hdr disabled on top of the tun device, such packets from tun devices are untagged in skb_vlan_untag() and vlan headers will be inserted back in vlan_insert_inner_tag(). vlan_insert_inner_tag() however did not expect packets without ethernet headers, so in such a case size argument for memmove() underflowed. We don't need to copy headers for packets which do not have preceding headers of vlan headers, so skip memmove() in that case. Also don't write vlan protocol in skb->data when it does not have enough room for it. Fixes: cbe7128c4b92 ("vlan: Fix out of order vlan headers with reorder header off") Signed-off-by: Toshiaki Makita Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 34a9a036350f5df3809065d64dadb28133c988b3 Author: Toshiaki Makita Date: Thu Mar 29 19:05:29 2018 +0900 net: Fix untag for vlan packets without ethernet header [ Upstream commit ae4745730cf8e693d354ccd4dbaf59ea440c09a9 ] In some situation vlan packets do not have ethernet headers. One example is packets from tun devices. Users can specify vlan protocol in tun_pi field instead of IP protocol, and skb_vlan_untag() attempts to untag such packets. skb_vlan_untag() (more precisely, skb_reorder_vlan_header() called by it) however did not expect packets without ethernet headers, so in such a case size argument for memmove() underflowed and triggered crash. ==== BUG: unable to handle kernel paging request at ffff8801cccb8000 IP: __memmove+0x24/0x1a0 arch/x86/lib/memmove_64.S:43 PGD 9cee067 P4D 9cee067 PUD 1d9401063 PMD 1cccb7063 PTE 2810100028101 Oops: 000b [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 17663 Comm: syz-executor2 Not tainted 4.16.0-rc7+ #368 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__memmove+0x24/0x1a0 arch/x86/lib/memmove_64.S:43 RSP: 0018:ffff8801cc046e28 EFLAGS: 00010287 RAX: ffff8801ccc244c4 RBX: fffffffffffffffe RCX: fffffffffff6c4c2 RDX: fffffffffffffffe RSI: ffff8801cccb7ffc RDI: ffff8801cccb8000 RBP: ffff8801cc046e48 R08: ffff8801ccc244be R09: ffffed0039984899 R10: 0000000000000001 R11: ffffed0039984898 R12: ffff8801ccc244c4 R13: ffff8801ccc244c0 R14: ffff8801d96b7c06 R15: ffff8801d96b7b40 FS: 00007febd562d700(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8801cccb8000 CR3: 00000001ccb2f006 CR4: 00000000001606e0 DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: memmove include/linux/string.h:360 [inline] skb_reorder_vlan_header net/core/skbuff.c:5031 [inline] skb_vlan_untag+0x470/0xc40 net/core/skbuff.c:5061 __netif_receive_skb_core+0x119c/0x3460 net/core/dev.c:4460 __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4627 netif_receive_skb_internal+0x10b/0x670 net/core/dev.c:4701 netif_receive_skb+0xae/0x390 net/core/dev.c:4725 tun_rx_batched.isra.50+0x5ee/0x870 drivers/net/tun.c:1555 tun_get_user+0x299e/0x3c20 drivers/net/tun.c:1962 tun_chr_write_iter+0xb9/0x160 drivers/net/tun.c:1990 call_write_iter include/linux/fs.h:1782 [inline] new_sync_write fs/read_write.c:469 [inline] __vfs_write+0x684/0x970 fs/read_write.c:482 vfs_write+0x189/0x510 fs/read_write.c:544 SYSC_write fs/read_write.c:589 [inline] SyS_write+0xef/0x220 fs/read_write.c:581 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x454879 RSP: 002b:00007febd562cc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007febd562d6d4 RCX: 0000000000454879 RDX: 0000000000000157 RSI: 0000000020000180 RDI: 0000000000000014 RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000000006b0 R14: 00000000006fc120 R15: 0000000000000000 Code: 90 90 90 90 90 90 90 48 89 f8 48 83 fa 20 0f 82 03 01 00 00 48 39 fe 7d 0f 49 89 f0 49 01 d0 49 39 f8 0f 8f 9f 00 00 00 48 89 d1 a4 c3 48 81 fa a8 02 00 00 72 05 40 38 fe 74 3b 48 83 ea 20 RIP: __memmove+0x24/0x1a0 arch/x86/lib/memmove_64.S:43 RSP: ffff8801cc046e28 CR2: ffff8801cccb8000 ==== We don't need to copy headers for packets which do not have preceding headers of vlan headers, so skip memmove() in that case. Fixes: 4bbb3e0e8239 ("net: Fix vlan untag for bridge and vlan_dev with reorder_hdr off") Reported-by: Eric Dumazet Signed-off-by: Toshiaki Makita Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 235ca6a0330d0ac2dcad16f0d0e751a51ee40ccf Author: Manish Chopra Date: Wed Mar 28 03:35:52 2018 -0700 qede: Do not drop rx-checksum invalidated packets. [ Upstream commit 58f101bf87e32753342a6924772c6ebb0fbde24a ] Today, driver drops received packets which are indicated as invalid checksum by the device. Instead of dropping such packets, pass them to the stack with CHECKSUM_NONE indication in skb. Signed-off-by: Ariel Elior Signed-off-by: Manish Chopra Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 78c986bf85b793980cce4eb6b048492bf0aa4f82 Author: Stephen Hemminger Date: Tue Mar 27 11:28:48 2018 -0700 hv_netvsc: enable multicast if necessary [ Upstream commit f03dbb06dc380274e351ca4b1ee1587ed4529e62 ] My recent change to netvsc drive in how receive flags are handled broke multicast. The Hyper-v/Azure virtual interface there is not a multicast filter list, filtering is only all or none. The driver must enable all multicast if any multicast address is present. Fixes: 009f766ca238 ("hv_netvsc: filter multicast/broadcast") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 28bbb0d963e06c76aeaf0f6b3f142b650d0e7a35 Author: Vinayak Menon Date: Wed Mar 28 16:01:16 2018 -0700 mm/kmemleak.c: wait for scan completion before disabling free [ Upstream commit 914b6dfff790544d9b77dfd1723adb3745ec9700 ] A crash is observed when kmemleak_scan accesses the object->pointer, likely due to the following race. TASK A TASK B TASK C kmemleak_write (with "scan" and NOT "scan=on") kmemleak_scan() create_object kmem_cache_alloc fails kmemleak_disable kmemleak_do_cleanup kmemleak_free_enabled = 0 kfree kmemleak_free bails out (kmemleak_free_enabled is 0) slub frees object->pointer update_checksum crash - object->pointer freed (DEBUG_PAGEALLOC) kmemleak_do_cleanup waits for the scan thread to complete, but not for direct call to kmemleak_scan via kmemleak_write. So add a wait for kmemleak_scan completion before disabling kmemleak_free, and while at it fix the comment on stop_scan_thread. [vinmenon@codeaurora.org: fix stop_scan_thread comment] Link: http://lkml.kernel.org/r/1522219972-22809-1-git-send-email-vinmenon@codeaurora.org Link: http://lkml.kernel.org/r/1522063429-18992-1-git-send-email-vinmenon@codeaurora.org Signed-off-by: Vinayak Menon Reviewed-by: Catalin Marinas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 08e9dbd5184e4e059adf1cc77b5dc08eca314a77 Author: Steven J. Hill Date: Wed Mar 28 16:01:09 2018 -0700 mm/vmstat.c: fix vmstat_update() preemption BUG [ Upstream commit c7f26ccfb2c31eb1bf810ba13d044fcf583232db ] Attempting to hotplug CPUs with CONFIG_VM_EVENT_COUNTERS enabled can cause vmstat_update() to report a BUG due to preemption not being disabled around smp_processor_id(). Discovered on Ubiquiti EdgeRouter Pro with Cavium Octeon II processor. BUG: using smp_processor_id() in preemptible [00000000] code: kworker/1:1/269 caller is vmstat_update+0x50/0xa0 CPU: 0 PID: 269 Comm: kworker/1:1 Not tainted 4.16.0-rc4-Cavium-Octeon-00009-gf83bbd5-dirty #1 Workqueue: mm_percpu_wq vmstat_update Call Trace: show_stack+0x94/0x128 dump_stack+0xa4/0xe0 check_preemption_disabled+0x118/0x120 vmstat_update+0x50/0xa0 process_one_work+0x144/0x348 worker_thread+0x150/0x4b8 kthread+0x110/0x140 ret_from_kernel_thread+0x14/0x1c Link: http://lkml.kernel.org/r/1520881552-25659-1-git-send-email-steven.hill@cavium.com Signed-off-by: Steven J. Hill Reviewed-by: Andrew Morton Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d2a5d00dcd8502e1e5071e983e619823d6cc68dd Author: Maninder Singh Date: Wed Mar 28 16:01:05 2018 -0700 mm/page_owner: fix recursion bug after changing skip entries [ Upstream commit 299815a4fba9f3c7a81434dba0072148f1690608 ] This patch fixes commit 5f48f0bd4e36 ("mm, page_owner: skip unnecessary stack_trace entries"). Because if we skip first two entries then logic of checking count value as 2 for recursion is broken and code will go in one depth recursion. so we need to check only one call of _RET_IP(__set_page_owner) while checking for recursion. Current Backtrace while checking for recursion:- (save_stack) from (__set_page_owner) // (But recursion returns true here) (__set_page_owner) from (get_page_from_freelist) (get_page_from_freelist) from (__alloc_pages_nodemask) (__alloc_pages_nodemask) from (depot_save_stack) (depot_save_stack) from (save_stack) // recursion should return true here (save_stack) from (__set_page_owner) (__set_page_owner) from (get_page_from_freelist) (get_page_from_freelist) from (__alloc_pages_nodemask+) (__alloc_pages_nodemask) from (depot_save_stack) (depot_save_stack) from (save_stack) (save_stack) from (__set_page_owner) (__set_page_owner) from (get_page_from_freelist) Correct Backtrace with fix: (save_stack) from (__set_page_owner) // recursion returned true here (__set_page_owner) from (get_page_from_freelist) (get_page_from_freelist) from (__alloc_pages_nodemask+) (__alloc_pages_nodemask) from (depot_save_stack) (depot_save_stack) from (save_stack) (save_stack) from (__set_page_owner) (__set_page_owner) from (get_page_from_freelist) Link: http://lkml.kernel.org/r/1521607043-34670-1-git-send-email-maninder1.s@samsung.com Fixes: 5f48f0bd4e36 ("mm, page_owner: skip unnecessary stack_trace entries") Signed-off-by: Maninder Singh Signed-off-by: Vaneet Narang Acked-by: Vlastimil Babka Cc: Michal Hocko Cc: Oscar Salvador Cc: Greg Kroah-Hartman Cc: Ayush Mittal Cc: Prakash Gupta Cc: Vinayak Menon Cc: Vasyl Gomonovych Cc: Amit Sahrawat Cc: Cc: Vaneet Narang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit da9ec481d66dcca59f3556c2fc783967da2c7697 Author: Shakeel Butt Date: Wed Mar 28 16:00:57 2018 -0700 mm, slab: memcg_link the SLAB's kmem_cache [ Upstream commit 880cd276dff17ea29e9a8404275c9502b265afa7 ] All the root caches are linked into slab_root_caches which was introduced by the commit 510ded33e075 ("slab: implement slab_root_caches list") but it missed to add the SLAB's kmem_cache. While experimenting with opt-in/opt-out kmem accounting, I noticed system crashes due to NULL dereference inside cache_from_memcg_idx() while deferencing kmem_cache.memcg_params.memcg_caches. The upstream clean kernel will not see these crashes but SLAB should be consistent with SLUB which does linked its boot caches (kmem_cache_node and kmem_cache) into slab_root_caches. Link: http://lkml.kernel.org/r/20180319210020.60289-1-shakeelb@google.com Fixes: 510ded33e075c ("slab: implement slab_root_caches list") Signed-off-by: Shakeel Butt Cc: Tejun Heo Cc: Vladimir Davydov Cc: Greg Thelen Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Johannes Weiner Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0bbd8e2593ad0ce31cf063cc7723d66fae5c31b3 Author: Manish Chopra Date: Tue Mar 27 06:34:41 2018 -0700 qede: Fix barrier usage after tx doorbell write. [ Upstream commit b9fc828debc8ac2bb21b5819a44d2aea456f1c95 ] Since commit c5ad119fb6c09b0297446be05bd66602fa564758 ("net: sched: pfifo_fast use skb_array") driver is exposed to an issue where it is hitting NULL skbs while handling TX completions. Driver uses mmiowb() to flush the writes to the doorbell bar which is a write-combined bar, however on x86 mmiowb() does not flush the write combined buffer. This patch fixes this problem by replacing mmiowb() with wmb() after the write combined doorbell write so that writes are flushed and synchronized from more than one processor. V1->V2: ------- This patch was marked as "superseded" in patchwork. (Not really sure for what reason).Resending it as v2. Signed-off-by: Ariel Elior Signed-off-by: Manish Chopra Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 38a85f8214e214600681c5d3f940015be92900a7 Author: Jan Kiszka Date: Wed Mar 21 13:15:28 2018 +0800 builddeb: Fix header package regarding dtc source links [ Upstream commit f8437520704cfd9cc442a99d73ed708a3cdadaf9 ] Since d5d332d3f7e8, a couple of links in scripts/dtc/include-prefixes are additionally required in order to build device trees with the header package. Signed-off-by: Jan Kiszka Reviewed-by: Riku Voipio Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5b5f4fd97d8fdc5d41ad632ed5154989b38b613f Author: Cong Wang Date: Mon Mar 26 15:08:33 2018 -0700 llc: properly handle dev_queue_xmit() return value [ Upstream commit b85ab56c3f81c5a24b5a5213374f549df06430da ] llc_conn_send_pdu() pushes the skb into write queue and calls llc_conn_send_pdus() to flush them out. However, the status of dev_queue_xmit() is not returned to caller, in this case, llc_conn_state_process(). llc_conn_state_process() needs hold the skb no matter success or failure, because it still uses it after that, therefore we should hold skb before dev_queue_xmit() when that skb is the one being processed by llc_conn_state_process(). For other callers, they can just pass NULL and ignore the return value as they are. Reported-by: Noam Rathaus Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 25801736ca4818040b184c5547e6f5a14eaf4847 Author: Alexey Dobriyan Date: Sun Jan 14 15:05:04 2018 +0300 x86/alternatives: Fixup alternative_call_2 [ Upstream commit bd6271039ee6f0c9b468148fc2d73e0584af6b4f ] The following pattern fails to compile while the same pattern with alternative_call() does: if (...) alternative_call_2(...); else alternative_call_2(...); as it expands into if (...) { }; <=== else { }; Signed-off-by: Alexey Dobriyan Signed-off-by: Thomas Gleixner Acked-by: Borislav Petkov Link: https://lkml.kernel.org/r/20180114120504.GA11368@avx2 Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 06956ca1aab3f12ba71b213f0142d5a233314806 Author: Stephane Eranian Date: Fri Mar 23 00:01:47 2018 -0700 perf/x86/intel: Fix linear IP of PEBS real_ip on Haswell and later CPUs [ Upstream commit 71eb9ee9596d8df3d5723c3cfc18774c6235e8b1 ] this patch fix a bug in how the pebs->real_ip is handled in the PEBS handler. real_ip only exists in Haswell and later processor. It is actually the eventing IP, i.e., where the event occurred. As opposed to the pebs->ip which is the PEBS interrupt IP which is always off by one. The problem is that the real_ip just like the IP needs to be fixed up because PEBS does not record all the machine state registers, and in particular the code segement (cs). This is why we have the set_linear_ip() function. The problem was that set_linear_ip() was only used on the pebs->ip and not the pebs->real_ip. We have profiles which ran into invalid callstacks because of this. Here is an example: ..... 0: ffffffffffffff80 recent entry, marker kernel v ..... 1: 000000000040044d <= user address in kernel space! ..... 2: fffffffffffffe00 marker enter user v ..... 3: 000000000040044d ..... 4: 00000000004004b6 oldest entry Debugging output in get_perf_callchain(): [ 857.769909] CALLCHAIN: CPU8 ip=40044d regs->cs=10 user_mode(regs)=0 The problem is that the kernel entry in 1: points to a user level address. How can that be? The reason is that with PEBS sampling the instruction that caused the event to occur and the instruction where the CPU was when the interrupt was posted may be far apart. And sometime during that time window, the privilege level may change. This happens, for instance, when the PEBS sample is taken close to a kernel entry point. Here PEBS, eventing IP (real_ip) captured a user level instruction. But by the time the PMU interrupt fired, the processor had already entered kernel space. This is why the debug output shows a user address with user_mode() false. The problem comes from PEBS not recording the code segment (cs) register. The register is used in x86_64 to determine if executing in kernel vs user space. This is okay because the kernel has a software workaround called set_linear_ip(). But the issue in setup_pebs_sample_data() is that set_linear_ip() is never called on the real_ip value when it is available (Haswell and later) and precise_ip > 1. This patch fixes this problem and eliminates the callchain discrepancy. The patch restructures the code around set_linear_ip() to minimize the number of times the IP has to be set. Signed-off-by: Stephane Eranian Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vince Weaver Cc: kan.liang@intel.com Link: http://lkml.kernel.org/r/1521788507-10231-1-git-send-email-eranian@google.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5b3b9ce272a603492bfefb99ed2586c1b780f800 Author: Or Gerlitz Date: Thu Feb 15 12:39:55 2018 +0200 net/mlx5: Make eswitch support to depend on switchdev [ Upstream commit f125376b06bcc57dfb0216ac8d6ec6d5dcf81025 ] Add dependancy for switchdev to be congfigured as any user-space control plane SW is expected to use the HW switchdev ID to locate the representors related to VFs of a certain PF and apply SW/offloaded switching on them. Fixes: e80541ecabd5 ('net/mlx5: Add CONFIG_MLX5_ESWITCH Kconfig') Signed-off-by: Or Gerlitz Reviewed-by: Mark Bloch Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 07af604f00a523c44da36511a3b5d0c1143cbb3a Author: Sean Wang Date: Mon Mar 26 18:07:10 2018 +0800 net: dsa: mt7530: fix module autoloading for OF platform drivers [ Upstream commit 3c82b372a9f44aa224b8d5106ff6f1ad516fa8a8 ] It's required to create a modules.alias via MODULE_DEVICE_TABLE helper for the OF platform driver. Otherwise, module autoloading cannot work. Signed-off-by: Sean Wang Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 77c18f7ea4179ed45e979ad7b7432ffbeccaa3e5 Author: Xin Long Date: Mon Mar 26 01:16:45 2018 +0800 bonding: fix the err path for dev hwaddr sync in bond_enslave [ Upstream commit 5c78f6bfae2b10ff70e21d343e64584ea6280c26 ] vlan_vids_add_by_dev is called right after dev hwaddr sync, so on the err path it should unsync dev hwaddr. Otherwise, the slave dev's hwaddr will never be unsync when this err happens. Fixes: 1ff412ad7714 ("bonding: change the bond's vlan syncing functions with the standard ones") Signed-off-by: Xin Long Reviewed-by: Nikolay Aleksandrov Acked-by: Andy Gospodarek Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6da5c98d65f0f87d8e12c62e421036777c4fadeb Author: Pawel Dembicki Date: Sat Mar 24 22:08:14 2018 +0100 net: qmi_wwan: add BroadMobi BM806U 2020:2033 [ Upstream commit 743989254ea9f132517806d8893ca9b6cf9dc86b ] BroadMobi BM806U is an Qualcomm MDM9225 based 3G/4G modem. Tested hardware BM806U is mounted on D-Link DWR-921-C3 router. The USB id is added to qmi_wwan.c to allow QMI communication with the BM806U. Tested on 4.14 kernel and OpenWRT. Signed-off-by: Pawel Dembicki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e78be20d112250f9a29189c1c14051d9984e0a81 Author: Raghuram Chary J Date: Fri Mar 23 15:48:08 2018 +0530 lan78xx: Set ASD in MAC_CR when EEE is enabled. [ Upstream commit e69647a19c870c2f919e4d5023af8a515e8ef25f ] Description: EEE does not work with lan7800 when AutoSpeed is not set. (This can happen when EEPROM is not populated or configured incorrectly) Root-Cause: When EEE is enabled, the mac config register ASD is not set i.e. in default state, causing EEE fail. Fix: Set the register when eeprom is not present. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Raghuram Chary J Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 373304e44fa9c55fe422e897b263cfb1c9c7310d Author: Jinbum Park Date: Tue Mar 6 01:37:21 2018 +0100 ARM: 8748/1: mm: Define vdso_start, vdso_end as array [ Upstream commit 73b9160d0dfe44dfdaffd6465dc1224c38a4a73c ] Define vdso_start, vdso_end as array to avoid compile-time analysis error for the case of built with CONFIG_FORTIFY_SOURCE. and, since vdso_start, vdso_end are used in vdso.c only, move extern-declaration from vdso.h to vdso.c. If kernel is built with CONFIG_FORTIFY_SOURCE, compile-time error happens at this code. - if (memcmp(&vdso_start, "177ELF", 4)) The size of "&vdso_start" is recognized as 1 byte, but n is 4, So that compile-time error is reported. Acked-by: Kees Cook Signed-off-by: Jinbum Park Signed-off-by: Russell King Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cbecd7187cdf3fe84d8b6bf58e68cf60225515e8 Author: Linus Lüssing Date: Thu Mar 22 00:21:32 2018 +0100 batman-adv: fix packet loss for broadcasted DHCP packets to a server [ Upstream commit a752c0a4524889cdc0765925258fd1fd72344100 ] DHCP connectivity issues can currently occur if the following conditions are met: 1) A DHCP packet from a client to a server 2) This packet has a multicast destination 3) This destination has a matching entry in the translation table (FF:FF:FF:FF:FF:FF for IPv4, 33:33:00:01:00:02/33:33:00:01:00:03 for IPv6) 4) The orig-node determined by TT for the multicast destination does not match the orig-node determined by best-gateway-selection In this case the DHCP packet will be dropped. The "gateway-out-of-range" check is supposed to only be applied to unicasted DHCP packets to a specific DHCP server. In that case dropping the the unicasted frame forces the client to retry via a broadcasted one, but now directed to the new best gateway. A DHCP packet with broadcast/multicast destination is already ensured to always be delivered to the best gateway. Dropping a multicasted DHCP packet here will only prevent completing DHCP as there is no other fallback. So far, it seems the unicast check was implicitly performed by expecting the batadv_transtable_search() to return NULL for multicast destinations. However, a multicast address could have always ended up in the translation table and in fact is now common. To fix this potential loss of a DHCP client-to-server packet to a multicast address this patch adds an explicit multicast destination check to reliably bail out of the gateway-out-of-range check for such destinations. The issue and fix were tested in the following three node setup: - Line topology, A-B-C - A: gateway client, DHCP client - B: gateway server, hop-penalty increased: 30->60, DHCP server - C: gateway server, code modifications to announce FF:FF:FF:FF:FF:FF Without this patch, A would never transmit its DHCP Discover packet due to an always "out-of-range" condition. With this patch, a full DHCP handshake between A and B was possible again. Fixes: be7af5cf9cae ("batman-adv: refactoring gateway handling code") Signed-off-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 110a7c19d9d155342632cc830f0d459f0b7308ac Author: Linus Lüssing Date: Tue Mar 20 03:13:27 2018 +0100 batman-adv: fix multicast-via-unicast transmission with AP isolation [ Upstream commit f8fb3419ead44f9a3136995acd24e35da4525177 ] For multicast frames AP isolation is only supposed to be checked on the receiving nodes and never on the originating one. Furthermore, the isolation or wifi flag bits should only be intepreted as such for unicast and never multicast TT entries. By injecting flags to the multicast TT entry claimed by a single target node it was verified in tests that this multicast address becomes unreachable, leading to packet loss. Omitting the "src" parameter to the batadv_transtable_search() call successfully skipped the AP isolation check and made the target reachable again. Fixes: 1d8ab8d3c176 ("batman-adv: Modified forwarding behaviour for multicast packets") Signed-off-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bbeb1a42dc584137041841652b98ac0f4e7b7200 Author: Felix Kuehling Date: Fri Mar 23 15:30:33 2018 -0400 drm/amdkfd: Fix scratch memory with HWS enabled [ Upstream commit c70a36268799cf2f902b5a31e452571fcb96bfe9 ] Program sh_hidden_private_base_vmid correctly in the map-process PM4 packet. Signed-off-by: Felix Kuehling Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 629b3a66d5ca6b191807bf6cb59aef8452e101e7 Author: Masami Hiramatsu Date: Sat Mar 17 21:40:31 2018 +0900 selftests: ftrace: Add a testcase for probepoint [ Upstream commit dfa453bc90eca0febff33c8d292a656e53702158 ] Add a testcase for probe point definition. This tests symbol, address and symbol+offset syntax. The offset must be positive and smaller than UINT_MAX. Link: http://lkml.kernel.org/r/152129043097.31874.14273580606301767394.stgit@devbox Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 04905c21ad69e7b5e53bd57e779db464c8a38324 Author: Masami Hiramatsu Date: Sat Mar 17 21:39:44 2018 +0900 selftests: ftrace: Add a testcase for string type with kprobe_event [ Upstream commit 5fbdbed797b6d12d043a5121fdbc8d8b49d10e80 ] Add a testcase for string type with kprobe event. This tests good/bad syntax combinations and also the traced data is correct in several way. Link: http://lkml.kernel.org/r/152129038381.31874.9201387794548737554.stgit@devbox Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7ed525fcb56a30f956ab42a16279670e2b1c498 Author: Masami Hiramatsu Date: Sat Mar 17 21:38:56 2018 +0900 selftests: ftrace: Add probe event argument syntax testcase [ Upstream commit 871bef2000968c312a4000b2f56d370dcedbc93c ] Add a testcase for probe event argument syntax which ensures the kprobe_events interface correctly parses given event arguments. Link: http://lkml.kernel.org/r/152129033679.31874.12705519603869152799.stgit@devbox Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 58be6253b0030799f653e9c53fab649260d52221 Author: Steffen Klassert Date: Mon Mar 19 07:15:39 2018 +0100 xfrm: Fix transport mode skb control buffer usage. [ Upstream commit 9a3fb9fb84cc30577c1b012a6a3efda944684291 ] A recent commit introduced a new struct xfrm_trans_cb that is used with the sk_buff control buffer. Unfortunately it placed the structure in front of the control buffer and overlooked that the IPv4/IPv6 control buffer is still needed for some layer 4 protocols. As a result the IPv4/IPv6 control buffer is overwritten with this structure. Fix this by setting a apropriate header in front of the structure. Fixes acf568ee859f ("xfrm: Reinject transport-mode packets ...") Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 49f4a8c52eeb6a8bc48da3845081bae55512af47 Author: David Rientjes Date: Thu Mar 22 16:17:45 2018 -0700 mm, thp: do not cause memcg oom for thp [ Upstream commit 9d3c3354bb85bab4d865fe95039443f09a4c8394 ] Commit 2516035499b9 ("mm, thp: remove __GFP_NORETRY from khugepaged and madvised allocations") changed the page allocator to no longer detect thp allocations based on __GFP_NORETRY. It did not, however, modify the mem cgroup try_charge() path to avoid oom kill for either khugepaged collapsing or thp faulting. It is never expected to oom kill a process to allocate a hugepage for thp; reclaim is governed by the thp defrag mode and MADV_HUGEPAGE, but allocations (and charging) should fallback instead of oom killing processes. Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1803191409420.124411@chino.kir.corp.google.com Fixes: 2516035499b9 ("mm, thp: remove __GFP_NORETRY from khugepaged and madvised allocations") Signed-off-by: David Rientjes Cc: "Kirill A. Shutemov" Cc: Michal Hocko Cc: Vlastimil Babka Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ca473201d709e2d061bf770776b96b9024e58df Author: Yisheng Xie Date: Thu Mar 22 16:17:02 2018 -0700 mm/mempolicy.c: avoid use uninitialized preferred_node [ Upstream commit 8970a63e965b43288c4f5f40efbc2bbf80de7f16 ] Alexander reported a use of uninitialized memory in __mpol_equal(), which is caused by incorrect use of preferred_node. When mempolicy in mode MPOL_PREFERRED with flags MPOL_F_LOCAL, it uses numa_node_id() instead of preferred_node, however, __mpol_equal() uses preferred_node without checking whether it is MPOL_F_LOCAL or not. [akpm@linux-foundation.org: slight comment tweak] Link: http://lkml.kernel.org/r/4ebee1c2-57f6-bcb8-0e2d-1833d1ee0bb7@huawei.com Fixes: fc36b8d3d819 ("mempolicy: use MPOL_F_LOCAL to Indicate Preferred Local Policy") Signed-off-by: Yisheng Xie Reported-by: Alexander Potapenko Tested-by: Alexander Potapenko Reviewed-by: Andrew Morton Cc: Dmitriy Vyukov Cc: Vlastimil Babka Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5498a2b5795f45de39dc1508a7e5aa1da7ba3447 Author: Y.C. Chen Date: Mon Mar 12 11:40:23 2018 +0800 drm/ast: Fixed 1280x800 Display Issue [ Upstream commit 5a9f698feb11b198f17b2acebbfe0e2716a3beed ] The original ast driver cannot display properly if the resolution is 1280x800 and the pixel clock is 83.5MHz. Here is the update to fix it. Signed-off-by: Y.C. Chen Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c269eb77dc22a79ad153ec9fd7efaa3d8cd56d00 Author: Florian Fainelli Date: Tue Mar 20 17:31:10 2018 -0700 net: dsa: Fix functional dsa-loop dependency on FIXED_PHY [ Upstream commit 40013ff20b1beed31184935fc0aea6a859d4d4ef ] We have a functional dependency on the FIXED_PHY MDIO bus because we register fixed PHY devices "the old way" which only works if the code that does this has had a chance to run before the fixed MDIO bus is probed. Make sure we account for that and have dsa_loop_bdinfo.o be either built-in or modular depending on whether CONFIG_FIXED_PHY reflects that too. Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bf922554682ba4404d06208ca4196aadd57d0d92 Author: Davide Caratti Date: Mon Mar 19 15:31:28 2018 +0100 net/sched: fix idr leak in the error path of tcf_skbmod_init() [ Upstream commit f29cdfbe33d6915ba8056179b0041279a67e3647 ] tcf_skbmod_init() can fail after the idr has been successfully reserved. When this happens, every subsequent attempt to configure skbmod rules using the same idr value will systematically fail with -ENOSPC, unless the first attempt was done using the 'replace' keyword: # tc action add action skbmod swap mac index 100 RTNETLINK answers: Cannot allocate memory We have an error talking to the kernel # tc action add action skbmod swap mac index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel # tc action add action skbmod swap mac index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel ... Fix this in tcf_skbmod_init(), ensuring that tcf_idr_release() is called on the error path when the idr has been reserved, but not yet inserted. Also, don't test 'ovr' in the error path, to avoid a 'replace' failure implicitly become a 'delete' that leaks refcount in act_skbmod module: # rmmod act_skbmod; modprobe act_skbmod # tc action add action skbmod swap mac index 100 # tc action add action skbmod swap mac continue index 100 RTNETLINK answers: File exists We have an error talking to the kernel # tc action replace action skbmod swap mac continue index 100 RTNETLINK answers: Cannot allocate memory We have an error talking to the kernel # tc action list action skbmod # # rmmod act_skbmod rmmod: ERROR: Module act_skbmod is in use Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR") Acked-by: Jamal Hadi Salim Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 91314c2731705274e2748b723291df3993f167a3 Author: Davide Caratti Date: Mon Mar 19 15:31:26 2018 +0100 net/sched: fix idr leak in the error path of __tcf_ipt_init() [ Upstream commit 1e46ef1762bb2e52f0f996131a4d16ed4e9fd065 ] __tcf_ipt_init() can fail after the idr has been successfully reserved. When this happens, subsequent attempts to configure xt/ipt rules using the same idr value systematically fail with -ENOSPC: # tc action add action xt -j LOG --log-prefix test1 index 100 tablename: mangle hook: NF_IP_POST_ROUTING target: LOG level warning prefix "test1" index 100 RTNETLINK answers: Cannot allocate memory We have an error talking to the kernel Command "(null)" is unknown, try "tc actions help". # tc action add action xt -j LOG --log-prefix test1 index 100 tablename: mangle hook: NF_IP_POST_ROUTING target: LOG level warning prefix "test1" index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel Command "(null)" is unknown, try "tc actions help". # tc action add action xt -j LOG --log-prefix test1 index 100 tablename: mangle hook: NF_IP_POST_ROUTING target: LOG level warning prefix "test1" index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel ... Fix this in the error path of __tcf_ipt_init(), calling tcf_idr_release() in place of tcf_idr_cleanup(). Since tcf_ipt_release() can now be called when tcfi_t is NULL, we also need to protect calls to ipt_destroy_target() to avoid NULL pointer dereference. Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR") Acked-by: Jamal Hadi Salim Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 01a80839635db5973dc72e00e7abd4d902af1902 Author: Davide Caratti Date: Mon Mar 19 15:31:25 2018 +0100 net/sched: fix idr leak in the error path of tcp_pedit_init() [ Upstream commit 94fa3f929ec0c048b1f3658cc335b940df4f6d22 ] tcf_pedit_init() can fail to allocate 'keys' after the idr has been successfully reserved. When this happens, subsequent attempts to configure a pedit rule using the same idr value systematically fail with -ENOSPC: # tc action add action pedit munge ip ttl set 63 index 100 RTNETLINK answers: Cannot allocate memory We have an error talking to the kernel # tc action add action pedit munge ip ttl set 63 index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel # tc action add action pedit munge ip ttl set 63 index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel ... Fix this in the error path of tcf_act_pedit_init(), calling tcf_idr_release() in place of tcf_idr_cleanup(). Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR") Acked-by: Jamal Hadi Salim Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 97689fea3c803d5b47a45941a6f46e196a0f2c53 Author: Davide Caratti Date: Mon Mar 19 15:31:24 2018 +0100 net/sched: fix idr leak in the error path of tcf_act_police_init() [ Upstream commit 5bf7f8185f7c7112decdfe3d3e5c5d5e67f099a1 ] tcf_act_police_init() can fail after the idr has been successfully reserved (e.g., qdisc_get_rtab() may return NULL). When this happens, subsequent attempts to configure a police rule using the same idr value systematiclly fail with -ENOSPC: # tc action add action police rate 1000 burst 1000 drop index 100 RTNETLINK answers: Cannot allocate memory We have an error talking to the kernel # tc action add action police rate 1000 burst 1000 drop index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel # tc action add action police rate 1000 burst 1000 drop index 100 RTNETLINK answers: No space left on device ... Fix this in the error path of tcf_act_police_init(), calling tcf_idr_release() in place of tcf_idr_cleanup(). Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR") Acked-by: Jamal Hadi Salim Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 154040a5a869af2ef1f78f828a35ea03772e3da0 Author: Davide Caratti Date: Mon Mar 19 15:31:23 2018 +0100 net/sched: fix idr leak in the error path of tcf_simp_init() [ Upstream commit 60e10b3adc3bac0f6a894c28e0eb1f2d13607362 ] if the kernel fails to duplicate 'sdata', creation of a new action fails with -ENOMEM. However, subsequent attempts to install the same action using the same value of 'index' systematically fail with -ENOSPC, and that value of 'index' will no more be usable by act_simple, until rmmod / insmod of act_simple.ko is done: # tc actions add action simple sdata hello index 100 # tc actions list action simple action order 0: Simple index 100 ref 1 bind 0 # tc actions flush action simple # tc actions add action simple sdata hello index 100 RTNETLINK answers: Cannot allocate memory We have an error talking to the kernel # tc actions flush action simple # tc actions add action simple sdata hello index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel # tc actions add action simple sdata hello index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel ... Fix this in the error path of tcf_simp_init(), calling tcf_idr_release() in place of tcf_idr_cleanup(). Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR") Suggested-by: Cong Wang Acked-by: Jamal Hadi Salim Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 29e36c3099fc2e3064068508ced39a702d1815b9 Author: Davide Caratti Date: Mon Mar 19 15:31:22 2018 +0100 net/sched: fix idr leak on the error path of tcf_bpf_init() [ Upstream commit bbc09e7842a5023ba5bc0f8d559b9dd464e44006 ] when the following command sequence is entered # tc action add action bpf bytecode '4,40 0 0 12,31 0 1 2048,6 0 0 262144,6 0 0 0' index 100 RTNETLINK answers: Invalid argument We have an error talking to the kernel # tc action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' index 100 RTNETLINK answers: No space left on device We have an error talking to the kernel act_bpf correctly refuses to install the first TC rule, because 31 is not a valid instruction. However, it refuses to install the second TC rule, even if the BPF code is correct. Furthermore, it's no more possible to install any other rule having the same value of 'index' until act_bpf module is unloaded/inserted again. After the idr has been reserved, call tcf_idr_release() instead of tcf_idr_cleanup(), to fix this issue. Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR") Acked-by: Jamal Hadi Salim Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f8d93c59c78cc925f542f22d5388473f69005840 Author: Kalderon, Michal Date: Wed Mar 21 14:51:52 2018 +0200 RDMA/qedr: Fix QP state initialization race [ Upstream commit caf61b1b8b88ccf1451f7321a176393797e8d292 ] Once the FW is transitioned to error, FLUSH cqes can be received. We want the driver to be aware of the fact that QP is already in error. Without this fix, a user may see false error messages in the dmesg log, mentioning that a FLUSH cqe was received while QP is not in error state. Fixes: cecbcddf ("qedr: Add support for QP verbs") Signed-off-by: Michal Kalderon Signed-off-by: Ariel Elior Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8ed753eee9bdf091a2ca2541451b42717de7e781 Author: Kalderon, Michal Date: Wed Mar 21 14:51:51 2018 +0200 RDMA/qedr: Fix rc initialization on CNQ allocation failure [ Upstream commit b15606f47b89b0b09936d7f45b59ba6275527041 ] Return code wasn't set properly when CNQ allocation failed. This only affect error message logging, currently user will receive an error message that says the qedr driver load failed with rc '0', instead of ENOMEM Fixes: ec72fce4 ("qedr: Add support for RoCE HW init") Signed-off-by: Michal Kalderon Signed-off-by: Ariel Elior Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 90b87707f0f7606782ee027a50187ae5bc62ca48 Author: Kalderon, Michal Date: Wed Mar 21 14:51:50 2018 +0200 RDMA/qedr: fix QP's ack timeout configuration [ Upstream commit c3594f22302cca5e924e47ec1cc8edd265708f41 ] QPs that were configured with ack timeout value lower than 1 msec will not implement re-transmission timeout. This means that if a packet / ACK were dropped, the QP will not retransmit this packet. This can lead to an application hang. Fixes: cecbcddf6 ("qedr: Add support for QP verbs") Signed-off-by: Michal Kalderon Signed-off-by: Ariel Elior Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7245e2d1790b4dbcaf318c36b87758d568e67f8b Author: Chien Tin Tung Date: Wed Mar 21 13:09:25 2018 -0500 RDMA/ucma: Correct option size check using optlen [ Upstream commit 5f3e3b85cc0a5eae1c46d72e47d3de7bf208d9e2 ] The option size check is using optval instead of optlen causing the set option call to fail. Use the correct field, optlen, for size check. Fixes: 6a21dfc0d0db ("RDMA/ucma: Limit possible option size") Signed-off-by: Chien Tin Tung Signed-off-by: Shiraz Saleem Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 405544d5f864ae0b8c191a2ff3201c0277bbeb70 Author: Nicolas Pitre Date: Thu Mar 15 16:56:20 2018 -0400 kbuild: make scripts/adjust_autoksyms.sh robust against timestamp races [ Upstream commit 825d487583089f9a33d31650c9c41f6474aab7fc ] Some filesystems have timestamps with coarse precision that may allow for a recently built object file to have the same timestamp as the updated time on one of its dependency files. When that happens, the object file doesn't get rebuilt as it should. This is especially the case on filesystems that don't have sub-second time precision, such as ext3 or Ext4 with 128B inodes. Let's prevent that by making sure updated dependency files have a newer timestamp than the first file we created (i.e. autoksyms.h.tmpnew). Reported-by: Thomas Lindroth Signed-off-by: Nicolas Pitre Tested-by: Thomas Lindroth Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0839b0ce6eb667e556f240b83bf429165dd567b6 Author: Stefan Wahren Date: Wed Mar 14 20:02:59 2018 +0100 brcmfmac: Fix check for ISO3166 code [ Upstream commit 9b9322db5c5a1917a66c71fe47c3848a9a31227e ] The commit "regulatory: add NUL to request alpha2" increases the length of alpha2 to 3. This causes a regression on brcmfmac, because brcmf_cfg80211_reg_notifier() expect valid ISO3166 codes in the complete array. So fix this accordingly. Fixes: 657308f73e67 ("regulatory: add NUL to request alpha2") Signed-off-by: Stefan Wahren Acked-by: Franky Lin Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4ff78587dea66265b5345182781592a8c89815ec Author: Song Liu Date: Mon Mar 12 09:59:43 2018 -0700 perf/cgroup: Fix child event counting bug [ Upstream commit c917e0f259908e75bd2a65877e25f9d90c22c848 ] When a perf_event is attached to parent cgroup, it should count events for all children cgroups: parent_group <---- perf_event \ - child_group <---- process(es) However, in our tests, we found this perf_event cannot report reliable results. Here is an example case: # create cgroups mkdir -p /sys/fs/cgroup/p/c # start perf for parent group perf stat -e instructions -G "p" # on another console, run test process in child cgroup: stressapptest -s 2 -M 1000 & echo $! > /sys/fs/cgroup/p/c/cgroup.procs # after the test process is done, stop perf in the first console shows instructions p The instruction should not be "not counted" as the process runs in the child cgroup. We found this is because perf_event->cgrp and cpuctx->cgrp are not identical, thus perf_event->cgrp are not updated properly. This patch fixes this by updating perf_cgroup properly for ancestor cgroup(s). Reported-by: Ephraim Park Signed-off-by: Song Liu Signed-off-by: Peter Zijlstra (Intel) Cc: Cc: Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Link: http://lkml.kernel.org/r/20180312165943.1057894-1-songliubraving@fb.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 92ab37923634609154d4dd7c7df13b80c345a1e8 Author: Thierry Reding Date: Sun Mar 18 01:13:39 2018 +0100 drm/tegra: Shutdown on driver unbind [ Upstream commit 192b4af6cd28cdad9b42fd79c21a90a2aeb0bec7 ] Since commit 846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2."), removing the last framebuffer will no longer disable the corresponding pipeline, which causes the KMS core to complain about leaked connectors on driver unbind. Fix this by calling drm_atomic_helper_shutdown() on driver unbind, which will cause all display pipelines to be shut down and therefore drop the extra references on the connectors. Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3a297d091edbf61176f18842b27b07448dfcad67 Author: Avraham Stern Date: Mon Mar 5 11:26:53 2018 +0200 iwlwifi: mvm: fix array out of bounds reference [ Upstream commit 4a6d2e525b43eba5870ea7e360f59aa65de00705 ] When starting aggregation, the code checks the status of the queue allocated to the aggregation tid, which might not yet be allocated and thus the queue index may be invalid. Fix this by reserving a new queue in case the queue id is invalid. While at it, clean up some unreachable code (a condition that is already handled earlier) and remove all the non-DQA comments since non-DQA mode is no longer supported. Fixes: cf961e16620f ("iwlwifi: mvm: support dqa-mode agg on non-shared queue") Signed-off-by: Avraham Stern Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7867e6d82fc9c35e02ae407641f5603bdbcc1a6f Author: Avraham Stern Date: Tue Mar 6 14:10:49 2018 +0200 iwlwifi: mvm: make sure internal station has a valid id [ Upstream commit df65c8d1728adee2a52c30287d33da83a8c87480 ] If the driver failed to resume from D3, it is possible that it has no valid aux station. In such case, fw restart will end up in sending station related commands with an invalid station id, which will result in an assert. Fix this by allocating a new station id for the aux station if it does not have a valid id even in the case of fw restart. Signed-off-by: Avraham Stern Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1001e8ec25db887240b0f397c1f5050fbb207502 Author: Avraham Stern Date: Wed Mar 7 10:41:18 2018 +0200 iwlwifi: mvm: clear tx queue id when unreserving aggregation queue [ Upstream commit 4b387906b1c3692bb790388c335515c0cf098a23 ] When a queue is reserved for aggregation, the queue id is assigned to the tid_data. This is fine since iwl_mvm_sta_tx_agg_oper() takes care of allocating the queue before actual tx starts. When the reservation is cancelled (e.g. when the AP declined the aggregation request) the tid_data is not cleared. As a result, following tx for this tid was trying to use an unallocated queue. Fix this by setting the txq_id for the tid to invalid when unreserving the queue. Signed-off-by: Avraham Stern Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4eaa2618051aa9621e9ebde6909aab63cbb20134 Author: Andrei Otcheretianski Date: Wed Feb 28 17:18:48 2018 +0200 iwlwifi: mvm: Increase session protection time after CS [ Upstream commit 19125cb0591ae63cd4591e3dfe4c22058e748518 ] After switching to a new channel, driver schedules session protection time event in order to hear the beacon on the new channel. The duration of the protection is two beacon intervals. However, since we start to switch slightly before beacon with count 1, in case we don't hear (or AP doesn't transmit) the very first beacon on the new channel the protection ends without hearing any beacon at all. At this stage the switch is not complete, the queues are closed and the interface doesn't have quota yet or TBTT events. As the result, we are stuck forever waiting for iwl_mvm_post_channel_switch() to be called. Fix this by increasing the protection time to be 3 beacon intervals and in addition drop the connection if the time event ends before we got any beacon. Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b57f0fe6e38b97dc3c2e3836010b8dc3373b1d58 Author: Stefano Brivio Date: Thu Mar 15 17:17:13 2018 +0100 vti6: Fix dev->max_mtu setting [ Upstream commit f8a554b4aa9686bb2c12f6bae516e58783289a03 ] We shouldn't allow a tunnel to have IP_MAX_MTU as MTU, because another IPv6 header is going on top of our packets. Without this patch, we might end up building packets bigger than IP_MAX_MTU. Fixes: b96f9afee4eb ("ipv4/6: use core net MTU range checking") Signed-off-by: Stefano Brivio Acked-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5815901c29c2936d7acbed2683d5807b4ae53ede Author: Stefano Brivio Date: Thu Mar 15 17:16:29 2018 +0100 vti4: Don't override MTU passed on link creation via IFLA_MTU [ Upstream commit 03080e5ec72740c1a62e6730f2a5f3f114f11b19 ] Don't hardcode a MTU value on vti tunnel initialization, ip_tunnel_newlink() is able to deal with this already. See also commit ffc2b6ee4174 ("ip_gre: fix IFLA_MTU ignored on NEWLINK"). Fixes: 1181412c1a67 ("net/ipv4: VTI support new module for ip_vti.") Signed-off-by: Stefano Brivio Acked-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 34b6ba622ac4d5f08238771603de1ff45a2722a0 Author: Stefano Brivio Date: Thu Mar 15 17:16:28 2018 +0100 ip_tunnel: Clamp MTU to bounds on new link [ Upstream commit 24fc79798b8ddfd46f2dd363a8d29072c083b977 ] Otherwise, it's possible to specify invalid MTU values directly on creation of a link (via 'ip link add'). This is already prevented on subsequent MTU changes by commit b96f9afee4eb ("ipv4/6: use core net MTU range checking"). Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Signed-off-by: Stefano Brivio Acked-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e675b292c282e4b9798f5e849983ea1fb03a0b37 Author: Stefano Brivio Date: Thu Mar 15 17:16:27 2018 +0100 vti4: Don't count header length twice on tunnel setup [ Upstream commit dd1df24737727e119c263acf1be2a92763938297 ] This re-introduces the effect of commit a32452366b72 ("vti4: Don't count header length twice.") which was accidentally reverted by merge commit f895f0cfbb77 ("Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec"). The commit message from Steffen Klassert said: We currently count the size of LL_MAX_HEADER and struct iphdr twice for vti4 devices, this leads to a wrong device mtu. The size of LL_MAX_HEADER and struct iphdr is already counted in ip_tunnel_bind_dev(), so don't do it again in vti_tunnel_init(). And this is still the case now: ip_tunnel_bind_dev() already accounts for the header length of the link layer (not necessarily LL_MAX_HEADER, if the output device is found), plus one IP header. For example, with a vti device on top of veth, with MTU of 1500, the existing implementation would set the initial vti MTU to 1332, accounting once for LL_MAX_HEADER (128, included in hard_header_len by vti) and twice for the same IP header (once from hard_header_len, once from ip_tunnel_bind_dev()). It should instead be 1480, because ip_tunnel_bind_dev() is able to figure out that the output device is veth, so no additional link layer header is attached, and will properly count one single IP header. The existing issue had the side effect of avoiding PMTUD for most xfrm policies, by arbitrarily lowering the initial MTU. However, the only way to get a consistent PMTU value is to let the xfrm PMTU discovery do its course, and commit d6af1a31cc72 ("vti: Add pmtu handling to vti_xmit.") now takes care of local delivery cases where the application ignores local socket notifications. Fixes: b9959fd3b0fa ("vti: switch to new ip tunnel code") Fixes: f895f0cfbb77 ("Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec") Signed-off-by: Stefano Brivio Acked-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 87e07eff2772826cb8435a9b69e9bfbbed0efb37 Author: Sven Eckelmann Date: Fri Mar 16 21:14:32 2018 +0100 batman-adv: Fix skbuff rcsum on packet reroute [ Upstream commit fc04fdb2c8a894283259f5621d31d75610701091 ] batadv_check_unicast_ttvn may redirect a packet to itself or another originator. This involves rewriting the ttvn and the destination address in the batadv unicast header. These field were not yet pulled (with skb rcsum update) and thus any change to them also requires a change in the receive checksum. Reported-by: Matthias Schiffer Fixes: a73105b8d4c7 ("batman-adv: improved client announcement mechanism") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f31f64b2d253809b125c3cf597a9bd82ab29a080 Author: Davide Caratti Date: Fri Mar 16 00:00:56 2018 +0100 net/sched: fix NULL dereference in the error path of tcf_sample_init() [ Upstream commit 1f110e7cae09e6c6a144616480d1a9dd99c5208a ] when the following command # tc action add action sample rate 100 group 100 index 100 is run for the first time, and psample_group_get(100) fails to create a new group, tcf_sample_cleanup() calls psample_group_put(NULL), thus causing the following error: BUG: unable to handle kernel NULL pointer dereference at 000000000000001c IP: psample_group_put+0x15/0x71 [psample] PGD 8000000075775067 P4D 8000000075775067 PUD 7453c067 PMD 0 Oops: 0002 [#1] SMP PTI Modules linked in: act_sample(E) psample ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core mbcache jbd2 crct10dif_pclmul snd_hwdep crc32_pclmul snd_seq ghash_clmulni_intel pcbc snd_seq_device snd_pcm aesni_intel crypto_simd snd_timer glue_helper snd cryptd joydev pcspkr i2c_piix4 soundcore virtio_balloon nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm virtio_net ata_piix virtio_console virtio_blk libata serio_raw crc32c_intel virtio_pci i2c_core virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_tunnel_key] CPU: 2 PID: 5740 Comm: tc Tainted: G E 4.16.0-rc4.act_vlan.orig+ #403 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:psample_group_put+0x15/0x71 [psample] RSP: 0018:ffffb8a80032f7d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000024 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffffc06d93c0 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044 R10: 00000000bd003000 R11: ffff979fba04aa59 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff979fbba3f22c FS: 00007f7638112740(0000) GS:ffff979fbfd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 00000000734ea001 CR4: 00000000001606e0 Call Trace: __tcf_idr_release+0x79/0xf0 tcf_sample_init+0x125/0x1d0 [act_sample] tcf_action_init_1+0x2cc/0x430 tcf_action_init+0xd3/0x1b0 tc_ctl_action+0x18b/0x240 rtnetlink_rcv_msg+0x29c/0x310 ? _cond_resched+0x15/0x30 ? __kmalloc_node_track_caller+0x1b9/0x270 ? rtnl_calcit.isra.28+0x100/0x100 netlink_rcv_skb+0xd2/0x110 netlink_unicast+0x17c/0x230 netlink_sendmsg+0x2cd/0x3c0 sock_sendmsg+0x30/0x40 ___sys_sendmsg+0x27a/0x290 ? filemap_map_pages+0x34a/0x3a0 ? __handle_mm_fault+0xbfd/0xe20 __sys_sendmsg+0x51/0x90 do_syscall_64+0x6e/0x1a0 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x7f7637523ba0 RSP: 002b:00007fff0473ef58 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fff0473f080 RCX: 00007f7637523ba0 RDX: 0000000000000000 RSI: 00007fff0473efd0 RDI: 0000000000000003 RBP: 000000005aaaac80 R08: 0000000000000002 R09: 0000000000000000 R10: 00007fff0473e9e0 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff0473f094 R14: 0000000000000001 R15: 0000000000669f60 Code: be 02 00 00 00 48 89 df e8 a9 fe ff ff e9 7c ff ff ff 0f 1f 40 00 0f 1f 44 00 00 53 48 89 fb 48 c7 c7 c0 93 6d c0 e8 db 20 8c ef <83> 6b 1c 01 74 10 48 c7 c7 c0 93 6d c0 ff 14 25 e8 83 83 b0 5b RIP: psample_group_put+0x15/0x71 [psample] RSP: ffffb8a80032f7d0 CR2: 000000000000001c Fix it in tcf_sample_cleanup(), ensuring that calls to psample_group_put(p) are done only when p is not NULL. Fixes: cadb9c9fdbc6 ("net/sched: act_sample: Fix error path in init") Signed-off-by: Davide Caratti Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6b4a3d4e63f1a1a9d333224c082b57bbadcfab17 Author: Matthias Schiffer Date: Fri Mar 16 11:29:10 2018 +0100 batman-adv: fix header size check in batadv_dbg_arp() [ Upstream commit 6f27d2c2a8c236d296201c19abb8533ec20d212b ] Checking for 0 is insufficient: when an SKB without a batadv header, but with a VLAN header is received, hdr_size will be 4, making the following code interpret the Ethernet header as a batadv header. Fixes: be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware") Signed-off-by: Matthias Schiffer Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 99ba9a9728707888b113f00ac8eee4faa6d60431 Author: Toshiaki Makita Date: Tue Mar 13 14:51:28 2018 +0900 vlan: Fix out of order vlan headers with reorder header off [ Upstream commit cbe7128c4b92e2004984f477fd38dfa81662f02e ] With reorder header off, received packets are untagged in skb_vlan_untag() called from within __netif_receive_skb_core(), and later the tag will be inserted back in vlan_do_receive(). This caused out of order vlan headers when we create a vlan device on top of another vlan device, because vlan_do_receive() inserts a tag as the outermost vlan tag. E.g. the outer tag is first removed in skb_vlan_untag() and inserted back in vlan_do_receive(), then the inner tag is next removed and inserted back as the outermost tag. This patch fixes the behaviour by inserting the inner tag at the right position. Signed-off-by: Toshiaki Makita Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 01a68a265ef506e95058c3cd0a8d9e4264eb9233 Author: Toshiaki Makita Date: Tue Mar 13 14:51:27 2018 +0900 net: Fix vlan untag for bridge and vlan_dev with reorder_hdr off [ Upstream commit 4bbb3e0e8239f9079bf1fe20b3c0cb598714ae61 ] When we have a bridge with vlan_filtering on and a vlan device on top of it, packets would be corrupted in skb_vlan_untag() called from br_dev_xmit(). The problem sits in skb_reorder_vlan_header() used in skb_vlan_untag(), which makes use of skb->mac_len. In this function mac_len is meant for handling rx path with vlan devices with reorder_header disabled, but in tx path mac_len is typically 0 and cannot be used, which is the problem in this case. The current code even does not properly handle rx path (skb_vlan_untag() called from __netif_receive_skb_core()) with reorder_header off actually. In rx path single tag case, it works as follows: - Before skb_reorder_vlan_header() mac_header data v v +-------------------+-------------+------+---- | ETH | VLAN | ETH | | ADDRS | TPID | TCI | TYPE | +-------------------+-------------+------+---- <-------- mac_len ---------> <-------------> to be removed - After skb_reorder_vlan_header() mac_header data v v +-------------------+------+---- | ETH | ETH | | ADDRS | TYPE | +-------------------+------+---- <-------- mac_len ---------> This is ok, but in rx double tag case, it corrupts packets: - Before skb_reorder_vlan_header() mac_header data v v +-------------------+-------------+-------------+------+---- | ETH | VLAN | VLAN | ETH | | ADDRS | TPID | TCI | TPID | TCI | TYPE | +-------------------+-------------+-------------+------+---- <--------------- mac_len ----------------> <-------------> should be removed <---------------------------> actually will be removed - After skb_reorder_vlan_header() mac_header data v v +-------------------+------+---- | ETH | ETH | | ADDRS | TYPE | +-------------------+------+---- <--------------- mac_len ----------------> So, two of vlan tags are both removed while only inner one should be removed and mac_header (and mac_len) is broken. skb_vlan_untag() is meant for removing the vlan header at (skb->data - 2), so use skb->data and skb->mac_header to calculate the right offset. Reported-by: Brandon Carpenter Fixes: a6e18ff11170 ("vlan: Fix untag operations of stacked vlans with REORDER_HEADER off") Signed-off-by: Toshiaki Makita Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 000fe789aa763723ec2767b743bfbc598bcc49c3 Author: Johannes Berg Date: Thu Feb 22 13:51:21 2018 +0100 iwlwifi: mvm: fix error checking for multi/broadcast sta [ Upstream commit 75fd4fec3e4c43b131c7c4958adb3ab9f1665513 ] The earlier patch called the station add functions but didn't assign their return value to the ret variable, so that the checks for it were meaningless. Fix that. Found by smatch: .../mac80211.c:2560 iwl_mvm_start_ap_ibss() warn: we tested 'ret' before and it was 'false' .../mac80211.c:2563 iwl_mvm_start_ap_ibss() warn: we tested 'ret' before and it was 'false' Fixes: 3a89411cd31c ("iwlwifi: mvm: fix assert 0x2B00 on older FWs") Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ac2b8f5e361f34b33670d05ef12e0c54167c40e4 Author: Beni Lev Date: Tue Feb 20 13:41:54 2018 +0200 iwlwifi: mvm: Correctly set IGTK for AP [ Upstream commit e829b17caf96c2da34620e335fb777592990906c ] Currently when an IGTK is set for an AP, it is set as a regular key. Since the cipher is set to CMAC, the STA_KEY_FLG_EXT flag is added to the host command, which causes assert 0x253D on NICs that do not support this. Fixes: 85aeb58cec1a ("iwlwifi: mvm: Enable security on new TX API") Signed-off-by: Beni Lev Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 85e5ae55652ec8da9fa39c4bd5ab88f35b280547 Author: Emmanuel Grumbach Date: Thu Feb 15 15:48:09 2018 +0200 iwlwifi: mvm: set the correct tid when we flush the MCAST sta [ Upstream commit 334167decf98f01a66c91ea84180c278bc4ad290 ] The tid being used for the queue (cab_queue) for the MCAST station has been changed recently to be 0 (for BE). The flush path still flushed only the special tid (15) which means that the firmware wasn't flushing the right queue and we could get a firmware crash upon remove station if we had an MCAST packet on the ring. The current code that flushes queues for a station only differentiates between internal stations (stations that aren't instantiated in mac80211, like the MCAST station) and the non-internal ones. Internal stations can be either: BCAST (beacons), MCAST (for cab_queue), GENERAL_PURPOSE (p2p dev, and sniffer injection). The internal stations can use different tids. To make the code simpler, just flush all the tids always and add the special internal tid (15) for internal stations. The firmware will know how to handle this even if we hadn't any queue mapped that that tid. Fixes: e340c1a6ef4b ("iwlwifi: mvm: Correctly set the tid for mcast queue") Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 404cbeb36ef7f67e3c89b977df8c563dd1b92e96 Author: Taehee Yoo Date: Fri Mar 16 11:35:51 2018 +0900 xfrm: fix rcu_read_unlock usage in xfrm_local_error [ Upstream commit 46c0ef6e1eb95f619d9f62da4332749153db92f7 ] In the xfrm_local_error, rcu_read_unlock should be called when afinfo is not NULL. because xfrm_state_get_afinfo calls rcu_read_unlock if afinfo is NULL. Fixes: af5d27c4e12b ("xfrm: remove xfrm_state_put_afinfo") Signed-off-by: Taehee Yoo Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 942138f356aab8371545f2331e015599e45a7d0b Author: Karol Herbst Date: Mon Feb 19 17:09:45 2018 +0100 drm/nouveau/bl: fix backlight regression [ Upstream commit 9e75dc61eaa9acd1bff83c3b814ac2af6dc1f64c ] Fixes: 3c66c87dc9 ("drm/nouveau/disp: remove hw-specific customisation of output paths") Suggested-by: Ben Skeggs Signed-off-by: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 872398068503bfb5eb58f5ff5aaac38c3cea41d8 Author: Lucas Stach Date: Thu Mar 15 10:11:59 2018 +0100 drm/imx: move arming of the vblank event to atomic_flush [ Upstream commit 6a055b92de15af987b4027826d43aa103c65a3c4 ] Right now the vblank event completion is racing with the atomic update, which is especially bad when the PRE is in use, as one of the hardware issue workaround might extend the atomic commit for quite some time. If the vblank IRQ happens to trigger during that time, we will prematurely signal the atomic commit completion to userspace, which causes tearing when userspace re-uses a framebuffer we haven't managed to flip away from yet. Signed-off-by: Lucas Stach Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 418c85ea458a01522a2a61f5fd111043940b8e4e Author: Arnd Bergmann Date: Thu Mar 15 17:19:57 2018 +0100 gpu: ipu-v3: prg: avoid possible array underflow [ Upstream commit 746d024c3211813946b319411aeb2b47767f8fb0 ] gcc-8 reports that we access an array with a negative index in an error case: drivers/gpu/ipu-v3/ipu-prg.c: In function 'ipu_prg_channel_disable': drivers/gpu/ipu-v3/ipu-prg.c:252:43: error: array subscript -22 is below array bounds of 'struct ipu_prg_channel[3]' [-Werror=array-bounds] This moves the range check in front of the first time that variable gets used. Signed-off-by: Arnd Bergmann Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 05c401183c2f55c96354be2a1174f8ae297ac1d2 Author: Andre Przywara Date: Tue Mar 6 09:21:06 2018 +0000 KVM: arm/arm64: vgic: Add missing irq_lock to vgic_mmio_read_pending [ Upstream commit 62b06f8f429cd233e4e2e7bbd21081ad60c9018f ] Our irq_is_pending() helper function accesses multiple members of the vgic_irq struct, so we need to hold the lock when calling it. Add that requirement as a comment to the definition and take the lock around the call in vgic_mmio_read_pending(), where we were missing it before. Fixes: 96b298000db4 ("KVM: arm/arm64: vgic-new: Add PENDING registers handlers") Signed-off-by: Andre Przywara Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ef5b2e5241a2b74b9a8f6386eb742d2e42ad826 Author: Cathy Zhou Date: Wed Mar 14 10:56:07 2018 -0700 sunvnet: does not support GSO for sctp [ Upstream commit cf55612a945039476abfd73e39064b2e721c3272 ] The NETIF_F_GSO_SOFTWARE implies support for GSO on SCTP, but the sunvnet driver does not support GSO for sctp. Here we remove the NETIF_F_GSO_SOFTWARE feature flag and only report NETIF_F_ALL_TSO instead. Signed-off-by: Cathy Zhou Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8387fbac8e18e26a60559adc63e0b7067303b0a4 Author: Sabrina Dubroca Date: Wed Mar 14 10:21:14 2018 +0100 ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu [ Upstream commit d52e5a7e7ca49457dd31fc8b42fb7c0d58a31221 ] Prior to the rework of PMTU information storage in commit 2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer."), when a PMTU event advertising a PMTU smaller than net.ipv4.route.min_pmtu was received, we would disable setting the DF flag on packets by locking the MTU metric, and set the PMTU to net.ipv4.route.min_pmtu. Since then, we don't disable DF, and set PMTU to net.ipv4.route.min_pmtu, so the intermediate router that has this link with a small MTU will have to drop the packets. This patch reestablishes pre-2.6.39 behavior by splitting rtable->rt_pmtu into a bitfield with rt_mtu_locked and rt_pmtu. rt_mtu_locked indicates that we shouldn't set the DF bit on that path, and is checked in ip_dont_fragment(). One possible workaround is to set net.ipv4.route.min_pmtu to a value low enough to accommodate the lowest MTU encountered. Fixes: 2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer.") Signed-off-by: Sabrina Dubroca Reviewed-by: Stefano Brivio Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7c84e5e9c62cec8a3c49bf32ddabf2f285cb371b Author: Arvind Yadav Date: Tue Mar 6 15:35:43 2018 +0530 workqueue: use put_device() instead of kfree() [ Upstream commit 537f4146c53c95aac977852b371bafb9c6755ee1 ] Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized in this function instead. Signed-off-by: Arvind Yadav Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 845c2de9578675a0969fd76162b53561938b39aa Author: Michael Chan Date: Fri Mar 9 23:46:10 2018 -0500 bnxt_en: Check valid VNIC ID in bnxt_hwrm_vnic_set_tpa(). [ Upstream commit 3c4fe80b32c685bdc02b280814d0cfe80d441c72 ] During initialization, if we encounter errors, there is a code path that calls bnxt_hwrm_vnic_set_tpa() with invalid VNIC ID. This may cause a warning in firmware logs. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27eebf0800cf12e178aed4526eb95e814eb4de5c Author: Bich HEMON Date: Mon Mar 12 08:52:37 2018 +0000 can: m_can: select pinctrl state in each suspend/resume function [ Upstream commit c9b3bce18da4a0aebc27853052dea39aa64b7d75 ] Make sure to apply the correct pin state in suspend/resume callbacks. Putting pins in sleep state saves power. Signed-off-by: Bich Hemon Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27fe367cdde0c49c5147ff397ca59fc4a09551de Author: Wolfram Sang Date: Tue Feb 6 09:52:07 2018 +0100 can: m_can: change comparison to bitshift when dealing with a mask [ Upstream commit b7db978ac283b237835129ac87f26cbac94d04e7 ] Due to a typo, the mask was destroyed by a comparison instead of a bit shift. Reported-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 533f5f847dfdfc76d965ecbeb0e5f572e015c524 Author: Florian Westphal Date: Thu Mar 8 12:54:19 2018 +0100 netfilter: ebtables: fix erroneous reject of last rule [ Upstream commit 932909d9b28d27e807ff8eecb68c7748f6701628 ] The last rule in the blob has next_entry offset that is same as total size. This made "ebtables32 -A OUTPUT -d de:ad:be:ef:01:02" fail on 64 bit kernel. Fixes: b71812168571fa ("netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2299285fb1819ef8459c116fd1eafe1458bb9ca1 Author: Gregory CLEMENT Date: Wed Mar 7 16:40:10 2018 +0100 dmaengine: mv_xor_v2: Fix clock resource by adding a register clock [ Upstream commit 3cd2c313f1d618f92d1294addc6c685c17065761 ] On the CP110 components which are present on the Armada 7K/8K SoC we need to explicitly enable the clock for the registers. However it is not needed for the AP8xx component, that's why this clock is optional. With this patch both clock have now a name, but in order to be backward compatible, the name of the first clock is not used. It allows to still use this clock with a device tree using the old binding. Reviewed-by: Rob Herring Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e2d9442dfe84062d9fdb96b0a755013fc5c2fa6d Author: Luis R. Rodriguez Date: Fri Mar 9 15:51:20 2018 -0800 lib/test_kmod.c: fix limit check on number of test devices created [ Upstream commit ac68b1b3b9c73e652dc7ce0585672e23c5a2dca4 ] As reported by Dan the parentheses is in the wrong place, and since unlikely() call returns either 0 or 1 it's never less than zero. The second issue is that signed integer overflows like "INT_MAX + 1" are undefined behavior. Since num_test_devs represents the number of devices, we want to stop prior to hitting the max, and not rely on the wrap arround at all. So just cap at num_test_devs + 1, prior to assigning a new device. Link: http://lkml.kernel.org/r/20180224030046.24238-1-mcgrof@kernel.org Fixes: d9c6a72d6fa2 ("kmod: add test driver to stress test the module loader") Reported-by: Dan Carpenter Signed-off-by: Luis R. Rodriguez Acked-by: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 21ccc62ec7259f3c33dc18b895ff8550a8b16b32 Author: Li Zhijian Date: Fri Mar 9 15:51:16 2018 -0800 selftests/vm/run_vmtests: adjust hugetlb size according to nr_cpus [ Upstream commit 0627be7d3c871035364923559543c9b2ff5357f2 ] Fix userfaultfd_hugetlb on hosts which have more than 64 cpus. --------------------------- running userfaultfd_hugetlb --------------------------- invalid MiB Usage: [FAIL] Via userfaultfd.c we can know, hugetlb_size needs to meet hugetlb_size >= nr_cpus * hugepage_size. hugepage_size is often 2M, so when host cpus > 64, it requires more than 128M. [zhijianx.li@intel.com: update changelog/comments and variable name] Link: http://lkml.kernel.org/r/20180302024356.83359-1-zhijianx.li@intel.com Link: http://lkml.kernel.org/r/20180303125027.81638-1-zhijianx.li@intel.com Link: http://lkml.kernel.org/r/20180302024356.83359-1-zhijianx.li@intel.com Signed-off-by: Li Zhijian Cc: Shuah Khan Cc: SeongJae Park Cc: Philippe Ombredanne Cc: Aneesh Kumar K.V Cc: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bad682e26d6a0345cc0c12dabb340e2545f135ad Author: Marc Zyngier Date: Fri Mar 9 15:40:50 2018 +0000 arm64: Relax ARM_SMCCC_ARCH_WORKAROUND_1 discovery [ Upstream commit e21da1c992007594d391e7b301779cf30f438691 ] A recent update to the ARM SMCCC ARCH_WORKAROUND_1 specification allows firmware to return a non zero, positive value to describe that although the mitigation is implemented at the higher exception level, the CPU on which the call is made is not affected. Let's relax the check on the return value from ARCH_WORKAROUND_1 so that we only error out if the returned value is negative. Fixes: b092201e0020 ("arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support") Signed-off-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 341029c2024ba907462a494517b14487c254e264 Author: Bartosz Golaszewski Date: Thu Mar 1 11:34:48 2018 +0100 ARM: davinci: fix the GPIO lookup for omapl138-hawk [ Upstream commit c4dc56be7e26040bfc60ce73425353516a356955 ] The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that mmc can correctly lookup the wp and cp gpios. Note that it is the gpio-davinci driver that sets the gpiochip label to davinci_gpio.0. Fixes: c69f43fb4f26 ("ARM: davinci: hawk: use gpio descriptor for mmc pins") Signed-off-by: Bartosz Golaszewski [nsekhar@ti.com: add a note on where the chip label is set] Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b7f1129a2c77f1dacd413a822fec90e2922855f8 Author: Stephen Hemminger Date: Wed Mar 7 13:49:12 2018 -0800 hv_netvsc: fix locking during VF setup [ Upstream commit b0dee7910317f41f398838992516af6a3b981d86 ] The dev_uc/mc_sync calls need to have the device address list locked. This was spotted by running with lockdep enabled. Fixes: bee9d41b37ea ("hv_netvsc: propagate rx filters to VF") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b37bc05f44c6b4b7cb25583f8c5c85b81d6eb9e0 Author: Stephen Hemminger Date: Wed Mar 7 13:49:11 2018 -0800 hv_netvsc: fix locking for rx_mode [ Upstream commit 35a57b7fef136fa3d5b735ba773f191b95110fa0 ] The rx_mode operation handler is different than other callbacks in that is not always called with rtnl held. Therefore use RCU to ensure that references are valid. Fixes: bee9d41b37ea ("hv_netvsc: propagate rx filters to VF") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9241c4f472054a46605d0a820e3b93fa59c23406 Author: Stephen Hemminger Date: Wed Mar 7 13:49:09 2018 -0800 hv_netvsc: fix filter flags [ Upstream commit de3d50aadd40bf68614db9fd157b275ce9c2d467 ] The recent change to not always enable all multicast and broadcast was broken; meant to set filter, not change flags. Fixes: 009f766ca238 ("hv_netvsc: filter multicast/broadcast") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7f2b054916fcc02ebbaafdb4dc8aa7af579ebb7 Author: Arvind Yadav Date: Tue Mar 6 15:40:37 2018 +0530 xen: xenbus: use put_device() instead of kfree() [ Upstream commit 351b2bccede1cb673ec7957b35ea997ea24c8884 ] Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9238d1fa3ee60e26909b5ca38e4fbfcd1dbc2201 Author: Bhavesh Davda Date: Fri Dec 22 14:17:13 2017 -0800 xen-blkfront: move negotiate_mq to cover all cases of new VBDs [ Upstream commit 7ed8ce1c5fc7cf25b3602c73bef897a3466a6645 ] negotiate_mq should happen in all cases of a new VBD being discovered by xen-blkfront, whether called through _probe() or a hot-attached new VBD from dom-0 via xenstore. Otherwise, hot-attached new VBDs are left configured without multi-queue. Signed-off-by: Bhavesh Davda Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b2709f78674177e9e8670132eaa73977cf61582a Author: Ganesh Goudar Date: Wed Mar 7 13:10:24 2018 +0530 cxgb4: do not set needs_free_netdev for mgmt dev's [ Upstream commit b06ef18a4c255609388ed6e068a1c69c797545e0 ] Do not set 'needs_free_netdev' as we do call free_netdev for mgmt net devices, doing both hits BUG_ON. Signed-off-by: Ganesh Goudar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba5b9b64e883fdae2db278c2c0b5670e9838d062 Author: Parav Pandit Date: Wed Mar 7 08:07:41 2018 +0200 IB/core: Fix possible crash to access NULL netdev [ Upstream commit bb7f8f199c354c4cf155b1d6d55f86eaaed7fa5a ] resolved_dev returned might be NULL as ifindex is transient number. Ignoring NULL check of resolved_dev might crash the kernel. Therefore perform NULL check before accessing resolved_dev. Additionally rdma_resolve_ip_route() invokes addr_resolve() which performs check and address translation for loopback ifindex. Therefore, checking it again in rdma_resolve_ip_route() is not helpful. Therefore, the code is simplified to avoid IFF_LOOPBACK check. Fixes: 200298326b27 ("IB/core: Validate route when we init ah") Reviewed-by: Daniel Jurgens Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7ae100c413931659f9c89e1320066458a6a2bf1d Author: Jeremy Linton Date: Tue Mar 6 09:00:06 2018 -0600 net: smsc911x: Fix unload crash when link is up [ Upstream commit e06513d78d54e6c7026c9043a39e2c01ee25bdbe ] The smsc911x driver will crash if it is rmmod'ed while the netdev is up like: Call trace: phy_detach+0x94/0x150 phy_disconnect+0x40/0x50 smsc911x_stop+0x104/0x128 [smsc911x] __dev_close_many+0xb4/0x138 dev_close_many+0xbc/0x190 rollback_registered_many+0x140/0x460 rollback_registered+0x68/0xb0 unregister_netdevice_queue+0x100/0x118 unregister_netdev+0x28/0x38 smsc911x_drv_remove+0x58/0x130 [smsc911x] platform_drv_remove+0x30/0x50 device_release_driver_internal+0x15c/0x1f8 driver_detach+0x54/0x98 bus_remove_driver+0x64/0xe8 driver_unregister+0x34/0x60 platform_driver_unregister+0x20/0x30 smsc911x_cleanup_module+0x14/0xbca8 [smsc911x] SyS_delete_module+0x1e8/0x238 __sys_trace_return+0x0/0x4 This is caused by the mdiobus being unregistered/free'd and the code in phy_detach() attempting to manipulate mdio related structures from unregister_netdev() calling close() To fix this, we delay the mdiobus teardown until after the netdev is deregistered. Reported-by: Matt Sealey Signed-off-by: Jeremy Linton Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a2b2d6ae5a3f8cb49b7533d3f450bc3be0c3c2bc Author: Hemanth Puranik Date: Tue Mar 6 08:18:06 2018 +0530 net: qcom/emac: Use proper free methods during TX [ Upstream commit cc5db3150e87fe7f7e947bf333b6c1c97f848ecb ] This patch fixes the warning messages/call traces seen if DMA debug is enabled, In case of fragmented skb's memory was allocated using dma_map_page but freed using dma_unmap_single. This patch modifies buffer allocations in TX path to use dma_map_page in all the places and dma_unmap_page while freeing the buffers. Signed-off-by: Hemanth Puranik Acked-by: Timur Tabi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c6ce72d59cab7c3e5d0224773e0cd9cfa523e20a Author: Michal Kalderon Date: Mon Mar 5 23:50:46 2018 +0200 qed: Free RoCE ILT Memory on rmmod qedr [ Upstream commit 9de506a547c0d172d13a91d69b1a399e6a2c0efa ] Rdma requires ILT Memory to be allocated for it's QPs. Each ILT entry points to a page used by several Rdma QPs. To avoid allocating all the memory in advance, the rdma implementation dynamically allocates memory as more QPs are added, however it does not dynamically free the memory. The memory should have been freed on rmmod qedr, but isn't. This patch adds the memory freeing on rmmod qedr (currently it will be freed with qed is removed). An outcome of this bug, is that if qedr is unloaded and loaded without unloaded qed, there will be no more RoCE traffic. The reason these are related, is that the logic of detecting the first QP ever opened is by asking whether ILT memory for RoCE has been allocated. In addition, this patch modifies freeing of the Task context to always use the PROTOCOLID_ROCE and not the protocol passed, this is because task context for iWARP and ROCE both use the ROCE protocol id, as opposed to the connection context. Fixes: dbb799c39717 ("qed: Initialize hardware for new protocols") Signed-off-by: Michal Kalderon Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7538ab34136d9dc2ca2ead75edf130fe8051e9dc Author: Denis Kirjanov Date: Sun Mar 4 21:48:17 2018 +0300 fsl/fman: avoid sleeping in atomic context while adding an address [ Upstream commit 803fafbe0cd522fa6b9e41ca3b96cfb2e2a2222d ] __dev_mc_add grabs an adress spinlock so use atomic context in kmalloc. / # ifconfig eth0 inet 192.168.0.111 [ 89.331622] BUG: sleeping function called from invalid context at mm/slab.h:420 [ 89.339002] in_atomic(): 1, irqs_disabled(): 0, pid: 1035, name: ifconfig [ 89.345799] 2 locks held by ifconfig/1035: [ 89.349908] #0: (rtnl_mutex){+.+.}, at: [<(ptrval)>] devinet_ioctl+0xc0/0x8a0 [ 89.357258] #1: (_xmit_ETHER){+...}, at: [<(ptrval)>] __dev_mc_add+0x28/0x80 [ 89.364520] CPU: 1 PID: 1035 Comm: ifconfig Not tainted 4.16.0-rc3-dirty #8 [ 89.371464] Call Trace: [ 89.373908] [e959db60] [c066f948] dump_stack+0xa4/0xfc (unreliable) [ 89.380177] [e959db80] [c00671d8] ___might_sleep+0x248/0x280 [ 89.385833] [e959dba0] [c01aec34] kmem_cache_alloc_trace+0x174/0x320 [ 89.392179] [e959dbd0] [c04ab920] dtsec_add_hash_mac_address+0x130/0x240 [ 89.398874] [e959dc00] [c04a9d74] set_multi+0x174/0x1b0 [ 89.404093] [e959dc30] [c04afb68] dpaa_set_rx_mode+0x68/0xe0 [ 89.409745] [e959dc40] [c057baf8] __dev_mc_add+0x58/0x80 [ 89.415052] [e959dc60] [c060fd64] igmp_group_added+0x164/0x190 [ 89.420878] [e959dca0] [c060ffa8] ip_mc_inc_group+0x218/0x460 [ 89.426617] [e959dce0] [c06120fc] ip_mc_up+0x3c/0x190 [ 89.431662] [e959dd10] [c0607270] inetdev_event+0x250/0x620 [ 89.437227] [e959dd50] [c005f190] notifier_call_chain+0x80/0xf0 [ 89.443138] [e959dd80] [c0573a74] __dev_notify_flags+0x54/0xf0 [ 89.448964] [e959dda0] [c05743f8] dev_change_flags+0x48/0x60 [ 89.454615] [e959ddc0] [c0606744] devinet_ioctl+0x544/0x8a0 [ 89.460180] [e959de10] [c060987c] inet_ioctl+0x9c/0x1f0 [ 89.465400] [e959de80] [c05479a8] sock_ioctl+0x168/0x460 [ 89.470708] [e959ded0] [c01cf3ec] do_vfs_ioctl+0xac/0x8c0 [ 89.476099] [e959df20] [c01cfc40] SyS_ioctl+0x40/0xc0 [ 89.481147] [e959df40] [c0011318] ret_from_syscall+0x0/0x3c [ 89.486715] --- interrupt: c01 at 0x1006943c [ 89.486715] LR = 0x100c45ec Signed-off-by: Denis Kirjanov Acked-by: Madalin Bucur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ccf92117d49d77f3d88ad81d63ea5c0d02a94e3f Author: Peter Malone Date: Wed Mar 7 14:00:34 2018 +0100 fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper(). [ Upstream commit 250c6c49e3b68756b14983c076183568636e2bde ] Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper(). 'index' is defined as an int in sbusfb_ioctl_helper(). We retrieve this from the user: if (get_user(index, &c->index) || __get_user(count, &c->count) || __get_user(ured, &c->red) || __get_user(ugreen, &c->green) || __get_user(ublue, &c->blue)) return -EFAULT; and then we use 'index' in the following way: red = cmap->red[index + i] >> 8; green = cmap->green[index + i] >> 8; blue = cmap->blue[index + i] >> 8; This is a classic information leak vulnerability. 'index' should be an unsigned int, given its usage above. This patch is straight-forward; it changes 'index' to unsigned int in two switch-cases: FBIOGETCMAP_SPARC && FBIOPUTCMAP_SPARC. This patch fixes CVE-2018-6412. Signed-off-by: Peter Malone Acked-by: Mathieu Malaterre Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 175e365a66624fd67f32e354755a2e689c736ee1 Author: Dan Carpenter Date: Tue Mar 6 13:00:31 2018 +0300 IB/mlx5: Fix an error code in __mlx5_ib_modify_qp() [ Upstream commit 5d414b178e950ce9685c253994cc730893d5d887 ] "err" is either zero or possibly uninitialized here. It should be -EINVAL. Fixes: 427c1e7bcd7e ("{IB, net}/mlx5: Move the modify QP operation table to mlx5_ib") Signed-off-by: Dan Carpenter Acked-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5759427a0ca87ea5a39c10f60420768416d9d468 Author: Jack M Date: Mon Mar 5 20:09:46 2018 +0200 IB/mlx4: Include GID type when deleting GIDs from HW table under RoCE [ Upstream commit a18177925c252da7801149abe217c05b80884798 ] The commit cited below added a gid_type field (RoCEv1 or RoCEv2) to GID properties. When adding GIDs, this gid_type field was copied over to the hardware gid table. However, when deleting GIDs, the gid_type field was not copied over to the hardware gid table. As a result, when running RoCEv2, all RoCEv2 gids in the hardware gid table were set to type RoCEv1 when any gid was deleted. This problem would persist until the next gid was added (which would again restore the gid_type field for all the gids in the hardware gid table). Fix this by copying over the gid_type field to the hardware gid table when deleting gids, so that the gid_type of all remaining gids is preserved when a gid is deleted. Fixes: b699a859d17b ("IB/mlx4: Add gid_type to GID properties") Reviewed-by: Moni Shoua Signed-off-by: Jack Morgenstein Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9636bbd409ba1df2c2cc69d12933f2107a92ab02 Author: Jack Morgenstein Date: Mon Mar 5 20:09:45 2018 +0200 IB/mlx4: Fix corruption of RoCEv2 IPv4 GIDs [ Upstream commit 0077416a3d529baccbe07ab3242e8db541cfadf6 ] When using IPv4 addresses in RoCEv2, the GID format for the mapped IPv4 address should be: ::ffff:<4-byte IPv4 address>. In the cited commit, IPv4 mapped IPV6 addresses had the 3 upper dwords zeroed out by memset, which resulted in deleting the ffff field. However, since procedure ipv6_addr_v4mapped() already verifies that the gid has format ::ffff:, no change is needed for the gid, and the memset can simply be removed. Fixes: 7e57b85c444c ("IB/mlx4: Add support for setting RoCEv2 gids in hardware") Reviewed-by: Moni Shoua Signed-off-by: Jack Morgenstein Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7b10604ddf519affe0cf56dee1169523d7e060c3 Author: Kalderon, Michal Date: Mon Mar 5 10:50:11 2018 +0200 RDMA/qedr: Fix iWARP write and send with immediate [ Upstream commit 551e1c67b4207455375a2e7a285dea1c7e8fc361 ] iWARP does not support RDMA WRITE or SEND with immediate data. Driver should check this before submitting to FW and return an immediate error Signed-off-by: Michal Kalderon Signed-off-by: Ariel Elior Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 40fe662649beff1050201b5a1e47acfe824e6624 Author: Kalderon, Michal Date: Mon Mar 5 10:50:10 2018 +0200 RDMA/qedr: Fix kernel panic when running fio over NFSoRDMA [ Upstream commit e3fd112cbf21d049faf64ba1471d72b93c22109a ] Race in qedr_poll_cq, lastest_cqe wasn't protected by lock, leading to a case where two context's accessing poll_cq at the same time lead to one of them having a pointer to an old latest_cqe and reading an invalid cqe element Signed-off-by: Amit Radzi Signed-off-by: Michal Kalderon Signed-off-by: Ariel Elior Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 87bcb00aa934e6e48d462dc32e82995d208a7a24 Author: Davidlohr Bueso Date: Mon Jan 22 09:21:37 2018 -0800 ia64/err-inject: Use get_user_pages_fast() [ Upstream commit 69c907022a7d9325cdc5c9dd064571e445df9a47 ] At the point of sysfs callback, the call to gup is done without mmap_sem (or any lock for that matter). This is racy. As such, use the get_user_pages_fast() alternative and safely avoid taking the lock, if possible. Signed-off-by: Davidlohr Bueso Signed-off-by: Tony Luck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d98ba4f4567ddbd0b4c8b982a43875d39fa46104 Author: Pierre-Yves Kerbrat Date: Fri Jan 26 11:24:12 2018 +0100 e1000e: allocate ring descriptors with dma_zalloc_coherent [ Upstream commit aea3fca005fb45f80869f2e8d56fd4e64c1d1fdb ] Descriptor rings were not initialized at zero when allocated When area contained garbage data, it caused skb_over_panic in e1000_clean_rx_irq (if data had E1000_RXD_STAT_DD bit set) This patch makes use of dma_zalloc_coherent to make sure the ring is memset at 0 to prevent the area from containing garbage. Following is the signature of the panic: IODDR0@0.0: skbuff: skb_over_panic: text:80407b20 len:64010 put:64010 head:ab46d800 data:ab46d842 tail:0xab47d24c end:0xab46df40 dev:eth0 IODDR0@0.0: BUG: failure at net/core/skbuff.c:105/skb_panic()! IODDR0@0.0: Kernel panic - not syncing: BUG! IODDR0@0.0: IODDR0@0.0: Process swapper/0 (pid: 0, threadinfo=81728000, task=8173cc00 ,cpu: 0) IODDR0@0.0: SP = <815a1c0c> IODDR0@0.0: Stack: 00000001 IODDR0@0.0: b2d89800 815e33ac IODDR0@0.0: ea73c040 00000001 IODDR0@0.0: 60040003 0000fa0a IODDR0@0.0: 00000002 IODDR0@0.0: IODDR0@0.0: 804540c0 815a1c70 IODDR0@0.0: b2744000 602ac070 IODDR0@0.0: 815a1c44 b2d89800 IODDR0@0.0: 8173cc00 815a1c08 IODDR0@0.0: IODDR0@0.0: 00000006 IODDR0@0.0: 815a1b50 00000000 IODDR0@0.0: 80079434 00000001 IODDR0@0.0: ab46df40 b2744000 IODDR0@0.0: b2d89800 IODDR0@0.0: IODDR0@0.0: 0000fa0a 8045745c IODDR0@0.0: 815a1c88 0000fa0a IODDR0@0.0: 80407b20 b2789f80 IODDR0@0.0: 00000005 80407b20 IODDR0@0.0: IODDR0@0.0: IODDR0@0.0: Call Trace: IODDR0@0.0: [<804540bc>] skb_panic+0xa4/0xa8 IODDR0@0.0: [<80079430>] console_unlock+0x2f8/0x6d0 IODDR0@0.0: [<80457458>] skb_put+0xa0/0xc0 IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8 IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8 IODDR0@0.0: [<804079c8>] e1000_clean_rx_irq+0x188/0x3e8 IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8 IODDR0@0.0: [<80468b48>] __dev_kfree_skb_any+0x88/0xa8 IODDR0@0.0: [<804101ac>] e1000e_poll+0x94/0x288 IODDR0@0.0: [<8046e9d4>] net_rx_action+0x19c/0x4e8 IODDR0@0.0: ... IODDR0@0.0: Maximum depth to print reached. Use kstack= To specify a custom value (where 0 means to display the full backtrace) IODDR0@0.0: ---[ end Kernel panic - not syncing: BUG! Signed-off-by: Pierre-Yves Kerbrat Signed-off-by: Marius Gligor Tested-by: Aaron Brown Reviewed-by: Alexander Duyck Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d1355ae4c345454f749b1cd54a8d201ac20ca270 Author: Benjamin Poirier Date: Tue Feb 20 15:12:00 2018 +0900 e1000e: Fix check_for_link return value with autoneg off [ Upstream commit 4e7dc08e57c95673d2edaba8983c3de4dd1f65f5 ] When autoneg is off, the .check_for_link callback functions clear the get_link_status flag and systematically return a "pseudo-error". This means that the link is not detected as up until the next execution of the e1000_watchdog_task() 2 seconds later. Fixes: 19110cfbb34d ("e1000e: Separate signaling for link check/link up") Signed-off-by: Benjamin Poirier Acked-by: Sasha Neftin Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f766148e47d7d3b8a7128cae511971c0f793e38e Author: Jiri Olsa Date: Fri Mar 2 17:13:54 2018 +0100 perf record: Fix crash in pipe mode [ Upstream commit ad46e48c65fa1f204fa29eaff1b91174d314a94b ] Currently we can crash perf record when running in pipe mode, like: $ perf record ls | perf report # To display the perf.data header info, please use --header/--header-only options. # perf: Segmentation fault Error: The - file has no samples! The callstack of the crash is: 0x0000000000515242 in perf_event__synthesize_event_update_name 3513 ev = event_update_event__new(len + 1, PERF_EVENT_UPDATE__NAME, evsel->id[0]); (gdb) bt #0 0x0000000000515242 in perf_event__synthesize_event_update_name #1 0x00000000005158a4 in perf_event__synthesize_extra_attr #2 0x0000000000443347 in record__synthesize #3 0x00000000004438e3 in __cmd_record #4 0x000000000044514e in cmd_record #5 0x00000000004cbc95 in run_builtin #6 0x00000000004cbf02 in handle_internal_command #7 0x00000000004cc054 in run_argv #8 0x00000000004cc422 in main The reason of the crash is that the evsel does not have ids array allocated and the pipe's synthesize code tries to access it. We don't force evsel ids allocation when we have single event, because it's not needed. However we need it when we are in pipe mode even for single event as a key for evsel update event. Fixing this by forcing evsel ids allocation event for single event, when we are in pipe mode. Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20180302161354.30192-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8997115bf7917677399b638a29f8eb44f42ceef6 Author: Rob Herring Date: Thu Mar 1 14:25:35 2018 -0600 ARM: dts: rockchip: Add missing #sound-dai-cells on rk3288 [ Upstream commit 4e943a890cef42e90f43ce6be64728a290b97c55 ] dtc now gives the following warning: arch/arm/boot/dts/rk3288-tinker.dtb: Warning (sound_dai_property): /sound/simple-audio-card,codec: Missing property '#sound-dai-cells' in node /hdmi@ff980000 or bad phandle (referred from sound-dai[0]) Add the missing #sound-dai-cells property. Cc: Heiko Stuebner Cc: linux-rockchip@lists.infradead.org Signed-off-by: Rob Herring Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a0cc3c18d34cdd474ebdb0f6bb4f3408b6223ce0 Author: Stephen Hemminger Date: Fri Mar 2 13:49:09 2018 -0800 hv_netvsc: propagate rx filters to VF [ Upstream commit bee9d41b37ea6b1f860e5bc0989cf1cf1d7e6ab3 ] The netvsc device should propagate filters to the SR-IOV VF device (if present). The flags also need to be propagated to the VF device as well. This only really matters on local Hyper-V since Azure does not support multiple addresses. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ed85935eeafbc847ffcf38caa60d1ffd9cc95a51 Author: Stephen Hemminger Date: Fri Mar 2 13:49:08 2018 -0800 hv_netvsc: filter multicast/broadcast [ Upstream commit 009f766ca2383d8788acd65c2c36c51bbfb19470 ] The netvsc driver was always enabling all multicast and broadcast even if netdevice flag had not enabled it. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c039c53d19521540b494fb4ae7d5269dcf91ef99 Author: Stephen Hemminger Date: Fri Mar 2 13:49:06 2018 -0800 hv_netvsc: use napi_schedule_irqoff [ Upstream commit 68633edaef655ce94e51088ecef5dd4e1d2f6f34 ] Since the netvsc_channel_cb is already called in interrupt context from vmbus, there is no need to do irqsave/restore. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f8156fd34cf7d10a70f147130bc565857621732 Author: Linus Lüssing Date: Sun Mar 4 13:08:17 2018 +0100 batman-adv: Fix multicast packet loss with a single WANT_ALL_IPV4/6 flag [ Upstream commit 74c12c630fe310eb7fcae1b292257d47781fff0a ] As the kernel doc describes too the code is supposed to skip adding multicast TT entries if both the WANT_ALL_IPV4 and WANT_ALL_IPV6 flags are present. Unfortunately, the current code even skips adding multicast TT entries if only either the WANT_ALL_IPV4 or WANT_ALL_IPV6 is present. This could lead to IPv6 multicast packet loss if only an IGMP but not an MLD querier is present for instance or vice versa. Fixes: 687937ab3489 ("batman-adv: Add multicast optimization support for bridged setups") Signed-off-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 73ecd80bca2bab39fd926aadf2a0665ee25e026e Author: Jayachandran C Date: Wed Feb 28 02:52:20 2018 -0800 watchdog: sbsa: use 32-bit read for WCV [ Upstream commit 93ac3deb7c220cbcec032a967220a1f109d58431 ] According to SBSA spec v3.1 section 5.3: All registers are 32 bits in size and should be accessed using 32-bit reads and writes. If an access size other than 32 bits is used then the results are IMPLEMENTATION DEFINED. [...] The Generic Watchdog is little-endian The current code uses readq to read the watchdog compare register which does a 64-bit access. This fails on ThunderX2 which does not implement 64-bit access to this register. Fix this by using lo_hi_readq() that does two 32-bit reads. Signed-off-by: Jayachandran C Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 49995a2931bba15fd53879ec3c8116f6d3644dca Author: Igor Pylypiv Date: Wed Feb 28 00:59:12 2018 -0800 watchdog: f71808e_wdt: Fix magic close handling [ Upstream commit 7bd3e7b743956afbec30fb525bc3c5e22e3d475c ] Watchdog close is "expected" when any byte is 'V' not just the last one. Writing "V" to the device fails because the last byte is the end of string. $ echo V > /dev/watchdog f71808e_wdt: Unexpected close, not stopping watchdog! Signed-off-by: Igor Pylypiv Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 266675ab52db3cfbf1de8747d9cf1445dafbc436 Author: Ka-Cheong Poon Date: Thu Mar 1 21:07:18 2018 -0800 rds: Incorrect reference counting in TCP socket creation [ Upstream commit 84eef2b2187ed73c0e4520cbfeb874e964a0b56a ] Commit 0933a578cd55 ("rds: tcp: use sock_create_lite() to create the accept socket") has a reference counting issue in TCP socket creation when accepting a new connection. The code uses sock_create_lite() to create a kernel socket. But it does not do __module_get() on the socket owner. When the connection is shutdown and sock_release() is called to free the socket, the owner's reference count is decremented and becomes incorrect. Note that this bug only shows up when the socket owner is configured as a kernel module. v2: Update comments Fixes: 0933a578cd55 ("rds: tcp: use sock_create_lite() to create the accept socket") Signed-off-by: Ka-Cheong Poon Acked-by: Santosh Shilimkar Acked-by: Sowmini Varadhan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2b6e7f2ff81a612cce9cccfc64264b8598fa4b4e Author: Ilan Peer Date: Thu Jan 25 15:22:41 2018 +0200 iwlwifi: mvm: Correctly set the tid for mcast queue [ Upstream commit 6508de0305d560235b366cc2cc98f7bcfb029e92 ] In the scheduler config command, the meaning of tid == 0xf was intended to indicate the configuration is for management frames. However, tid == 0xf was also used for the multicast queue that was meant only for multicast data frames, which resulted with the FW not encrypting multicast data frames. As multicast frames do not have a QoS header, fix this by setting tid == 0, to indicate that this is a data queue and not management one. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f2eb4ded1ecb3853c2f0a4fc802fab0b36afb32 Author: Ilan Peer Date: Mon Jan 22 08:55:06 2018 +0200 iwlwifi: mvm: Direct multicast frames to the correct station [ Upstream commit 7c305de2b9548ab6b65fce342c78618bbed5db73 ] Multicast frames for NL80211_IFTYPE_AP and NL80211_IFTYPE_ADHOC were directed to the broadcast station, however, as the broadcast station did not have keys configured, these frames were sent unencrypted. Fix this by using the multicast station which is the station for which encryption keys are configured. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ef3dfb138159344ed73d230ded0ee23d7de766f2 Author: Sara Sharon Date: Mon Jan 15 13:50:59 2018 +0200 iwlwifi: mvm: fix "failed to remove key" message [ Upstream commit e4f13ad07823b24a1537518d2163bd164292fb10 ] When the GTK is installed, we install it to HW with the station ID of the AP. Mac80211 will try to remove it only after the AP sta is removed, which will result in a failure to remove key since we do not have any station for it. This is a valid situation, but a previous commit removed the early return and added a return with error value, which resulted in an error message that is confusing to users. Remove the error return value. Fixes: 85aeb58cec1a ("iwlwifi: mvm: Enable security on new TX API") Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3a0bbca21ca5e97029e5d08199eb114f3e4f427f Author: Shaul Triebitz Date: Thu Jan 11 16:18:46 2018 +0200 iwlwifi: avoid collecting firmware dump if not loaded [ Upstream commit 8745f12a6600dd9d31122588621d4c8ddb332cd7 ] Trying to collect firmware debug data while firmware is not loaded causes various errors (e.g. failing NIC access). This causes even a bigger issue if at that time the HW radio is off. In that case, when later turning the radio on, the Driver fails to read the HW (registers contain garbage values). (It may be that the CSR_GP_CNTRL_REG_FLAG_RFKILL_WAKE_L1A_EN bit is cleared on faulty NIC access - since the same behavior was seen in HW RFKILL toggling before setting that bit.) Signed-off-by: Shaul Triebitz Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 233d806172489f9213b2a75eede2feda5fbf68ae Author: Sara Sharon Date: Sun Jan 7 14:30:49 2018 +0200 iwlwifi: mvm: fix assert 0x2B00 on older FWs [ Upstream commit 63dd5d022f4766e6b05ee611124afcc7cbfbb953 ] We should add the multicast station before adding the broadcast station. However, in older FW, the firmware will start beaconing when we add the multicast station, and since the broadcast station is not added at this point so the transmission of the beacon will fail on assert 0x2b00. This is fixed in later firmware, so make the order of addition depend on the TLV. Fixes: 26d6c16bed53 ("iwlwifi: mvm: add multicast station") Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f970847f0e9d8601b87efba473dae36f46697bd Author: Andrei Otcheretianski Date: Thu Jan 4 17:39:08 2018 +0200 iwlwifi: mvm: Fix channel switch for count 0 and 1 [ Upstream commit 40d53f4a60c9eb10d4fa58066c23ba1af8a59e39 ] It was assumed that apply_time==0 implies immediate scheduling, which is wrong. Instead, the fw expects the START_IMMEDIATELY flag to be set. Otherwise, this resulted in 0x3063 assert. Fix that. While at it rename the T2_V2_START_IMMEDIATELY to TE_V2_START_IMMEDIATELY. Fixes: f5d8f50f271d ("iwlwifi: mvm: Fix channel switch in case of count <= 1") Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d6bcdf0b14d8fbec88d9e8c6217017f913443c67 Author: Sara Sharon Date: Tue Jan 2 11:40:15 2018 +0200 iwlwifi: mvm: fix TX of CCMP 256 [ Upstream commit de04d4fbf87b769ab18c480e4f020c53e74bbdd2 ] We don't have enough room in the TX command for a CCMP 256 key, and need to use key from table. Fixes: 3264bf032bd9 ("[BUGFIX] iwlwifi: mvm: Fix CCMP IV setting") Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d9ed3aed6d83a6ff60f2e4781ae47d5b3e19619a Author: Edward Cree Date: Wed Feb 28 19:15:58 2018 +0000 net: ethtool: don't ignore return from driver get_fecparam method [ Upstream commit a6d50512b4d86ecd9f5952525e454583be1c3b14 ] If ethtool_ops->get_fecparam returns an error, pass that error on to the user, rather than ignoring it. Fixes: 1a5f3da20bd9 ("net: ethtool: add support for forward error correction modes") Signed-off-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f03cd5862f55956afb208b695e45e681b160181e Author: Michael Ellerman Date: Mon Feb 26 15:22:22 2018 +1100 selftests/powerpc: Skip the subpage_prot tests if the syscall is unavailable [ Upstream commit cd4a6f3ab4d80cb919d15897eb3cbc85c2009d4b ] The subpage_prot syscall is only functional when the system is using the Hash MMU. Since commit 5b2b80714796 ("powerpc/mm: Invalidate subpage_prot() system call on radix platforms") it returns ENOENT when the Radix MMU is active. Currently this just makes the test fail. Additionally the syscall is not available if the kernel is built with 4K pages, or if CONFIG_PPC_SUBPAGE_PROT=n, in which case it returns ENOSYS because the syscall is missing entirely. So check explicitly for ENOENT and ENOSYS and skip if we see either of those. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2b103dee283f3fcec7b1141aa041d1346176e0cf Author: Ming Lei Date: Tue Feb 6 20:17:42 2018 +0800 nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors [ Upstream commit 16ccfff2897613007b5eda9e29d65303c6280026 ] 84676c1f21 ("genirq/affinity: assign vectors to all possible CPUs") has switched to do irq vectors spread among all possible CPUs, so pass num_possible_cpus() as max vecotrs to be assigned. For example, in a 8 cores system, 0~3 online, 4~8 offline/not present, see 'lscpu': [ming@box]$lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 2 NUMA node(s): 2 ... NUMA node0 CPU(s): 0-3 NUMA node1 CPU(s): ... 1) before this patch, follows the allocated vectors and their affinity: irq 47, cpu list 0,4 irq 48, cpu list 1,6 irq 49, cpu list 2,5 irq 50, cpu list 3,7 2) after this patch, follows the allocated vectors and their affinity: irq 43, cpu list 0 irq 44, cpu list 1 irq 45, cpu list 2 irq 46, cpu list 3 irq 47, cpu list 4 irq 48, cpu list 6 irq 49, cpu list 5 irq 50, cpu list 7 Cc: Keith Busch Cc: Sagi Grimberg Cc: Thomas Gleixner Cc: Christoph Hellwig Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d68e660604881f9c6de082c4db1473e015f0d41f Author: Wen Xiong Date: Thu Feb 15 14:05:10 2018 -0600 nvme-pci: Fix EEH failure on ppc [ Upstream commit 651438bb0af5213f1f70d66e75bf11d08cb5537a ] Triggering PPC EEH detection and handling requires a memory mapped read failure. The NVMe driver removed the periodic health check MMIO, so there's no early detection mechanism to trigger the recovery. Instead, the detection now happens when the nvme driver handles an IO timeout event. This takes the pci channel offline, so we do not want the driver to proceed with escalating its own recovery efforts that may conflict with the EEH handler. This patch ensures the driver will observe the channel was set to offline after a failed MMIO read and resets the IO timer so the EEH handler has a chance to recover the device. Signed-off-by: Wen Xiong [updated change log] Signed-off-by: Keith Busch Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c84b5aaf7a5ebbdf08ebe08d79c911670712d20 Author: Jiufei Xue Date: Tue Feb 27 20:10:18 2018 +0800 block: display the correct diskname for bio [ Upstream commit 9c0fb1e313aaf4e8edec22433c8b22dd308e466c ] bio_devname use __bdevname to display the device name, and can only show the major and minor of the part0, Fix this by using disk_name to display the correct name. Fixes: 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index") Reviewed-by: Omar Sandoval Reviewed-by: Christoph Hellwig Signed-off-by: Jiufei Xue Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 07d3fb191b5a51af584e21e962fb796919d7db3f Author: Chengguang Xu Date: Thu Mar 1 14:24:51 2018 +0800 ceph: fix potential memory leak in init_caches() [ Upstream commit 1c789249578895bb14ab62b4327306439b754857 ] There is lack of cache destroy operation for ceph_file_cachep when failing from fscache register. Signed-off-by: Chengguang Xu Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 010f5ccbf4c4dcceed770e779089cd24737a1218 Author: Filipe Manana Date: Wed Feb 28 15:55:40 2018 +0000 Btrfs: fix log replay failure after linking special file and fsync [ Upstream commit 9a6509c4daa91400b52a5fd541a5521c649a8fea ] If in the same transaction we rename a special file (fifo, character/block device or symbolic link), create a hard link for it having its old name then sync the log, we will end up with a log that can not be replayed and at when attempting to replay it, an EEXIST error is returned and mounting the filesystem fails. Example scenario: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ mkdir /mnt/testdir $ mkfifo /mnt/testdir/foo # Make sure everything done so far is durably persisted. $ sync # Create some unrelated file and fsync it, this is just to create a log # tree. The file must be in the same directory as our special file. $ touch /mnt/testdir/f1 $ xfs_io -c "fsync" /mnt/testdir/f1 # Rename our special file and then create a hard link with its old name. $ mv /mnt/testdir/foo /mnt/testdir/bar $ ln /mnt/testdir/bar /mnt/testdir/foo # Create some other unrelated file and fsync it, this is just to persist # the log tree which was modified by the previous rename and link # operations. Alternatively we could have modified file f1 and fsync it. $ touch /mnt/f2 $ xfs_io -c "fsync" /mnt/f2 $ mount /dev/sdc /mnt mount: mount /dev/sdc on /mnt failed: File exists This happens because when both the log tree and the subvolume's tree have an entry in the directory "testdir" with the same name, that is, there is one key (258 INODE_REF 257) in the subvolume tree and another one in the log tree (where 258 is the inode number of our special file and 257 is the inode for directory "testdir"). Only the data of those two keys differs, in the subvolume tree the index field for inode reference has a value of 3 while the log tree it has a value of 5. Because the same key exists in both trees, but have different index, the log replay fails with an -EEXIST error when attempting to replay the inode reference from the log tree. Fix this by setting the last_unlink_trans field of the inode (our special file) to the current transaction id when a hard link is created, as this forces logging the parent directory inode, solving the conflict at log replay time. A new generic test case for fstests was also submitted. Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9925eea3225eae9f86cec251e73715ca484bd614 Author: Filipe Manana Date: Tue Feb 6 20:39:20 2018 +0000 Btrfs: send, fix issuing write op when processing hole in no data mode [ Upstream commit d4dfc0f4d39475ccbbac947880b5464a74c30b99 ] When doing an incremental send of a filesystem with the no-holes feature enabled, we end up issuing a write operation when using the no data mode send flag, instead of issuing an update extent operation. Fix this by issuing the update extent operation instead. Trivial reproducer: $ mkfs.btrfs -f -O no-holes /dev/sdc $ mkfs.btrfs -f /dev/sdd $ mount /dev/sdc /mnt/sdc $ mount /dev/sdd /mnt/sdd $ xfs_io -f -c "pwrite -S 0xab 0 32K" /mnt/sdc/foobar $ btrfs subvolume snapshot -r /mnt/sdc /mnt/sdc/snap1 $ xfs_io -c "fpunch 8K 8K" /mnt/sdc/foobar $ btrfs subvolume snapshot -r /mnt/sdc /mnt/sdc/snap2 $ btrfs send /mnt/sdc/snap1 | btrfs receive /mnt/sdd $ btrfs send --no-data -p /mnt/sdc/snap1 /mnt/sdc/snap2 \ | btrfs receive -vv /mnt/sdd Before this change the output of the second receive command is: receiving snapshot snap2 uuid=f6922049-8c22-e544-9ff9-fc6755918447... utimes write foobar, offset 8192, len 8192 utimes foobar BTRFS_IOC_SET_RECEIVED_SUBVOL uuid=f6922049-8c22-e544-9ff9-... After this change it is: receiving snapshot snap2 uuid=564d36a3-ebc8-7343-aec9-bf6fda278e64... utimes update_extent foobar: offset=8192, len=8192 utimes foobar BTRFS_IOC_SET_RECEIVED_SUBVOL uuid=564d36a3-ebc8-7343-aec9-bf6fda278e64... Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b114296692b08e196f5bd900d1158487c1a34983 Author: Jeff Mahoney Date: Thu Feb 15 22:59:47 2018 -0500 btrfs: use kvzalloc to allocate btrfs_fs_info [ Upstream commit a8fd1f71749387c9a1053a83ff1c16287499a4e7 ] The srcu_struct in btrfs_fs_info scales in size with NR_CPUS. On kernels built with NR_CPUS=8192, this can result in kmalloc failures that prevent mounting. There is work in progress to try to resolve this for every user of srcu_struct but using kvzalloc will work around the failures until that is complete. As an example with NR_CPUS=512 on x86_64: the overall size of subvol_srcu is 3460 bytes, fs_info is 6496. Signed-off-by: Jeff Mahoney Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit acb162b9cdb6bc71618d9a9e745bd498c7462b0a Author: Giulio Benetti Date: Wed Feb 28 17:46:53 2018 +0100 drm/sun4i: Fix dclk_set_phase [ Upstream commit e64b6afa98f3629d0c0c46233bbdbe8acdb56f06 ] Phase value is not shifted before writing. Shift left of 28 bits to fit right bits Signed-off-by: Giulio Benetti Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/1519836413-35023-1-git-send-email-giulio.benetti@micronovasrl.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd2dee1ea6d553a044a03585b5c1ec7c4657b854 Author: Douglas Anderson Date: Tue Feb 27 12:47:11 2018 -0800 arm64: dts: rockchip: Fix rk3399-gru-* s2r (pinctrl hogs, wifi reset) [ Upstream commit 2560da49de5d0cfec22e9564023aebfffa094732 ] Back in the early days when gru devices were still under development we found an issue where the WiFi reset line needed to be configured as early as possible during the boot process to avoid the WiFi module being in a bad state. We found that the way to get the kernel to do this in the earliest possible place was to configure this line in the pinctrl hogs, so that's what we did. For some history here you can see . After the time that change landed in the kernel, we landed a firmware change to configure this line even earlier. See . However, even after the firmware change landed we kept the kernel change to deal with the fact that some people working on devices might take a little while to update their firmware. At this there are definitely zero devices out in the wild that have firmware without the fix in it. Specifically looking in the firmware branch several critically important fixes for memory stability landed after the patch in coreboot and I know we didn't ship without those. Thus, by now, everyone should have the new firmware and it's safe to not have the kernel set this up in a pinctrl hog. Historically, even though it wasn't needed to have this in a pinctrl hog, we still kept it since it didn't hurt. Pinctrl would apply the default hog at bootup and then would never touch things again. That all changed with commit 981ed1bfbc6c ("pinctrl: Really force states during suspend/resume"). After that commit then we'll re-apply the default hog at resume time and that can screw up the reset state of WiFi. ...and on rk3399 if you touch a device on PCIe in the wrong way then the whole system can go haywire. That's what was happening. Specifically you'd resume a rk3399-gru-* device and it would mostly resume, then would crash with some crazy weird crash. One could say, perhaps, that the recent pinctrl change was at fault (and should be fixed) since it changed behavior. ...but that's not really true. The device tree for rk3399-gru is really to blame. Specifically since the pinctrl is defined in the hog and not in the "wlan-pd-n" node then the actual user of this pin doesn't have a pinctrl entry for it. That's bad. Let's fix our problems by just moving the control of "wlan_module_reset_l pinctrl" out of the hog and put them in the proper place. NOTE: in theory, I think it should actually be possible to have a pin controlled _both_ by the hog and by an actual device. Once the device claims the pin I think the hog is supposed to let go. I'm not 100% sure that this works and in any case this solution would be more complex than is necessary. Reported-by: Marc Zyngier Fixes: 48f4d9796d99 ("arm64: dts: rockchip: add Gru/Kevin DTS") Fixes: 981ed1bfbc6c ("pinctrl: Really force states during suspend/resume") Signed-off-by: Douglas Anderson Tested-by: Enric Balletbo i Serra Tested-by: Marc Zyngier Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5877f41cf8c83a6bb31137bb3f304fb8638aceba Author: Steffen Klassert Date: Wed Feb 28 09:23:19 2018 +0100 xfrm: Fix ESN sequence number handling for IPsec GSO packets. [ Upstream commit b8b549eec8187ac1b12075d69a2d84d89b5e811a ] When IPsec offloading was introduced, we accidentally incremented the sequence number counter on the xfrm_state by one packet too much in the ESN case. This leads to a sequence number gap of one packet after each GSO packet. Fix this by setting the sequence number to the correct value. Fixes: d7dbefc45cf5 ("xfrm: Add xfrm_replay_overflow functions for offloading") Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 30310d4077157bd05bdad6712d69f08f318a3739 Author: Tom St Denis Date: Mon Feb 26 09:09:26 2018 -0500 drm/amd/amdgpu: Correct VRAM width for APUs with GMC9 [ Upstream commit 585b7f161c85bd5ca675b97580faf21c506541e3 ] DDR4 has a 64-bit width not 128-bits. It was reporting twice the width. Tested with my Ryzen 2400G. Signed-off-by: Tom St Denis Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5b71573794b0f80cccb479b44ba4d62a20516742 Author: Roger Pau Monne Date: Wed Feb 28 09:19:03 2018 +0000 xen/pirq: fix error path cleanup when binding MSIs [ Upstream commit 910f8befdf5bccf25287d9f1743e3e546bcb7ce0 ] Current cleanup in the error path of xen_bind_pirq_msi_to_irq is wrong. First of all there's an off-by-one in the cleanup loop, which can lead to unbinding wrong IRQs. Secondly IRQs not bound won't be freed, thus leaking IRQ numbers. Note that there's no need to differentiate between bound and unbound IRQs when freeing them, __unbind_from_irq will deal with both of them correctly. Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") Reported-by: Hooman Mirhadi Signed-off-by: Roger Pau Monné Reviewed-by: Amit Shah Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 62ee80d3b45b7328e6415e4477d845b96cb6668f Author: Selvin Xavier Date: Mon Feb 26 01:51:39 2018 -0800 RDMA/bnxt_re: Fix the ib_reg failure cleanup [ Upstream commit 497158aa5f520db50452ef928c0f955cb42f2e77 ] Release the netdev references in the cleanup path. Invokes the cleanup routines if bnxt_re_ib_reg fails. Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2bce0d98b9d98b75484c2248b51f6194bdf7308e Author: Devesh Sharma Date: Mon Feb 26 01:51:38 2018 -0800 RDMA/bnxt_re: Fix incorrect DB offset calculation [ Upstream commit c354dff00db8df80f271418d8392065e10ffffb6 ] To support host systems with non 4K page size, l2_db_size shall be calculated with 4096 instead of PAGE_SIZE. Also, supply the host page size to FW during initialization. Signed-off-by: Devesh Sharma Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 466199b440d990d9c340defa6dd91243939905a4 Author: Devesh Sharma Date: Mon Feb 26 01:51:37 2018 -0800 RDMA/bnxt_re: Unconditionly fence non wire memory operations [ Upstream commit a45bc17b360d75fac9ced85e99fda14bf38b4dc3 ] HW requires an unconditonal fence for all non-wire memory operations through SQ. This guarantees the completions of these memory operations. Signed-off-by: Devesh Sharma Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b73bc820c4d1ca3d8cf46a09898c43a446eff6b6 Author: Moni Shoua Date: Sun Feb 25 13:39:54 2018 +0200 IB/mlx: Set slid to zero in Ethernet completion struct [ Upstream commit 65389322b28f81cc137b60a41044c2d958a7b950 ] IB spec says that a lid should be ignored when link layer is Ethernet, for example when building or parsing a CM request message (CA17-34). However, since ib_lid_be16() and ib_lid_cpu16() validates the slid, not only when link layer is IB, we set the slid to zero to prevent false warnings in the kernel log. Fixes: 62ede7779904 ("Add OPA extended LID support") Reviewed-by: Majd Dibbiny Signed-off-by: Moni Shoua Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2a71d94e4f6b0426cc938d6ae276bd9f8bde3c38 Author: Julian Anastasov Date: Sun Feb 25 22:29:18 2018 +0200 ipvs: remove IPS_NAT_MASK check to fix passive FTP [ Upstream commit 8a949fff0302b50063f74bb345a66190015528d0 ] The IPS_NAT_MASK check in 4.12 replaced previous check for nfct_nat() which was needed to fix a crash in 2.6.36-rc, see commit 7bcbf81a2296 ("ipvs: avoid oops for passive FTP"). But as IPVS does not set the IPS_SRC_NAT and IPS_DST_NAT bits, checking for IPS_NAT_MASK prevents PASV response to be properly mangled and blocks the transfer. Remove the check as it is not needed after 3.12 commit 41d73ec053d2 ("netfilter: nf_conntrack: make sequence number adjustments usuable without NAT") which changes nfct_nat() with nfct_seqadj() and especially after 3.13 commit b25adce16064 ("ipvs: correct usage/allocation of seqadj ext in ipvs"). Thanks to Li Shuang and Florian Westphal for reporting the problem! Reported-by: Li Shuang Fixes: be7be6e161a2 ("netfilter: ipvs: fix incorrect conflict resolution") Signed-off-by: Julian Anastasov Acked-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 738310e1dbc98cacd89f9b5241e6f4f6e343dd17 Author: Eugeniy Paltsev Date: Fri Feb 23 19:41:54 2018 +0300 ARC: setup cpu possible mask according to possible-cpus dts property [ Upstream commit a29a25275452c97fe35815f1eb9564f2a07a1965 ] As we have option in u-boot to set CPU mask for running linux, we want to pass information to kernel about CPU cores should be brought up. So we patch kernel dtb in u-boot to set possible-cpus property. This also allows us to have correctly setuped MCIP debug mask. Signed-off-by: Eugeniy Paltsev Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7f78191c910d741c5971094003dfe7233c29743 Author: Eugeniy Paltsev Date: Fri Feb 23 19:41:53 2018 +0300 ARC: mcip: update MCIP debug mask when the new cpu came online [ Upstream commit f3205de98db2fc8083796dd5ad81b191e436fab8 ] As of today we use hardcoded MCIP debug mask, so if we launch kernel via debugger and kick fever cores than HW has all cpus hang at the momemt of setup MCIP debug mask. So update MCIP debug mask when the new cpu came online, instead of use hardcoded MCIP debug mask. Signed-off-by: Eugeniy Paltsev Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 50de7f4347cf0dbe7b9c28e273a8cf498067790e Author: Eugeniy Paltsev Date: Fri Feb 23 19:41:52 2018 +0300 ARC: mcip: halt GFRC counter when ARC cores halt [ Upstream commit 07423d00a2b2a71a97e4287d9262cb83c4c4c89f ] In SMP systems, GFRC is used for clocksource. However by default the counter keeps running even when core is halted (say when debugging via a JTAG debugger). This confuses Linux timekeeping and triggers flase RCU stall splat such as below: | [ARCLinux]# while true; do ./shm_open_23-1.run-test ; done | Running with 1000 processes for 1000 objects | hrtimer: interrupt took 485060 ns | | create_cnt: 1000 | Running with 1000 processes for 1000 objects | [ARCLinux]# INFO: rcu_preempt self-detected stall on CPU | 2-...: (1 GPs behind) idle=a01/1/0 softirq=135770/135773 fqs=0 | INFO: rcu_preempt detected stalls on CPUs/tasks: | 0-...: (1 GPs behind) idle=71e/0/0 softirq=135264/135264 fqs=0 | 2-...: (1 GPs behind) idle=a01/1/0 softirq=135770/135773 fqs=0 | 3-...: (1 GPs behind) idle=4e0/0/0 softirq=134304/134304 fqs=0 | (detected by 1, t=13648 jiffies, g=31493, c=31492, q=1) Starting from ARC HS v3.0 it's possible to tie GFRC to state of up-to 4 ARC cores with help of GFRC's CORE register where we set a mask for cores which state we need to rely on. We update cpu mask every time new cpu came online instead of using hardcoded one or using mask generated from "possible_cpus" as we want it set correctly even if we run kernel on HW which has fewer cores than expected (or we launch kernel via debugger and kick fever cores than HW has) Note that GFRC halts when all cores have halted and thus relies on programming of Inter-Core-dEbug register to halt all cores when one halts. Signed-off-by: Alexey Brodkin Signed-off-by: Eugeniy Paltsev Signed-off-by: Vineet Gupta [vgupta: rewrote changelog] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e44fe4d2a81bce519cb1109592948e5c2feee1a8 Author: Ido Schimmel Date: Wed Feb 28 13:12:11 2018 +0100 spectrum: Reference count VLAN entries [ Upstream commit b3529af6bb0d4fe72defdd539712ceffaa054fb3 ] One of the basic construct in the device is a port-VLAN pair, which can be bound to a FID or a RIF in order to direct packets to the bridge or the router, respectively. Since not all the netdevs are configured with a VLAN (e.g., sw1p1 vs. sw1p1.10), VID 1 is used to represent these and thus this VID can be used by both upper devices of mlxsw ports and by the driver itself. However, this VID is not reference counted and therefore might be freed prematurely, which can result in various WARNINGs. For example: $ ip link add name br0 type bridge vlan_filtering 1 $ teamd -t team0 -d -c '{"runner": {"name": "lacp"}}' $ ip link set dev team0 master br0 $ ip link set dev enp1s0np1 master team0 $ ip address add 192.0.2.1/24 dev enp1s0np1 The enslavement to team0 will fail because team0 already has an upper and thus vlan_vids_del_by_dev() will be executed as part of team's error path which will delete VID 1 from enp1s0np1 (added by br0 as PVID). The WARNING will be generated when the driver will realize it can't find VID 1 on the port and bind it to a RIF. Fix this by adding a reference count to the VLAN entries on the port, in a similar fashion to the reference counting used by the corresponding 'vlan_vid_info' structure in the 8021q driver. Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN") Reported-by: Tal Bar Signed-off-by: Ido Schimmel Tested-by: Tal Bar Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5a8392f2dc13b4b4589d2b6b4ba87777deebbe9e Author: Ido Schimmel Date: Wed Feb 28 13:12:10 2018 +0100 mlxsw: spectrum: Treat IPv6 unregistered multicast as broadcast [ Upstream commit 9d45deb04c59b628b21fc5014aff4f9a1d38f969 ] When multicast snooping is enabled, the Linux bridge resorts to flooding unregistered multicast packets to all ports only in case it did not detect a querier in the network. The above condition is not reflected to underlying drivers, which is especially problematic in IPv6 environments, as multicast snooping is enabled by default and since neighbour solicitation packets might be treated as unregistered multicast packets in case there is no corresponding MDB entry. Until the Linux bridge reflects its querier state to underlying drivers, simply treat unregistered multicast packets as broadcast and allow them to reach their destination. Fixes: 9df552ef3e21 ("mlxsw: spectrum: Improve IPv6 unregistered multicast flooding") Signed-off-by: Ido Schimmel Reported-by: David Ahern Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 47a8c89258e5dee8e81c4ac716b24978eccd7cf2 Author: Jiri Pirko Date: Wed Feb 28 13:12:08 2018 +0100 mlxsw: core: Fix flex keys scratchpad offset conflict [ Upstream commit 2ddc94c76cc4ccaf51b478315912b38dfdde1afc ] IP_TTL, IP_ECN and IP_DSCP are using the same offset within the scratchpad as L4 ports. Fix this by shifting all up. Fixes: 5f57e0909136 ("mlxsw: acl: Add ip ttl acl element") Fixes: i80d0fe4710c ("mlxsw: acl: Add ip tos acl element") Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 953a64ca335384a51ee047df461993881bc0afe1 Author: Karsten Graul Date: Wed Feb 28 12:44:08 2018 +0100 net/smc: use link_id of server in confirm link reply [ Upstream commit 2be922f31606f114119f48de3207d122a90e7357 ] The CONFIRM LINK reply message must contain the link_id sent by the server. And set the link_id explicitly when initializing the link. Signed-off-by: Karsten Graul Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e0a5a0f4749fa7019efab95372737f2a502e470b Author: Max Gurtovoy Date: Wed Jan 24 17:31:45 2018 +0200 nvmet: fix PSDT field check in command format [ Upstream commit bffd2b61670feef18d2535e9b53364d270a1c991 ] PSDT field section according to NVM_Express-1.3: "This field specifies whether PRPs or SGLs are used for any data transfer associated with the command. PRPs shall be used for all Admin commands for NVMe over PCIe. SGLs shall be used for all Admin and I/O commands for NVMe over Fabrics. This field shall be set to 01b for NVMe over Fabrics 1.0 implementations. Suggested-by: Idan Burstein Signed-off-by: Max Gurtovoy Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c6885fb45d4e40053ee1ef92b56d668340237e2e Author: Joey Pabalinas Date: Tue Feb 27 22:05:53 2018 -1000 net/tcp/illinois: replace broken algorithm reference link [ Upstream commit ecc832758a654e375924ebf06a4ac971acb5ce60 ] The link to the pdf containing the algorithm description is now a dead link; it seems http://www.ifp.illinois.edu/~srikant/ has been moved to https://sites.google.com/a/illinois.edu/srikant/ and none of the original papers can be found there... I have replaced it with the only working copy I was able to find. n.b. there is also a copy available at: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.296.6350&rep=rep1&type=pdf However, this seems to only be a *cached* version, so I am unsure exactly how reliable that link can be expected to remain over time and have decided against using that one. Signed-off-by: Joey Pabalinas net/ipv4/tcp_illinois.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb19a6a9b598c807a7d4537d7b043e9180d8a7d0 Author: Claudiu Manoil Date: Tue Feb 27 17:33:10 2018 +0200 gianfar: Fix Rx byte accounting for ndev stats [ Upstream commit 590399ddf9561f2ed0839311c8ae1be21597ba68 ] Don't include in the Rx bytecount of the packet sent up the stack: the FCB (frame control block), and the padding bytes inserted by the controller into the frame payload, nor the FCS. All these are being pulled out of the skb by gfar_process_frame(). This issue is old, likely from the driver's beginnings, however it was amplified by recent: commit d903ec77118c ("gianfar: simplify FCS handling and fix memory leak") which basically added the FCS to the Rx bytecount, and so brought this to my attention. Signed-off-by: Claudiu Manoil Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10c7390ee34009a54c97a23eea7e4d53a096a3f5 Author: Felix Fietkau Date: Wed Feb 28 10:56:10 2018 +0100 clocksource/drivers/mips-gic-timer: Use correct shift count to extract data [ Upstream commit 5753405e27f8fe4c42c1537d3ddbd9e058e54cdc ] __gic_clocksource_init() extracts the GIC_CONFIG_COUNTBITS field from read_gic_config() by right shifting the register value. The shift count is determined by the most significant bit (__fls) of the bitmask which is wrong as it shifts out the complete bitfield. Use the least significant bit (__ffs) instead to shift the bitfield down to bit 0. Fixes: e07127a077c7 ("clocksource: mips-gic-timer: Use new GIC accessor functions") Signed-off-by: Felix Fietkau Signed-off-by: Thomas Gleixner Cc: daniel.lezcano@linaro.org Cc: paul.burton@imgtec.com Link: https://lkml.kernel.org/r/20180228095610.50341-1-nbd@nbd.name Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f97c2bf56bb799ef109e67c6aebe2d00b5e6e12b Author: Guenter Roeck Date: Fri Feb 23 12:55:59 2018 -0800 powerpc/boot: Fix random libfdt related build errors [ Upstream commit 64c3f648c25d108f346fdc96c15180c6b7d250e9 ] Once in a while I see build errors similar to the following when building images from a clean tree. Building powerpc:virtex-ml507:44x/virtex5_defconfig ... failed ------------ Error log: arch/powerpc/boot/treeboot-akebono.c:37:20: fatal error: libfdt.h: No such file or directory Building powerpc:bamboo:smpdev:44x/bamboo_defconfig ... failed ------------ Error log: arch/powerpc/boot/treeboot-akebono.c:37:20: fatal error: libfdt.h: No such file or directory arch/powerpc/boot/treeboot-currituck.c:35:20: fatal error: libfdt.h: No such file or directory Rebuilds will succeed. Turns out that several source files in arch/powerpc/boot/ include libfdt.h, but Makefile dependencies are incomplete. Let's fix that. Signed-off-by: Guenter Roeck Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9bbedb9742f3947a88da327969ec8849c2134043 Author: Stefan Wahren Date: Sat Feb 24 15:15:21 2018 +0100 ARM: dts: bcm283x: Fix unit address of local_intc [ Upstream commit 808b7de86a0c19582a7efce4c80d6b4e1da7f370 ] This patch fixes the following DTC warning (requires W=1): Node /soc/local_intc simple-bus unit address format error, expected "40000000" Signed-off-by: Stefan Wahren Reviewed-by: Eric Anholt Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c43ff936255bb31feb27cc2b4f2ef3897384733a Author: Florian Fainelli Date: Mon Feb 26 17:00:35 2018 -0800 ARM: dts: NSP: Fix amount of RAM on BCM958625HR [ Upstream commit 0a5aff64f20d92c5a6e9aeed7b5950b0b817bcd9 ] Jon attempted to fix the amount of RAM on the BCM958625HR in commit c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board") but it seems like we tripped over some poorly documented schematics. The top-level page of the schematics says the board has 2GB, but when you end-up scrolling to page 6, you see two chips of 4GBit (512MB) but what the bootloader really initializes only 512MB, any attempt to use more than that results in data aborts. Fix this again back to 512MB. Fixes: c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board") Acked-by: Jon Mason Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 615bf75c46903a2409e95d8e146d2bb0a81f930c Author: Gustavo A. R. Silva Date: Mon Feb 12 11:14:55 2018 -0600 nbd: fix return value in error handling path [ Upstream commit 0979962f5490abe75b3e2befb07a564fa0cf631b ] It seems that the proper value to return in this particular case is the one contained into variable new_index instead of ret. Addresses-Coverity-ID: 1465148 ("Copy-paste error") Fixes: e46c7287b1c2 ("nbd: add a basic netlink interface") Reviewed-by: Omar Sandoval Signed-off-by: Gustavo A. R. Silva Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d2e2e20bbdd3b527e413044deb0677e7aa3892eb Author: Xin Long Date: Tue Feb 27 19:19:41 2018 +0800 sit: fix IFLA_MTU ignored on NEWLINK [ Upstream commit 2b3957c34b6d7f03544b12ebbf875eee430745db ] Commit 128bb975dc3c ("ip6_gre: init dev->mtu and dev->hard_header_len correctly") fixed IFLA_MTU ignored on NEWLINK for ip6_gre. The same mtu fix is also needed for sit. Note that dev->hard_header_len setting for sit works fine, no need to fix it. sit is actually ipv4 tunnel, it can't call ip6_tnl_change_mtu to set mtu. Reported-by: Jianlin Shi Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2b0fbc2fcd2fa5d6abed5e86ba0042000721e4d0 Author: Xin Long Date: Tue Feb 27 19:19:40 2018 +0800 ip6_tunnel: fix IFLA_MTU ignored on NEWLINK [ Upstream commit a6aa80446234ec0ad38eecdb8efc59e91daae565 ] Commit 128bb975dc3c ("ip6_gre: init dev->mtu and dev->hard_header_len correctly") fixed IFLA_MTU ignored on NEWLINK for ip6_gre. The same mtu fix is also needed for ip6_tunnel. Note that dev->hard_header_len setting for ip6_tunnel works fine, no need to fix it. Reported-by: Jianlin Shi Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 29764acd50d33678883b1955334040bef563cd11 Author: Xin Long Date: Tue Feb 27 19:19:39 2018 +0800 ip_gre: fix IFLA_MTU ignored on NEWLINK [ Upstream commit ffc2b6ee417435605ee8bb1eb4c8f02e9ff4b4a5 ] It's safe to remove the setting of dev's needed_headroom and mtu in __gre_tunnel_init, as discussed in [1], ip_tunnel_newlink can do it properly. Now Eric noticed that it could cover the mtu value set in do_setlink when creating a ip_gre dev. It makes IFLA_MTU param not take effect. So this patch is to remove them to make IFLA_MTU work, as in other ipv4 tunnels. [1]: https://patchwork.ozlabs.org/patch/823504/ Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Reported-by: Eric Garver Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f07b6505f474a108326ebb99018c0036c789c153 Author: Tang Junhui Date: Tue Feb 27 09:49:30 2018 -0800 bcache: fix kcrashes with fio in RAID5 backend dev [ Upstream commit 60eb34ec5526e264c2bbaea4f7512d714d791caf ] Kernel crashed when run fio in a RAID5 backend bcache device, the call trace is bellow: [ 440.012034] kernel BUG at block/blk-ioc.c:146! [ 440.012696] invalid opcode: 0000 [#1] SMP NOPTI [ 440.026537] CPU: 2 PID: 2205 Comm: md127_raid5 Not tainted 4.15.0 #8 [ 440.027441] Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 07/16 /2015 [ 440.028615] RIP: 0010:put_io_context+0x8b/0x90 [ 440.029246] RSP: 0018:ffffa8c882b43af8 EFLAGS: 00010246 [ 440.029990] RAX: 0000000000000000 RBX: ffffa8c88294fca0 RCX: 0000000000 0f4240 [ 440.031006] RDX: 0000000000000004 RSI: 0000000000000286 RDI: ffffa8c882 94fca0 [ 440.032030] RBP: ffffa8c882b43b10 R08: 0000000000000003 R09: ffff949cb8 0c1700 [ 440.033206] R10: 0000000000000104 R11: 000000000000b71c R12: 00000000000 01000 [ 440.034222] R13: 0000000000000000 R14: ffff949cad84db70 R15: ffff949cb11 bd1e0 [ 440.035239] FS: 0000000000000000(0000) GS:ffff949cba280000(0000) knlGS: 0000000000000000 [ 440.060190] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 440.084967] CR2: 00007ff0493ef000 CR3: 00000002f1e0a002 CR4: 00000000001 606e0 [ 440.110498] Call Trace: [ 440.135443] bio_disassociate_task+0x1b/0x60 [ 440.160355] bio_free+0x1b/0x60 [ 440.184666] bio_put+0x23/0x30 [ 440.208272] search_free+0x23/0x40 [bcache] [ 440.231448] cached_dev_write_complete+0x31/0x70 [bcache] [ 440.254468] closure_put+0xb6/0xd0 [bcache] [ 440.277087] request_endio+0x30/0x40 [bcache] [ 440.298703] bio_endio+0xa1/0x120 [ 440.319644] handle_stripe+0x418/0x2270 [raid456] [ 440.340614] ? load_balance+0x17b/0x9c0 [ 440.360506] handle_active_stripes.isra.58+0x387/0x5a0 [raid456] [ 440.380675] ? __release_stripe+0x15/0x20 [raid456] [ 440.400132] raid5d+0x3ed/0x5d0 [raid456] [ 440.419193] ? schedule+0x36/0x80 [ 440.437932] ? schedule_timeout+0x1d2/0x2f0 [ 440.456136] md_thread+0x122/0x150 [ 440.473687] ? wait_woken+0x80/0x80 [ 440.491411] kthread+0x102/0x140 [ 440.508636] ? find_pers+0x70/0x70 [ 440.524927] ? kthread_associate_blkcg+0xa0/0xa0 [ 440.541791] ret_from_fork+0x35/0x40 [ 440.558020] Code: c2 48 00 5b 41 5c 41 5d 5d c3 48 89 c6 4c 89 e7 e8 bb c2 48 00 48 8b 3d bc 36 4b 01 48 89 de e8 7c f7 e0 ff 5b 41 5c 41 5d 5d c3 <0f> 0b 0f 1f 00 0f 1f 44 00 00 55 48 8d 47 b8 48 89 e5 41 57 41 [ 440.610020] RIP: put_io_context+0x8b/0x90 RSP: ffffa8c882b43af8 [ 440.628575] ---[ end trace a1fd79d85643a73e ]-- All the crash issue happened when a bypass IO coming, in such scenario s->iop.bio is pointed to the s->orig_bio. In search_free(), it finishes the s->orig_bio by calling bio_complete(), and after that, s->iop.bio became invalid, then kernel would crash when calling bio_put(). Maybe its upper layer's faulty, since bio should not be freed before we calling bio_put(), but we'd better calling bio_put() first before calling bio_complete() to notify upper layer ending this bio. This patch moves bio_complete() under bio_put() to avoid kernel crash. [mlyle: fixed commit subject for character limits] Reported-by: Matthias Ferdinand Tested-by: Matthias Ferdinand Signed-off-by: Tang Junhui Reviewed-by: Michael Lyle Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 421c15e803defb3b439d95ae5994c75f8dcc01e6 Author: Yoshihiro Shimoda Date: Wed Feb 14 18:40:12 2018 +0900 dmaengine: rcar-dmac: fix max_chunk_size for R-Car Gen3 [ Upstream commit d716d9b702bb759dd6fb50804f10a174bd156d71 ] According to R-Car Gen3 Rev.0.80 manual, the DMATCR can be set to 16,777,215 as maximum. So, this patch fixes the max_chunk_size for safety on all of SoCs. Otherwise, a system may hang if the DMATCR is set to 0 on R-Car Gen3. Signed-off-by: Yoshihiro Shimoda Reviewed-by: Simon Horman Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c08f8140a9a67c48aa133eb0962af71076487ce Author: Dave Airlie Date: Wed Feb 21 11:50:03 2018 +1000 virtio-gpu: fix ioctl and expose the fixed status to userspace. [ Upstream commit 9a191b114906457c4b2494c474f58ae4142d4e67 ] This exposes to mesa that it can use the fixed ioctl for querying later cap sets, cap set 1 is forever frozen in time. Signed-off-by: Dave Airlie Link: http://patchwork.freedesktop.org/patch/msgid/20180221015003.22884-1-airlied@gmail.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b156a0a49c9f7eb8ae144e49dc52dc200f23d60 Author: Eric Dumazet Date: Sun Feb 25 19:12:10 2018 -0800 r8152: fix tx packets accounting [ Upstream commit 4c27bf3c5b7434ccb9ab962301da661c26b467a4 ] r8152 driver handles TSO packets (limited to ~16KB) quite well, but pretends each TSO logical packet is a single packet on the wire. There is also some error since headers are accounted once, but error rate is small enough that we do not care. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9c3e4e41c206112ad80b93fa06bd41571f11d0da Author: Daniel Díaz Date: Wed Feb 7 11:24:31 2018 -0600 selftests/futex: Fix line continuation in Makefile [ Upstream commit 067b25a5639b10dfdd41ce6b4d4140fe84d0a8e7 ] The Makefile lacks a couple of line continuation backslashes in an `if' clause, which produces an error when make versions prior to 4.x are used for building the tests. $ make make[1]: Entering directory `/[...]/linux/tools/testing/selftests/futex' /bin/sh: -c: line 5: syntax error: unexpected end of file make[1]: *** [all] Error 1 make[1]: Leaving directory `/[...]/linux/tools/testing/selftests/futex' make: *** [all] Error 2 Signed-off-by: Daniel Díaz Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 784858e73805e307509a2664b2c7dcb5f67d306e Author: Ramon Fried Date: Sun Feb 25 09:49:37 2018 +0200 qrtr: add MODULE_ALIAS macro to smd [ Upstream commit c77f5fbbefc04612755117775e8555c2a7006cac ] Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load when IPCRTR channel is detected. Signed-off-by: Ramon Fried Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0129ee813ef7ea0c7abafcaf3ec425306282d756 Author: David S. Miller Date: Mon Feb 26 13:41:47 2018 -0500 ARM: orion5x: Revert commit 4904dbda41c8. [ Upstream commit 13a55372b64e00e564a08d785ca87bd9d454ba30 ] It is not valid for orion5x to use mac_pton(). First of all, the orion5x buffer is not NULL terminated. mac_pton() has no business operating on non-NULL terminated buffers because only the caller can know that this is valid and in what manner it is ok to parse this NULL'less buffer. Second of all, orion5x operates on an __iomem pointer, which cannot be dereferenced using normal C pointer operations. Accesses to such areas much be performed with the proper iomem accessors. Fixes: 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3ecb681ccf6b1853e7acd912cb7d13e6f97fb525 Author: Colin Ian King Date: Thu Feb 22 17:22:59 2018 +0000 xen/pvcalls: fix null pointer dereference on map->sock [ Upstream commit 68d2059be660944152ba667e43c3b4ec225974bc ] Currently if map is null then a potential null pointer deference occurs when calling sock_release on map->sock. I believe the actual intention was to call sock_release on sock instead. Fix this. Fixes: 5db4d286a8ef ("xen/pvcalls: implement connect command") Signed-off-by: Colin Ian King Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6c88c93898ca3cebf27c5ea96585560bb81959a2 Author: Chengguang Xu Date: Fri Feb 9 20:40:59 2018 +0800 ceph: fix dentry leak when failing to init debugfs [ Upstream commit 18106734b512664a8541026519ce4b862498b6c3 ] When failing from ceph_fs_debugfs_init() in ceph_real_mount(), there is lack of dput of root_dentry and it causes slab errors, so change the calling order of ceph_fs_debugfs_init() and open_root_dentry() and do some cleanups to avoid this issue. Signed-off-by: Chengguang Xu Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e080e814deb129f1e3b928af58f61177bd8e8dab Author: Chengguang Xu Date: Tue Feb 6 08:25:55 2018 +0800 libceph, ceph: avoid memory leak when specifying same option several times [ Upstream commit 937441f3a3158d5510ca8cc78a82453f57a96365 ] When parsing string option, in order to avoid memory leak we need to carefully free it first in case of specifying same option several times. Signed-off-by: Chengguang Xu Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 682def914242d13b41c1196e01582d05008ffd43 Author: Colin Ian King Date: Mon Feb 26 11:36:14 2018 +0000 clocksource/drivers/fsl_ftm_timer: Fix error return checking [ Upstream commit f287eb9013ccf199cbfa4eabd80c36fedfc15a73 ] The error checks on freq for a negative error return always fails because freq is unsigned and can never be negative. Fix this by making freq a signed long. Detected with Coccinelle: drivers/clocksource/fsl_ftm_timer.c:287:5-9: WARNING: Unsigned expression compared with zero: freq <= 0 drivers/clocksource/fsl_ftm_timer.c:291:5-9: WARNING: Unsigned expression compared with zero: freq <= 0 Fixes: 2529c3a33079 ("clocksource: Add Freescale FlexTimer Module (FTM) timer support") Signed-off-by: Colin Ian King Signed-off-by: Thomas Gleixner Cc: Daniel Lezcano Cc: kernel-janitors@vger.kernel.org Link: https://lkml.kernel.org/r/20180226113614.3092-1-colin.king@canonical.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 44cb7ed6e5e2f933958c568dc0f01c9331e7083f Author: Jianchao Wang Date: Thu Feb 15 19:13:41 2018 +0800 nvme-pci: Fix nvme queue cleanup if IRQ setup fails [ Upstream commit f25a2dfc20e3a3ed8fe6618c331799dd7bd01190 ] This patch fixes nvme queue cleanup if requesting an IRQ handler for the queue's vector fails. It does this by resetting the cq_vector to the uninitialized value of -1 so it is ignored for a controller reset. Signed-off-by: Jianchao Wang [changelog updates, removed misc whitespace changes] Signed-off-by: Keith Busch Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 588078bb272e816a45f8e8e9873cadbb82eef4fa Author: Sven Eckelmann Date: Sat Feb 24 12:03:37 2018 +0100 batman-adv: Fix netlink dumping of BLA backbones [ Upstream commit fce672db548ff19e76a08a32a829544617229bc2 ] The function batadv_bla_backbone_dump_bucket must be able to handle non-complete dumps of a single bucket. It tries to do that by saving the latest dumped index in *idx_skip to inform the caller about the current state. But the caller only assumes that buckets were not completely dumped when the return code is non-zero. This function must therefore also return a non-zero index when the dumping of an entry failed. Otherwise the caller will just skip all remaining buckets. And the function must also reset *idx_skip back to zero when it finished a bucket. Otherwise it will skip the same number of entries in the next bucket as the previous one had. Fixes: ea4152e11716 ("batman-adv: add backbone table netlink support") Reported-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f03c64fbdd9b0bd75dbc7a992579b78f61a023a0 Author: Sven Eckelmann Date: Sat Feb 24 12:03:36 2018 +0100 batman-adv: Fix netlink dumping of BLA claims [ Upstream commit b0264ecdfeab5f889b02ec54af7ca8cc1c245e2f ] The function batadv_bla_claim_dump_bucket must be able to handle non-complete dumps of a single bucket. It tries to do that by saving the latest dumped index in *idx_skip to inform the caller about the current state. But the caller only assumes that buckets were not completely dumped when the return code is non-zero. This function must therefore also return a non-zero index when the dumping of an entry failed. Otherwise the caller will just skip all remaining buckets. And the function must also reset *idx_skip back to zero when it finished a bucket. Otherwise it will skip the same number of entries in the next bucket as the previous one had. Fixes: 04f3f5bf1883 ("batman-adv: add B.A.T.M.A.N. Dump BLA claims via netlink") Reported-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f08cabec0696517f8c811cd8279df5f56d0ab15d Author: Sven Eckelmann Date: Mon Feb 19 14:08:53 2018 +0100 batman-adv: Ignore invalid batadv_v_gw during netlink send [ Upstream commit 011c935fceae5252619ef730baa610c655281dda ] The function batadv_v_gw_dump stops the processing loop when batadv_v_gw_dump_entry returns a non-0 return code. This should only happen when the buffer is full. Otherwise, an empty message may be returned by batadv_gw_dump. This empty message will then stop the netlink dumping of gateway entries. At worst, not a single entry is returned to userspace even when plenty of possible gateways exist. Fixes: b71bb6f924fe ("batman-adv: add B.A.T.M.A.N. V bat_gw_dump implementations") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b7e379faf15f26b271225f60c5b9a654076193d Author: Sven Eckelmann Date: Mon Feb 19 14:08:52 2018 +0100 batman-adv: Ignore invalid batadv_iv_gw during netlink send [ Upstream commit 10d570284258a30dc104c50787c5289ec49f3d23 ] The function batadv_iv_gw_dump stops the processing loop when batadv_iv_gw_dump_entry returns a non-0 return code. This should only happen when the buffer is full. Otherwise, an empty message may be returned by batadv_gw_dump. This empty message will then stop the netlink dumping of gateway entries. At worst, not a single entry is returned to userspace even when plenty of possible gateways exist. Fixes: efb766af06e3 ("batman-adv: add B.A.T.M.A.N. IV bat_gw_dump implementations") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dd20ff0d079da24afa6b34c5323e46272d091228 Author: Florian Westphal Date: Mon Feb 19 01:24:53 2018 +0100 netfilter: ebtables: convert BUG_ONs to WARN_ONs [ Upstream commit fc6a5d0601c5ac1d02f283a46f60b87b2033e5ca ] All of these conditions are not fatal and should have been WARN_ONs from the get-go. Convert them to WARN_ONs and bail out. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84fc57f472f9fcf42ba3ef27734694d1a2a75b23 Author: Florian Westphal Date: Fri Feb 16 12:49:33 2018 +0100 netfilter: ipt_CLUSTERIP: put config instead of freeing it [ Upstream commit 1a9da5937386dbe553ffcf6c65d985bd48c347c5 ] Once struct is added to per-netns list it becomes visible to other cpus, so we cannot use kfree(). Also delay setting entries refcount to 1 until after everything is initialised so that when we call clusterip_config_put() in this spot entries is still zero. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 596816fabe42d41d81e862b056761bab50a93ae2 Author: Florian Westphal Date: Fri Feb 16 12:49:32 2018 +0100 netfilter: ipt_CLUSTERIP: put config struct if we can't increment ct refcount [ Upstream commit 8ae56822812ddedc26a152ab1916eb30120b4748 ] This needs to put() the entry to avoid a resource leak in error path. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ff8c6751ecf35b4a57a73b8b5c32fd8914d69b6d Author: Matthias Schiffer Date: Tue Jan 23 10:59:50 2018 +0100 batman-adv: invalidate checksum on fragment reassembly [ Upstream commit 3bf2a09da956b43ecfaa630a2ef9a477f991a46a ] A more sophisticated implementation could try to combine fragment checksums when all fragments have CHECKSUM_COMPLETE and are split at even offsets. For now, we just set ip_summed to CHECKSUM_NONE to avoid "hw csum failure" warnings in the kernel log when fragmented frames are received. In consequence, skb_pull_rcsum() can be replaced with skb_pull(). Note that in usual setups, packets don't reach batman-adv with CHECKSUM_COMPLETE (I assume NICs bail out of checksumming when they see batadv's ethtype?), which is why the log messages do not occur on every system using batman-adv. I could reproduce this issue by stacking batman-adv on top of a VXLAN interface. Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Tested-by: Maximilian Wilhelm Signed-off-by: Matthias Schiffer Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ee7a88fc775e91fe1f250f6a9843aae2ae7df62a Author: Matthias Schiffer Date: Tue Jan 23 10:59:49 2018 +0100 batman-adv: fix packet checksum in receive path [ Upstream commit abd6360591d3f8259f41c34e31ac4826dfe621b8 ] eth_type_trans() internally calls skb_pull(), which does not adjust the skb checksum; skb_postpull_rcsum() is necessary to avoid log spam of the form "bat0: hw csum failure" when packets with CHECKSUM_COMPLETE are received. Note that in usual setups, packets don't reach batman-adv with CHECKSUM_COMPLETE (I assume NICs bail out of checksumming when they see batadv's ethtype?), which is why the log messages do not occur on every system using batman-adv. I could reproduce this issue by stacking batman-adv on top of a VXLAN interface. Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Tested-by: Maximilian Wilhelm Signed-off-by: Matthias Schiffer Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 879a73b10a93c8f7b59e7ce1f2d19f6c73fb73b6 Author: Yufen Yu Date: Sat Feb 24 12:05:56 2018 +0800 md/raid1: fix NULL pointer dereference [ Upstream commit 3de59bb9d551428cbdc76a9ea57883f82e350b4d ] In handle_write_finished(), if r1_bio->bios[m] != NULL, it thinks the corresponding conf->mirrors[m].rdev is also not NULL. But, it is not always true. Even if some io hold replacement rdev(i.e. rdev->nr_pending.count > 0), raid1_remove_disk() can also set the rdev as NULL. That means, bios[m] != NULL, but mirrors[m].rdev is NULL, resulting in NULL pointer dereference in handle_write_finished and sync_request_write. This patch can fix BUGs as follows: BUG: unable to handle kernel NULL pointer dereference at 0000000000000140 IP: [] raid1d+0x2bd/0xfc0 PGD 12ab52067 PUD 12f587067 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 2008 Comm: md3_raid1 Not tainted 4.1.44+ #130 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 Call Trace: ? schedule+0x37/0x90 ? prepare_to_wait_event+0x83/0xf0 md_thread+0x144/0x150 ? wake_atomic_t_function+0x70/0x70 ? md_start_sync+0xf0/0xf0 kthread+0xd8/0xf0 ? kthread_worker_fn+0x160/0x160 ret_from_fork+0x42/0x70 ? kthread_worker_fn+0x160/0x160 BUG: unable to handle kernel NULL pointer dereference at 00000000000000b8 IP: sync_request_write+0x9e/0x980 PGD 800000007c518067 P4D 800000007c518067 PUD 8002b067 PMD 0 Oops: 0000 [#1] SMP PTI CPU: 24 PID: 2549 Comm: md3_raid1 Not tainted 4.15.0+ #118 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 Call Trace: ? sched_clock+0x5/0x10 ? sched_clock_cpu+0xc/0xb0 ? flush_pending_writes+0x3a/0xd0 ? pick_next_task_fair+0x4d5/0x5f0 ? __switch_to+0xa2/0x430 raid1d+0x65a/0x870 ? find_pers+0x70/0x70 ? find_pers+0x70/0x70 ? md_thread+0x11c/0x160 md_thread+0x11c/0x160 ? finish_wait+0x80/0x80 kthread+0x111/0x130 ? kthread_create_worker_on_cpu+0x70/0x70 ? do_syscall_64+0x6f/0x190 ? SyS_exit_group+0x10/0x10 ret_from_fork+0x35/0x40 Reviewed-by: NeilBrown Signed-off-by: Yufen Yu Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0a4c60471d13ff01ab042b16f37e7912f872d985 Author: BingJing Chang Date: Thu Feb 22 13:34:46 2018 +0800 md: fix a potential deadlock of raid5/raid10 reshape [ Upstream commit 8876391e440ba615b10eef729576e111f0315f87 ] There is a potential deadlock if mount/umount happens when raid5_finish_reshape() tries to grow the size of emulated disk. How the deadlock happens? 1) The raid5 resync thread finished reshape (expanding array). 2) The mount or umount thread holds VFS sb->s_umount lock and tries to write through critical data into raid5 emulated block device. So it waits for raid5 kernel thread handling stripes in order to finish it I/Os. 3) In the routine of raid5 kernel thread, md_check_recovery() will be called first in order to reap the raid5 resync thread. That is, raid5_finish_reshape() will be called. In this function, it will try to update conf and call VFS revalidate_disk() to grow the raid5 emulated block device. It will try to acquire VFS sb->s_umount lock. The raid5 kernel thread cannot continue, so no one can handle mount/ umount I/Os (stripes). Once the write-through I/Os cannot be finished, mount/umount will not release sb->s_umount lock. The deadlock happens. The raid5 kernel thread is an emulated block device. It is responible to handle I/Os (stripes) from upper layers. The emulated block device should not request any I/Os on itself. That is, it should not call VFS layer functions. (If it did, it will try to acquire VFS locks to guarantee the I/Os sequence.) So we have the resync thread to send resync I/O requests and to wait for the results. For solving this potential deadlock, we can put the size growth of the emulated block device as the final step of reshape thread. 2017/12/29: Thanks to Guoqing Jiang , we confirmed that there is the same deadlock issue in raid10. It's reproducible and can be fixed by this patch. For raid10.c, we can remove the similar code to prevent deadlock as well since they has been called before. Reported-by: Alex Wu Reviewed-by: Alex Wu Reviewed-by: Chung-Chiang Cheng Signed-off-by: BingJing Chang Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2565b271aed0199f5ff977429486e3b59e68e708 Author: Will Deacon Date: Mon Feb 19 14:55:55 2018 +0000 fs: dcache: Use READ_ONCE when accessing i_dir_seq [ Upstream commit 8cc07c808c9d595e81cbe5aad419b7769eb2e5c9 ] i_dir_seq is subject to concurrent modification by a cmpxchg or store-release operation, so ensure that the relaxed access in d_alloc_parallel uses READ_ONCE. Reported-by: Peter Zijlstra Signed-off-by: Will Deacon Signed-off-by: Al Viro Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3623c1f37efaf6ab2eed458a2ad11e49ebc2e08b Author: Will Deacon Date: Mon Feb 19 14:55:54 2018 +0000 fs: dcache: Avoid livelock between d_alloc_parallel and __d_add [ Upstream commit 015555fd4d2930bc0c86952c46ad88b3392f66e4 ] If d_alloc_parallel runs concurrently with __d_add, it is possible for d_alloc_parallel to continuously retry whilst i_dir_seq has been incremented to an odd value by __d_add: CPU0: __d_add n = start_dir_add(dir); cmpxchg(&dir->i_dir_seq, n, n + 1) == n CPU1: d_alloc_parallel retry: seq = smp_load_acquire(&parent->d_inode->i_dir_seq) & ~1; hlist_bl_lock(b); bit_spin_lock(0, (unsigned long *)b); // Always succeeds CPU0: __d_lookup_done(dentry) hlist_bl_lock bit_spin_lock(0, (unsigned long *)b); // Never succeeds CPU1: if (unlikely(parent->d_inode->i_dir_seq != seq)) { hlist_bl_unlock(b); goto retry; } Since the simple bit_spin_lock used to implement hlist_bl_lock does not provide any fairness guarantees, then CPU1 can starve CPU0 of the lock and prevent it from reaching end_dir_add(dir), therefore CPU1 cannot exit its retry loop because the sequence number always has the bottom bit set. This patch resolves the livelock by not taking hlist_bl_lock in d_alloc_parallel if the sequence counter is odd, since any subsequent masked comparison with i_dir_seq will fail anyway. Cc: Peter Zijlstra Cc: Al Viro Reported-by: Naresh Madhusudana Acked-by: Peter Zijlstra (Intel) Reviewed-by: Matthew Wilcox Signed-off-by: Will Deacon Signed-off-by: Al Viro Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ed49851ce15c08c310c64b11cb68f8e134528bec Author: Shyam Saini Date: Tue Feb 20 18:08:08 2018 +0530 ARM: dts: imx6dl: Include correct dtsi file for Engicam i.CoreM6 DualLite/Solo RQS [ Upstream commit c0c6bb2322964bd264b4ddedaa5776f40c709f0c ] This patch fixes the wrongly included dtsi file which was breaking mainline support for Engicam i.CoreM6 DualLite/Solo RQS. As per the board name, the correct file should be imx6dl.dtsi instead of imx6q.dtsi Reported-by: Michael Trimarchi Suggested-by: Jagan Teki Signed-off-by: Shyam Saini Reviewed-by: Fabio Estevam Fixes: 7a9caba55a61 ("ARM: dts: imx6dl: Add Engicam i.CoreM6 DualLite/Solo RQS initial support") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f95541a0db52dd4edf2dcca3d3e3ba54b97d3cf Author: Sebastian Ott Date: Thu Feb 22 13:05:41 2018 +0100 kvm: fix warning for CONFIG_HAVE_KVM_EVENTFD builds [ Upstream commit 076467490b8176eb96eddc548a14d4135c7b5852 ] Move the kvm_arch_irq_routing_update() prototype outside of ifdef CONFIG_HAVE_KVM_EVENTFD guards to fix the following sparse warning: arch/s390/kvm/../../../virt/kvm/irqchip.c:171:28: warning: symbol 'kvm_arch_irq_routing_update' was not declared. Should it be static? Signed-off-by: Sebastian Ott Acked-by: Christian Borntraeger Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1fe15ab15935c40a0dc99158e460aa36b6927b52 Author: Chao Gao Date: Sun Feb 11 10:06:30 2018 +0800 KVM: nVMX: Don't halt vcpu when L1 is injecting events to L2 [ Upstream commit 135a06c3a515bbd17729eb04f4f26316d48363d7 ] Although L2 is in halt state, it will be in the active state after VM entry if the VM entry is vectoring according to SDM 26.6.2 Activity State. Halting the vcpu here means the event won't be injected to L2 and this decision isn't reported to L1. Thus L0 drops an event that should be injected to L2. Cc: Liran Alon Reviewed-by: Liran Alon Signed-off-by: Chao Gao Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ce8bdc7aabf973f8256f16181c52df402758aeca Author: Alexey Kodanev Date: Thu Feb 22 18:20:30 2018 +0300 macvlan: fix use-after-free in macvlan_common_newlink() [ Upstream commit 4e14bf4236490306004782813b8b4494b18f5e60 ] The following use-after-free was reported by KASan when running LTP macvtap01 test on 4.16-rc2: [10642.528443] BUG: KASAN: use-after-free in macvlan_common_newlink+0x12ef/0x14a0 [macvlan] [10642.626607] Read of size 8 at addr ffff880ba49f2100 by task ip/18450 ... [10642.963873] Call Trace: [10642.994352] dump_stack+0x5c/0x7c [10643.035325] print_address_description+0x75/0x290 [10643.092938] kasan_report+0x28d/0x390 [10643.137971] ? macvlan_common_newlink+0x12ef/0x14a0 [macvlan] [10643.207963] macvlan_common_newlink+0x12ef/0x14a0 [macvlan] [10643.275978] macvtap_newlink+0x171/0x260 [macvtap] [10643.334532] rtnl_newlink+0xd4f/0x1300 ... [10646.256176] Allocated by task 18450: [10646.299964] kasan_kmalloc+0xa6/0xd0 [10646.343746] kmem_cache_alloc_trace+0xf1/0x210 [10646.397826] macvlan_common_newlink+0x6de/0x14a0 [macvlan] [10646.464386] macvtap_newlink+0x171/0x260 [macvtap] [10646.522728] rtnl_newlink+0xd4f/0x1300 ... [10647.022028] Freed by task 18450: [10647.061549] __kasan_slab_free+0x138/0x180 [10647.111468] kfree+0x9e/0x1c0 [10647.147869] macvlan_port_destroy+0x3db/0x650 [macvlan] [10647.211411] rollback_registered_many+0x5b9/0xb10 [10647.268715] rollback_registered+0xd9/0x190 [10647.319675] register_netdevice+0x8eb/0xc70 [10647.370635] macvlan_common_newlink+0xe58/0x14a0 [macvlan] [10647.437195] macvtap_newlink+0x171/0x260 [macvtap] Commit d02fd6e7d293 ("macvlan: Fix one possible double free") handles the case when register_netdevice() invokes ndo_uninit() on error and as a result free the port. But 'macvlan_port_get_rtnl(dev))' check (returns dev->rx_handler_data), which was added by this commit in order to prevent double free, is not quite correct: * for macvlan it always returns NULL because 'lowerdev' is the one that was used to register rx handler (port) in macvlan_port_create() as well as to unregister it in macvlan_port_destroy(). * for macvtap it always returns a valid pointer because macvtap registers its own rx handler before macvlan_common_newlink(). Fixes: d02fd6e7d293 ("macvlan: Fix one possible double free") Signed-off-by: Alexey Kodanev Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a383f44e7a3455179f906cac19497de6935ee541 Author: Pratyush Anand Date: Mon Feb 5 14:28:01 2018 +0100 arm64: fix unwind_frame() for filtered out fn for function graph tracing [ Upstream commit 9f416319f40cd857d2bb517630e5855a905ef3fb ] do_task_stat() calls get_wchan(), which further does unwind_frame(). unwind_frame() restores frame->pc to original value in case function graph tracer has modified a return address (LR) in a stack frame to hook a function return. However, if function graph tracer has hit a filtered function, then we can't unwind it as ftrace_push_return_trace() has biased the index(frame->graph) with a 'huge negative' offset(-FTRACE_NOTRACE_DEPTH). Moreover, arm64 stack walker defines index(frame->graph) as unsigned int, which can not compare a -ve number. Similar problem we can have with calling of walk_stackframe() from save_stack_trace_tsk() or dump_backtrace(). This patch fixes unwind_frame() to test the index for -ve value and restore index accordingly before we can restore frame->pc. Reproducer: cd /sys/kernel/debug/tracing/ echo schedule > set_graph_notrace echo 1 > options/display-graph echo wakeup > current_tracer ps -ef | grep -i agent Above commands result in: Unable to handle kernel paging request at virtual address ffff801bd3d1e000 pgd = ffff8003cbe97c00 [ffff801bd3d1e000] *pgd=0000000000000000, *pud=0000000000000000 Internal error: Oops: 96000006 [#1] SMP [...] CPU: 5 PID: 11696 Comm: ps Not tainted 4.11.0+ #33 [...] task: ffff8003c21ba000 task.stack: ffff8003cc6c0000 PC is at unwind_frame+0x12c/0x180 LR is at get_wchan+0xd4/0x134 pc : [] lr : [] pstate: 60000145 sp : ffff8003cc6c3ab0 x29: ffff8003cc6c3ab0 x28: 0000000000000001 x27: 0000000000000026 x26: 0000000000000026 x25: 00000000000012d8 x24: 0000000000000000 x23: ffff8003c1c04000 x22: ffff000008c83000 x21: ffff8003c1c00000 x20: 000000000000000f x19: ffff8003c1bc0000 x18: 0000fffffc593690 x17: 0000000000000000 x16: 0000000000000001 x15: 0000b855670e2b60 x14: 0003e97f22cf1d0f x13: 0000000000000001 x12: 0000000000000000 x11: 00000000e8f4883e x10: 0000000154f47ec8 x9 : 0000000070f367c0 x8 : 0000000000000000 x7 : 00008003f7290000 x6 : 0000000000000018 x5 : 0000000000000000 x4 : ffff8003c1c03cb0 x3 : ffff8003c1c03ca0 x2 : 00000017ffe80000 x1 : ffff8003cc6c3af8 x0 : ffff8003d3e9e000 Process ps (pid: 11696, stack limit = 0xffff8003cc6c0000) Stack: (0xffff8003cc6c3ab0 to 0xffff8003cc6c4000) [...] [] unwind_frame+0x12c/0x180 [] do_task_stat+0x864/0x870 [] proc_tgid_stat+0x3c/0x48 [] proc_single_show+0x5c/0xb8 [] seq_read+0x160/0x414 [] __vfs_read+0x58/0x164 [] vfs_read+0x88/0x144 [] SyS_read+0x60/0xc0 [] __sys_trace_return+0x0/0x4 Fixes: 20380bb390a4 (arm64: ftrace: fix a stack tracer's output under function graph tracer) Signed-off-by: Pratyush Anand Signed-off-by: Jerome Marchand [catalin.marinas@arm.com: replace WARN_ON with WARN_ON_ONCE] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3d82155f85477cb40cf0b303af5de39fb17b7e01 Author: Felix Fietkau Date: Fri Feb 23 10:06:03 2018 +0100 mac80211: drop frames with unexpected DS bits from fast-rx to slow path [ Upstream commit b323ac19b7734a1c464b2785a082ee50bccd3b91 ] Fixes rx for 4-addr packets in AP mode. These may be used for setting up a 4-addr link for stations that are allowed to do so. Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dff5da4724bb13687b65072ae5347c0b3f84326f Author: Samuel Neves Date: Wed Feb 21 20:50:36 2018 +0000 x86/topology: Update the 'cpu cores' field in /proc/cpuinfo correctly across CPU hotplug operations [ Upstream commit 4596749339e06dc7a424fc08a15eded850ed78b7 ] Without this fix, /proc/cpuinfo will display an incorrect amount of CPU cores, after bringing them offline and online again, as exemplified below: $ cat /proc/cpuinfo | grep cores cpu cores : 4 cpu cores : 8 cpu cores : 8 cpu cores : 20 cpu cores : 4 cpu cores : 3 cpu cores : 2 cpu cores : 2 This patch fixes this by always zeroing the booted_cores variable upon turning off a logical CPU. Tested-by: Dou Liyang Signed-off-by: Samuel Neves Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: jgross@suse.com Cc: luto@kernel.org Cc: prarit@redhat.com Cc: vkuznets@redhat.com Link: http://lkml.kernel.org/r/20180221205036.5244-1-sneves@dei.uc.pt Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 95e8297ab2060bfdbe0cc7170d576d6857be36bb Author: Andrea Parri Date: Thu Feb 22 10:24:48 2018 +0100 locking/xchg/alpha: Fix xchg() and cmpxchg() memory ordering bugs [ Upstream commit 472e8c55cf6622d1c112dc2bc777f68bbd4189db ] Successful RMW operations are supposed to be fully ordered, but Alpha's xchg() and cmpxchg() do not meet this requirement. Will Deacon noticed the bug: > So MP using xchg: > > WRITE_ONCE(x, 1) > xchg(y, 1) > > smp_load_acquire(y) == 1 > READ_ONCE(x) == 0 > > would be allowed. ... which thus violates the above requirement. Fix it by adding a leading smp_mb() to the xchg() and cmpxchg() implementations. Reported-by: Will Deacon Signed-off-by: Andrea Parri Acked-by: Paul E. McKenney Cc: Alan Stern Cc: Andrew Morton Cc: Ivan Kokshaysky Cc: Linus Torvalds Cc: Matt Turner Cc: Peter Zijlstra Cc: Richard Henderson Cc: Thomas Gleixner Cc: linux-alpha@vger.kernel.org Link: http://lkml.kernel.org/r/1519291488-5752-1-git-send-email-parri.andrea@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4ba4273e7218fb68d2365ef3a3814bc1e2f8bf9c Author: Wang Hui Date: Thu Feb 22 19:26:03 2018 -0800 x86/intel_rdt: Fix incorrect returned value when creating rdgroup sub-directory in resctrl file system [ Upstream commit 36e74d355297dde6e69a39c838d24710e442babe ] If no monitoring feature is detected because all monitoring features are disabled during boot time or there is no monitoring feature in hardware, creating rdtgroup sub-directory by "mkdir" command reports error: mkdir: cannot create directory ‘/sys/fs/resctrl/p1’: No such file or directory But the sub-directory actually is generated and content is correct: cpus cpus_list schemata tasks The error is because rdtgroup_mkdir_ctrl_mon() returns non zero value after the sub-directory is created and the returned value is reported as an error to user. Clear the returned value to report to user that the sub-directory is actually created successfully. Signed-off-by: Wang Hui Signed-off-by: Zhang Yanfei Signed-off-by: Fenghua Yu Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Ravi V Shankar Cc: Thomas Gleixner Cc: Tony Luck Cc: Vikas Cc: Xiaochen Shen Link: http://lkml.kernel.org/r/1519356363-133085-1-git-send-email-fenghua.yu@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09897fcbd42ae88d3f4ed4a8bf99e56a2bfc5778 Author: Randy Dunlap Date: Mon Feb 12 17:26:20 2018 -0800 integrity/security: fix digsig.c build error with header file [ Upstream commit 120f3b11ef88fc38ce1d0ff9c9a4b37860ad3140 ] security/integrity/digsig.c has build errors on some $ARCH due to a missing header file, so add it. security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] Reported-by: Michael Ellerman Signed-off-by: Randy Dunlap Cc: Mimi Zohar Cc: linux-integrity@vger.kernel.org Link: http://kisskb.ellerman.id.au/kisskb/head/13396/ Signed-off-by: James Morris Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0b9f26e97f2bd557cc41de670cffd0c594ebf6b9 Author: Johannes Berg Date: Thu Feb 22 20:55:28 2018 +0100 regulatory: add NUL to request alpha2 [ Upstream commit 657308f73e674e86b60509a430a46e569bf02846 ] Similar to the ancient commit a5fe8e7695dc ("regulatory: add NUL to alpha2"), add another byte to alpha2 in the request struct so that when we use nla_put_string(), we don't overrun anything. Fixes: 73d54c9e74c4 ("cfg80211: add regulatory netlink multicast group") Reported-by: Kees Cook Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c254a86a333c77c70bebbda7277a73c0d6a11c8c Author: Eric Dumazet Date: Tue Feb 20 21:42:26 2018 -0800 smsc75xx: fix smsc75xx_set_features() [ Upstream commit 88e80c62671ceecdbb77c902731ec95a4bfa62f9 ] If an attempt is made to disable RX checksums, USB adapter is changed but netdev->features is not, because smsc75xx_set_features() returns a non zero value. This throws errors from netdev_rx_csum_fault() : : hw csum failure Signed-off-by: Eric Dumazet Cc: Steve Glendinning Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cc4a2d71cff36bb36e8576c0cbe353ce4ced433d Author: Tony Lindgren Date: Thu Feb 22 10:02:49 2018 -0800 ARM: OMAP: Fix dmtimer init for omap1 [ Upstream commit ba6887836178d43b3665b9da075c2c5dfe1d207c ] We need to enable PM runtime on omap1 also as otherwise we will get errors: omap_timer omap_timer.1: omap_dm_timer_probe: pm_runtime_get_sync failed! omap_timer: probe of omap_timer.1 failed with error -13 ... We are checking for OMAP_TIMER_NEEDS_RESET flag elsewhere so this is safe to do. Cc: Aaro Koskinen Cc: Keerthy Cc: Ladislav Michl Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 90c9ae5943c31de6fd8dfe1503a405bfcbfa3524 Author: Bill.Baker@oracle.com Date: Wed Feb 21 12:46:43 2018 -0600 nfs: system crashes after NFS4ERR_MOVED recovery [ Upstream commit ad86f605c59500da82d196ac312cfbac3daba31d ] nfs4_update_server unconditionally releases the nfs_client for the source server. If migration fails, this can cause the source server's nfs_client struct to be left with a low reference count, resulting in use-after-free. Also, adjust reference count handling for ELOOP. NFS: state manager: migration failed on NFSv4 server nfsvmu10 with error 6 WARNING: CPU: 16 PID: 17960 at fs/nfs/client.c:281 nfs_put_client+0xfa/0x110 [nfs]() nfs_put_client+0xfa/0x110 [nfs] nfs4_run_state_manager+0x30/0x40 [nfsv4] kthread+0xd8/0xf0 BUG: unable to handle kernel NULL pointer dereference at 00000000000002a8 nfs4_xdr_enc_write+0x6b/0x160 [nfsv4] rpcauth_wrap_req+0xac/0xf0 [sunrpc] call_transmit+0x18c/0x2c0 [sunrpc] __rpc_execute+0xa6/0x490 [sunrpc] rpc_async_schedule+0x15/0x20 [sunrpc] process_one_work+0x160/0x470 worker_thread+0x112/0x540 ? rescuer_thread+0x3f0/0x3f0 kthread+0xd8/0xf0 This bug was introduced by 32e62b7c ("NFS: Add nfs4_update_server"), but the fix applies cleanly to 52442f9b ("NFS4: Avoid migration loops") Reported-by: Helen Chao Fixes: 52442f9b11b7 ("NFS4: Avoid migration loops") Signed-off-by: Bill Baker Reviewed-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4b0a3b9a511d55fcff4b0a0c91d3661417a31c5b Author: Rob Herring Date: Thu Feb 1 15:32:40 2018 -0600 arm64: dts: cavium: fix PCI bus dtc warnings [ Upstream commit e2c8d283c4e2f468bed1bcfedb80b670b1bc8ab1 ] dtc recently added PCI bus checks. Fix these warnings: arch/arm64/boot/dts/cavium/thunder2-99xx.dtb: Warning (pci_bridge): Node /pci missing bus-range for PCI bridge arch/arm64/boot/dts/cavium/thunder2-99xx.dtb: Warning (unit_address_vs_reg): Node /pci has a reg or ranges property, but no unit name Signed-off-by: Rob Herring Cc: Jayachandran C Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e47c1bf99a14a78389d91a58a760a9154747dfe3 Author: Eric Biggers Date: Thu Feb 22 14:38:33 2018 +0000 PKCS#7: fix direct verification of SignerInfo signature [ Upstream commit 6459ae386699a5fe0dc52cf30255f75274fa43a4 ] If none of the certificates in a SignerInfo's certificate chain match a trusted key, nor is the last certificate signed by a trusted key, then pkcs7_validate_trust_one() tries to check whether the SignerInfo's signature was made directly by a trusted key. But, it actually fails to set the 'sig' variable correctly, so it actually verifies the last signature seen. That will only be the SignerInfo's signature if the certificate chain is empty; otherwise it will actually be the last certificate's signature. This is not by itself a security problem, since verifying any of the certificates in the chain should be sufficient to verify the SignerInfo. Still, it's not working as intended so it should be fixed. Fix it by setting 'sig' correctly for the direct verification case. Fixes: 757932e6da6d ("PKCS#7: Handle PKCS#7 messages that contain no X.509 certs") Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a72612a1c39dd86863c1e3af57e321ad41a26f2d Author: Li Zhijian Date: Thu Feb 22 10:34:02 2018 +0800 selftests/bpf/test_maps: exit child process without error in ENOMEM case [ Upstream commit 80475c48c6a8a65171e035e0915dc7996b5a0a65 ] test_maps contains a series of stress tests, and previously it will break the rest tests when it failed to alloc memory. ----------------------- Failed to create hashmap key=8 value=262144 'Cannot allocate memory' Failed to create hashmap key=16 value=262144 'Cannot allocate memory' Failed to create hashmap key=8 value=262144 'Cannot allocate memory' Failed to create hashmap key=8 value=262144 'Cannot allocate memory' test_maps: test_maps.c:955: run_parallel: Assertion `status == 0' failed. Aborted not ok 1..3 selftests: test_maps [FAIL] ----------------------- after this patch, the rest tests will be continue when it occurs an ENOMEM failure CC: Alexei Starovoitov CC: Philip Li Suggested-by: Daniel Borkmann Signed-off-by: Li Zhijian Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dac5d3a100c62bba3795286d44ac9200573c9c44 Author: Sebastian Ott Date: Mon Feb 12 12:01:03 2018 +0100 s390/cio: clear timer when terminating driver I/O [ Upstream commit 410d5e13e7638bc146321671e223d56495fbf3c7 ] When we terminate driver I/O (because we need to stop using a certain channel path) we also need to ensure that a timer (which may have been set up using ccw_device_start_timeout) is cleared. Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5b1b2e2185db4c5eeb72d8f61a1ba0c1f7a752c Author: Sebastian Ott Date: Wed Feb 7 13:18:19 2018 +0100 s390/cio: fix return code after missing interrupt [ Upstream commit 770b55c995d171f026a9efb85e71e3b1ea47b93d ] When a timeout occurs for users of ccw_device_start_timeout we will stop the IO and call the drivers int handler with the irb pointer set to ERR_PTR(-ETIMEDOUT). Sometimes however we'd set the irb pointer to ERR_PTR(-EIO) which is not intended. Just set the correct value in all codepaths. Reported-by: Julian Wiedmann Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5df337455c5a7a4adb1dc71a577608d63221fd1e Author: Sebastian Ott Date: Tue Feb 6 14:59:43 2018 +0100 s390/cio: fix ccw_device_start_timeout API [ Upstream commit f97a6b6c47d2f329a24f92cc0ca3c6df5727ba73 ] There are cases a device driver can't start IO because the device is currently in use by cio. In this case the device driver is notified when the device is usable again. Using ccw_device_start_timeout we would set the timeout (and change an existing timeout) before we test for internal usage. Worst case this could lead to an unexpected timer deletion. Fix this by setting the timeout after we test for internal usage. Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aa6eeca7bcd714cc1e41227aa9d9599570117742 Author: Mark Lord Date: Tue Feb 20 14:49:20 2018 -0500 powerpc/bpf/jit: Fix 32-bit JIT for seccomp_data access [ Upstream commit 083b20907185b076f21c265b30fe5b5f24c03d8c ] I am using SECCOMP to filter syscalls on a ppc32 platform, and noticed that the JIT compiler was failing on the BPF even though the interpreter was working fine. The issue was that the compiler was missing one of the instructions used by SECCOMP, so here is a patch to enable JIT for that instruction. Fixes: eb84bab0fb38 ("ppc: Kconfig: Enable BPF JIT on ppc32") Signed-off-by: Mark Lord Acked-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e1bb3673ae9dc689af2371517b3f98c5ab7e3c9a Author: Stefan Agner Date: Sun Jan 7 14:49:05 2018 +0100 soc: imx: gpc: de-register power domains only if initialized [ Upstream commit 7801c545e706674aeed40256eb806ad37b18ad71 ] If power domain information are missing in the device tree, no power domains get initialized. However, imx_gpc_remove tries to remove power domains always in the old DT binding case. Only remove power domains when imx_gpc_probe initialized them in first place. Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver") Signed-off-by: Stefan Agner Reviewed-by: Lucas Stach Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e65cd9a20343ea90f576c24c38ee85ab6e7d5fec Author: Tycho Andersen Date: Tue Feb 20 19:47:47 2018 -0700 seccomp: add a selftest for get_metadata [ Upstream commit d057dc4e35e16050befa3dda943876dab39cbf80 ] Let's test that we get the flags correctly, and that we preserve the filter index across the ptrace(PTRACE_SECCOMP_GET_METADATA) correctly. Signed-off-by: Tycho Andersen CC: Kees Cook Signed-off-by: Kees Cook Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 32e139dfb684acc630e9c3ca7b400c62cc00b1dd Author: Anders Roxell Date: Wed Feb 21 14:45:58 2018 -0800 selftests/memfd: add run_fuse_test.sh to TEST_FILES [ Upstream commit bdefe01a6b14bde268741435ac854fda4ef7e847 ] While testing memfd tests, there is a missing script, as reported by kselftest: ./run_tests.sh: line 7: ./run_fuse_test.sh: No such file or directory Link: http://lkml.kernel.org/r/1517955779-11386-1-git-send-email-daniel.diaz@linaro.org Signed-off-by: Anders Roxell Signed-off-by: Daniel Díaz Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 305eb32d45f00730f8f61a1cff111e3c4b07a766 Author: Arnd Bergmann Date: Wed Feb 21 14:45:54 2018 -0800 bug.h: work around GCC PR82365 in BUG() [ Upstream commit 173a3efd3edb2ef6ef07471397c5f542a360e9c1 ] Looking at functions with large stack frames across all architectures led me discovering that BUG() suffers from the same problem as fortify_panic(), which I've added a workaround for already. In short, variables that go out of scope by calling a noreturn function or __builtin_unreachable() keep using stack space in functions afterwards. A workaround that was identified is to insert an empty assembler statement just before calling the function that doesn't return. I'm adding a macro "barrier_before_unreachable()" to document this, and insert calls to that in all instances of BUG() that currently suffer from this problem. The files that saw the largest change from this had these frame sizes before, and much less with my patch: fs/ext4/inode.c:82:1: warning: the frame size of 1672 bytes is larger than 800 bytes [-Wframe-larger-than=] fs/ext4/namei.c:434:1: warning: the frame size of 904 bytes is larger than 800 bytes [-Wframe-larger-than=] fs/ext4/super.c:2279:1: warning: the frame size of 1160 bytes is larger than 800 bytes [-Wframe-larger-than=] fs/ext4/xattr.c:146:1: warning: the frame size of 1168 bytes is larger than 800 bytes [-Wframe-larger-than=] fs/f2fs/inode.c:152:1: warning: the frame size of 1424 bytes is larger than 800 bytes [-Wframe-larger-than=] net/netfilter/ipvs/ip_vs_core.c:1195:1: warning: the frame size of 1068 bytes is larger than 800 bytes [-Wframe-larger-than=] net/netfilter/ipvs/ip_vs_core.c:395:1: warning: the frame size of 1084 bytes is larger than 800 bytes [-Wframe-larger-than=] net/netfilter/ipvs/ip_vs_ftp.c:298:1: warning: the frame size of 928 bytes is larger than 800 bytes [-Wframe-larger-than=] net/netfilter/ipvs/ip_vs_ftp.c:418:1: warning: the frame size of 908 bytes is larger than 800 bytes [-Wframe-larger-than=] net/netfilter/ipvs/ip_vs_lblcr.c:718:1: warning: the frame size of 960 bytes is larger than 800 bytes [-Wframe-larger-than=] drivers/net/xen-netback/netback.c:1500:1: warning: the frame size of 1088 bytes is larger than 800 bytes [-Wframe-larger-than=] In case of ARC and CRIS, it turns out that the BUG() implementation actually does return (or at least the compiler thinks it does), resulting in lots of warnings about uninitialized variable use and leaving noreturn functions, such as: block/cfq-iosched.c: In function 'cfq_async_queue_prio': block/cfq-iosched.c:3804:1: error: control reaches end of non-void function [-Werror=return-type] include/linux/dmaengine.h: In function 'dma_maxpq': include/linux/dmaengine.h:1123:1: error: control reaches end of non-void function [-Werror=return-type] This makes them call __builtin_trap() instead, which should normally dump the stack and kill the current process, like some of the other architectures already do. I tried adding barrier_before_unreachable() to panic() and fortify_panic() as well, but that had very little effect, so I'm not submitting that patch. Vineet said: : For ARC, it is double win. : : 1. Fixes 3 -Wreturn-type warnings : : | ../net/core/ethtool.c:311:1: warning: control reaches end of non-void function : [-Wreturn-type] : | ../kernel/sched/core.c:3246:1: warning: control reaches end of non-void function : [-Wreturn-type] : | ../include/linux/sunrpc/svc_xprt.h:180:1: warning: control reaches end of : non-void function [-Wreturn-type] : : 2. bloat-o-meter reports code size improvements as gcc elides the : generated code for stack return. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365 Link: http://lkml.kernel.org/r/20171219114112.939391-1-arnd@arndb.de Signed-off-by: Arnd Bergmann Acked-by: Vineet Gupta [arch/arc] Tested-by: Vineet Gupta [arch/arc] Cc: Mikael Starvik Cc: Jesper Nilsson Cc: Tony Luck Cc: Fenghua Yu Cc: Geert Uytterhoeven Cc: "David S. Miller" Cc: Christopher Li Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Kees Cook Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Will Deacon Cc: "Steven Rostedt (VMware)" Cc: Mark Rutland Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 14488f25339e40444c578d49b422f9e40673fd9a Author: David Rientjes Date: Wed Feb 21 14:45:32 2018 -0800 kernel/relay.c: limit kmalloc size to KMALLOC_MAX_SIZE [ Upstream commit 88913bd8ea2a75d7e460a4bed5f75e1c32660d7e ] chan->n_subbufs is set by the user and relay_create_buf() does a kmalloc() of chan->n_subbufs * sizeof(size_t *). kmalloc_slab() will generate a warning when this fails if chan->subbufs * sizeof(size_t *) > KMALLOC_MAX_SIZE. Limit chan->n_subbufs to the maximum allowed kmalloc() size. Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1802061216100.122576@chino.kir.corp.google.com Fixes: f6302f1bcd75 ("relay: prevent integer overflow in relay_open()") Signed-off-by: David Rientjes Reviewed-by: Andrew Morton Cc: Jens Axboe Cc: Dave Jiang Cc: Al Viro Cc: Dan Carpenter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cf15cd63000bb800b2a3b455054186fb093b518d Author: Jesper Dangaard Brouer Date: Tue Feb 20 14:32:10 2018 +0100 virtio_net: fix XDP code path in receive_small() [ Upstream commit 95dbe9e7b3720efa5cf83d21f44f6d953f7cf4a2 ] When configuring virtio_net to use the code path 'receive_small()', in-order to get correct XDP_REDIRECT support, I discovered TCP packets would get silently dropped when loading an XDP program action XDP_PASS. The bug seems to be that receive_small() when XDP is loaded check that hdr->hdr.flags is zero, which seems wrong as hdr.flags contains the flags VIRTIO_NET_HDR_F_* : #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */ #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */ TCP got dropped as it had the VIRTIO_NET_HDR_F_DATA_VALID flag set. The flags that are relevant here are the VIRTIO_NET_HDR_GSO_* flags stored in hdr->hdr.gso_type. Thus, the fix is just check that none of the gso_type flags have been set. Fixes: bb91accf2733 ("virtio-net: XDP support for small buffers") Signed-off-by: Jesper Dangaard Brouer Acked-by: John Fastabend Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0e498db68095a466fe00c757f1bba5ce401cd375 Author: Arnd Bergmann Date: Tue Feb 20 14:09:11 2018 +0100 md: raid5: avoid string overflow warning [ Upstream commit 53b8d89ddbdbb0e4625a46d2cdbb6f106c52f801 ] gcc warns about a possible overflow of the kmem_cache string, when adding four characters to a string of the same length: drivers/md/raid5.c: In function 'setup_conf': drivers/md/raid5.c:2207:34: error: '-alt' directive writing 4 bytes into a region of size between 1 and 32 [-Werror=format-overflow=] sprintf(conf->cache_name[1], "%s-alt", conf->cache_name[0]); ^~~~ drivers/md/raid5.c:2207:2: note: 'sprintf' output between 5 and 36 bytes into a destination of size 32 sprintf(conf->cache_name[1], "%s-alt", conf->cache_name[0]); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If I'm counting correctly, we need 11 characters for the fixed part of the string and 18 characters for a 64-bit pointer (when no gendisk is used), so that leaves three characters for conf->level, which should always be sufficient. This makes the code use snprintf() with the correct length, to make the code more robust against changes, and to get the compiler to shut up. In commit f4be6b43f1ac ("md/raid5: ensure we create a unique name for kmem_cache when mddev has no gendisk") from 2010, Neil said that the pointer could be removed "shortly" once devices without gendisk are disallowed. I have no idea if that happened, but if it did, that should probably be changed as well. Signed-off-by: Arnd Bergmann Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ca353544670d9448033645a0d5c0bf0d9d90fed5 Author: Andrea Parri Date: Tue Feb 20 19:45:56 2018 +0100 locking/xchg/alpha: Add unconditional memory barrier to cmpxchg() [ Upstream commit cb13b424e986aed68d74cbaec3449ea23c50e167 ] Continuing along with the fight against smp_read_barrier_depends() [1] (or rather, against its improper use), add an unconditional barrier to cmpxchg. This guarantees that dependency ordering is preserved when a dependency is headed by an unsuccessful cmpxchg. As it turns out, the change could enable further simplification of LKMM as proposed in [2]. [1] https://marc.info/?l=linux-kernel&m=150884953419377&w=2 https://marc.info/?l=linux-kernel&m=150884946319353&w=2 https://marc.info/?l=linux-kernel&m=151215810824468&w=2 https://marc.info/?l=linux-kernel&m=151215816324484&w=2 [2] https://marc.info/?l=linux-kernel&m=151881978314872&w=2 Signed-off-by: Andrea Parri Acked-by: Peter Zijlstra Acked-by: Paul E. McKenney Cc: Alan Stern Cc: Ivan Kokshaysky Cc: Linus Torvalds Cc: Matt Turner Cc: Richard Henderson Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-alpha@vger.kernel.org Link: http://lkml.kernel.org/r/1519152356-4804-1-git-send-email-parri.andrea@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit badacb781dce84a4942071828c2c248482055d66 Author: Or Gerlitz Date: Tue Jan 30 13:16:58 2018 +0200 net/mlx5e: Return error if prio is specified when offloading eswitch vlan push [ Upstream commit 001a2fc0c8cc29241305e44ffbce52d1daf8782b ] This isn't supported when we emulate eswitch vlan push action which is the current state of things. Fixes: 8b32580df1cb ('net/mlx5e: Add TC vlan action for SRIOV offloads') Signed-off-by: Or Gerlitz Reviewed-by: Mark Bloch Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2e9f41ace36b52039ce195a9109cb221a8ad93d2 Author: Thomas Falcon Date: Mon Feb 19 20:12:57 2018 -0600 ibmvnic: Check for NULL skb's in NAPI poll routine [ Upstream commit abe27a885d9e6575e663a16176dabc58ce9d7188 ] After introduction of commit d0869c0071e4, there were some instances of RX queue entries from a previous session (before the device was closed and reopened) returned to the NAPI polling routine. Since the corresponding socket buffers were freed, this resulted in a panic on reopen. Include a check for a NULL skb here to avoid this. Fixes: d0869c0071e4 ("ibmvnic: Clean RX pool buffers during device close") Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 775cc792bb0879d65f7fa446ce4bd82096447e34 Author: Selvin Xavier Date: Thu Feb 15 21:20:12 2018 -0800 RDMA/bnxt_re: Fix system crash during load/unload [ Upstream commit dcdaba08062b4726500b9456f8664bfda896c664 ] During driver unload, the driver proceeds with cleanup without waiting for the scheduled events. So the device pointers get freed up and driver crashes when the events are scheduled later. Flush the bnxt_re_task work queue before starting device removal. Signed-off-by: Selvin Xavier Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c0935f1ef990a50cc891aede2b4298038a1c5504 Author: Devesh Sharma Date: Thu Feb 15 21:20:10 2018 -0800 RDMA/bnxt_re: Unpin SQ and RQ memory if QP create fails [ Upstream commit 6b4521f5174c26020ae0deb3ef7f2c28557cf445 ] Driver leaves the QP memory pinned if QP create command fails from the FW. Avoids this scenario by adding a proper exit path if the FW command fails. Signed-off-by: Devesh Sharma Signed-off-by: Selvin Xavier Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5c0632b9c7b80914f8704b10e2ebd4adf41ed2a Author: Mark Rutland Date: Wed Feb 14 17:21:57 2018 +0000 arm64: perf: correct PMUVer probing [ Upstream commit 0331365edb1d6ccd6ae68b1038111da85d4c68d1 ] The ID_AA64DFR0_EL1.PMUVer field doesn't follow the usual ID registers scheme. While value 0xf indicates a non-architected PMU is implemented, values 0x1 to 0xe indicate an increasingly featureful architected PMU, as if the field were unsigned. For more details, see ARM DDI 0487C.a, D10.1.4, "Alternative ID scheme used for the Performance Monitors Extension version". Currently, we treat the field as signed, and erroneously bail out for values 0x8 to 0xe. Let's correct that. Signed-off-by: Mark Rutland Reviewed-by: Robin Murphy Cc: Will Deacon Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 33b3f7b5af5dbd7364c98845350e68b325c8f265 Author: Neil Armstrong Date: Thu Feb 15 11:19:36 2018 +0100 drm/meson: fix vsync buffer update [ Upstream commit e88230a3744a71a0b5ecfb45e08ddfe1c884e50d ] The plane buffer address/stride/height was incorrectly updated in the plane_atomic_update operation instead of the vsync irq. This patch delays this operation in the vsync irq along with the other plane delayed setup. This issue was masked using legacy framebuffer and X11 modesetting, but is clearly visible using gbm rendering when buffer is submitted late after vblank, like using software decoding and OpenGL rendering in Kodi. With this patch, tearing and other artifacts disappears completely. Cc: Michal Lazo Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Neil Armstrong Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1518689976-23292-1-git-send-email-narmstrong@baylibre.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2c6a5cc09b46a6478ed7c0597b2f92906b87d7e7 Author: Wolfram Sang Date: Mon Feb 5 21:09:59 2018 +0100 drm/exynos: fix comparison to bitshift when dealing with a mask [ Upstream commit 1293b6191010672c0c9dacae8f71c6f3e4d70cbe ] Due to a typo, the mask was destroyed by a comparison instead of a bit shift. Signed-off-by: Wolfram Sang Signed-off-by: Inki Dae Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f925cc2d3995f56be58b10870f4f424300b8ad8 Author: Arnd Bergmann Date: Wed Jan 17 18:01:21 2018 +0100 drm/exynos: g2d: use monotonic timestamps [ Upstream commit a588a8bb7b25a3fb4f7fed00feb7aec541fc2632 ] The exynos DRM driver uses real-time 'struct timeval' values for exporting its timestamps to user space. This has multiple problems: 1. signed seconds overflow in y2038 2. the 'struct timeval' definition is deprecated in the kernel 3. time may jump or go backwards after a 'settimeofday()' syscall 4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they can't be compared 5. exporting microseconds requires a division by 1000, which may be slow on some architectures. The code existed in two places before, but the IPP portion was removed in 8ded59413ccc ("drm/exynos: ipp: Remove Exynos DRM IPP subsystem"), so we no longer need to worry about it. Ideally timestamps should just use 64-bit nanoseconds instead, but of course we can't change that now. Instead, this tries to address the first four points above by using monotonic 'timespec' values. According to Tobias Jakobi, user space doesn't care about the timestamp at the moment, so we can change the format. Even if there is something looking at them, it will work just fine with monotonic times as long as the application only looks at the relative values between two events. Link: https://patchwork.kernel.org/patch/10038593/ Cc: Tobias Jakobi Signed-off-by: Arnd Bergmann Reviewed-by: Tobias Jakobi Signed-off-by: Inki Dae Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5db4c271ca5b9ab0c7809c44462d469e77487be Author: Yufen Yu Date: Tue Feb 6 17:39:15 2018 +0800 md raid10: fix NULL deference in handle_write_completed() [ Upstream commit 01a69cab01c184d3786af09e9339311123d63d22 ] In the case of 'recover', an r10bio with R10BIO_WriteError & R10BIO_IsRecover will be progressed by handle_write_completed(). This function traverses all r10bio->devs[copies]. If devs[m].repl_bio != NULL, it thinks conf->mirrors[dev].replacement is also not NULL. However, this is not always true. When there is an rdev of raid10 has replacement, then each r10bio ->devs[m].repl_bio != NULL in conf->r10buf_pool. However, in 'recover', even if corresponded replacement is NULL, it doesn't clear r10bio ->devs[m].repl_bio, resulting in replacement NULL deference. This bug was introduced when replacement support for raid10 was added in Linux 3.3. As NeilBrown suggested: Elsewhere the determination of "is this device part of the resync/recovery" is made by resting bio->bi_end_io. If this is end_sync_write, then we tried to write here. If it is NULL, then we didn't try to write. Fixes: 9ad1aefc8ae8 ("md/raid10: Handle replacement devices during resync.") Cc: stable (V3.3+) Suggested-by: NeilBrown Signed-off-by: Yufen Yu Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3ed913b61e6a3cde1e8ef93123e183dc5ea17e12 Author: Tobias Jordan Date: Thu Feb 15 15:35:30 2018 +0100 gpu: ipu-v3: prg: fix device node leak in ipu_prg_lookup_by_phandle [ Upstream commit 3addaba8141bc6a4f649a48f46e552af32922147 ] Before returning, call of_node_put() for the device node returned by of_parse_phandle(). Fixes: ea9c260514c1 ("gpu: ipu-v3: add driver for Prefetch Resolve Gasket") Signed-off-by: Tobias Jordan Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9ccb1d53c6ac959abba61ba446585cb7f1c5b6c9 Author: Tobias Jordan Date: Thu Feb 15 15:34:55 2018 +0100 gpu: ipu-v3: pre: fix device node leak in ipu_pre_lookup_by_phandle [ Upstream commit c795f3052b60b01e80485fad98c53e5e67d093c9 ] Before returning, call of_node_put() for the device node returned by of_parse_phandle(). Fixes: d2a34232580a ("gpu: ipu-v3: add driver for Prefetch Resolve Engine") Signed-off-by: Tobias Jordan Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8dcb7ddb2c8356cd8f19324f97c3aa3e4da70889 Author: Ilan Peer Date: Mon Feb 19 14:48:43 2018 +0200 mac80211: Fix sending ADDBA response for an ongoing session [ Upstream commit 3b07029729e347f288c70227cfe3c66b085d6b0b ] In case an ADDBA request is received while there is already an ongoing BA sessions with the same parameters, i.e., update flow, an ADBBA response with decline status was sent twice. Fix it. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 707c81727baa201e125241f5a82cc5726fa3f7a6 Author: Ilan Peer Date: Mon Feb 19 14:48:42 2018 +0200 mac80211: Do not disconnect on invalid operating class [ Upstream commit 191da271ac260700db3e5b4bb982a17ca78769d6 ] Some APs include a non global operating class in their extended channel switch information element. In such a case, as the operating class is not known, mac80211 would decide to disconnect. However the specification states that the operating class needs to be taken from Annex E, but it does not specify from which table it should be taken, so it is valid for an AP to use a non global operating class. To avoid possibly unneeded disconnection, in such a case ignore the operating class and assume that the current band is used, and if the resulting channel and band configuration is invalid disconnect. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f6bfc88f14cc176d9dae7739ab19a3e59b101f57 Author: Avraham Stern Date: Mon Feb 19 14:48:38 2018 +0200 cfg80211: clear wep keys after disconnection [ Upstream commit 3027a8e799b20fc922496a12f8ad2f9f36a8a696 ] When a low level driver calls cfg80211_disconnected(), wep keys are not cleared. As a result, following connection requests will fail since cfg80211 internal state shows a connection is still in progress. Fix this by clearing the wep keys when disconnecting. Signed-off-by: Avraham Stern Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a7f126b2e1ad9f4ae347d31f48946e129a86fc3f Author: Sara Sharon Date: Mon Feb 19 14:48:37 2018 +0200 mac80211: fix calling sleeping function in atomic context [ Upstream commit 95f3ce6a77893ac828ba841df44421620de4314b ] sta_info_alloc can be called from atomic paths (such as RX path) so we need to call pcpu_alloc with the correct gfp. Fixes: c9c5962b56c1 ("mac80211: enable collecting station statistics per-CPU") Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 99d4fe95e4f6289176a403722e5c8dd5815a64a8 Author: Sara Sharon Date: Mon Feb 19 14:48:35 2018 +0200 mac80211: fix a possible leak of station stats [ Upstream commit d78d9ee9d40aca4781d2c5334972544601a4c3a2 ] If sta_info_alloc fails after allocating the per CPU statistics, they are not properly freed. Fixes: c9c5962b56c1 ("mac80211: enable collecting station statistics per-CPU") Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f49e3a9acc524b8641bcacf8e33a1cac27371213 Author: Felix Fietkau Date: Sat Feb 10 13:20:34 2018 +0100 mac80211: round IEEE80211_TX_STATUS_HEADROOM up to multiple of 4 [ Upstream commit 651b9920d7a694ffb1f885aef2bbb068a25d9d66 ] This ensures that mac80211 allocated management frames are properly aligned, which makes copying them more efficient. For instance, mt76 uses iowrite32_copy to copy beacon frames to beacon template memory on the chip. Misaligned 32-bit accesses cause CPU exceptions on MIPS and should be avoided. Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 020c32a91ee0d2744479dad9b2f8aab8a7081024 Author: Xin Long Date: Sat Feb 17 15:16:22 2018 +0800 xfrm: do not call rcu_read_unlock when afinfo is NULL in xfrm_get_tos [ Upstream commit 143a4454daaf0e80a2b9f37159a0d6d2b61e64ed ] When xfrm_policy_get_afinfo returns NULL, it will not hold rcu read lock. In this case, rcu_read_unlock should not be called in xfrm_get_tos, just like other places where it's calling xfrm_policy_get_afinfo. Fixes: f5e2bb4f5b22 ("xfrm: policy: xfrm_get_tos cannot fail") Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d0d9330fa2a382dbe09574e6d3f69d24ca242ab9 Author: Stefan Haberland Date: Wed Feb 7 17:39:14 2018 +0100 s390/dasd: fix handling of internal requests [ Upstream commit 9487cfd3430d07366801886bdf185799a2b6f066 ] Internal DASD device driver I/O such as query host access count or path verification is started using the _sleep_on() function. To mark a request as started or ended the callback_data is set to either DASD_SLEEPON_START_TAG or DASD_SLEEPON_END_TAG. In cases where the request has to be stopped unconditionally the status is set to DASD_SLEEPON_END_TAG as well which leads to immediate clearing of the request. But the request might still be on a device request queue for normal operation which might lead to a panic because of a BUG() statement in __dasd_device_process_final_queue() or a list corruption of the device request queue. Fix by removing the setting of DASD_SLEEPON_END_TAG in the dasd_cancel_req() and dasd_generic_requeue_all_requests() functions and ensure that the request is not deleted in the requeue function. Trigger the device tasklet in the requeue function and let the normal processing cleanup the request. Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e08f866978350ecc9dd90a2cfeb907b2abb74392 Author: Heinz Mauelshagen Date: Fri Feb 2 23:13:19 2018 +0100 md: fix md_write_start() deadlock w/o metadata devices [ Upstream commit 4b6c1060eaa6495aa5b0032e8f2d51dd936b1257 ] If no metadata devices are configured on raid1/4/5/6/10 (e.g. via dm-raid), md_write_start() unconditionally waits for superblocks to be written thus deadlocking. Fix introduces mddev->has_superblocks bool, defines it in md_run() and checks for it in md_write_start() to conditionally avoid waiting. Once on it, check for non-existing superblocks in md_super_write(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=198647 Fixes: cc27b0c78c796 ("md: fix deadlock between mddev_suspend() and md_write_start()") Signed-off-by: Heinz Mauelshagen Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ca4363bf7cb882aa725762bdfa2e1e87ac431e2f Author: Xiao Ni Date: Wed Jan 24 12:17:38 2018 +0800 MD: Free bioset when md_run fails [ Upstream commit b126194cbb799f9980b92a77e58db6ad794c8082 ] Signed-off-by: Xiao Ni Acked-by: Guoqing Jiang Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f146c6e6506fe9a3c9578caddcf0f9837bd6a90f Author: David Howells Date: Thu Feb 15 22:59:00 2018 +0000 rxrpc: Work around usercopy check [ Upstream commit a16b8d0cf2ec1e626d24bc2a7b9e64ace6f7501d ] Due to a check recently added to copy_to_user(), it's now not permitted to copy from slab-held data to userspace unless the slab is whitelisted. This affects rxrpc_recvmsg() when it attempts to place an RXRPC_USER_CALL_ID control message in the userspace control message buffer. A warning is generated by usercopy_warn() because the source is the copy of the user_call_ID retained in the rxrpc_call struct. Work around the issue by copying the user_call_ID to a variable on the stack and passing that to put_cmsg(). The warning generated looks like: Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'dmaengine-unmap-128' (offset 680, size 8)! WARNING: CPU: 0 PID: 1401 at mm/usercopy.c:81 usercopy_warn+0x7e/0xa0 ... RIP: 0010:usercopy_warn+0x7e/0xa0 ... Call Trace: __check_object_size+0x9c/0x1a0 put_cmsg+0x98/0x120 rxrpc_recvmsg+0x6fc/0x1010 [rxrpc] ? finish_wait+0x80/0x80 ___sys_recvmsg+0xf8/0x240 ? __clear_rsb+0x25/0x3d ? __clear_rsb+0x15/0x3d ? __clear_rsb+0x25/0x3d ? __clear_rsb+0x15/0x3d ? __clear_rsb+0x25/0x3d ? __clear_rsb+0x15/0x3d ? __clear_rsb+0x25/0x3d ? __clear_rsb+0x15/0x3d ? finish_task_switch+0xa6/0x2b0 ? trace_hardirqs_on_caller+0xed/0x180 ? _raw_spin_unlock_irq+0x29/0x40 ? __sys_recvmsg+0x4e/0x90 __sys_recvmsg+0x4e/0x90 do_syscall_64+0x7a/0x220 entry_SYSCALL_64_after_hwframe+0x26/0x9b Reported-by: Jonathan Billings Signed-off-by: David Howells Acked-by: Kees Cook Tested-by: Jonathan Billings Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 54881db3251a48f9a27ac8b7223a9b421757d395 Author: Kees Cook Date: Wed Feb 14 15:45:07 2018 -0800 NFC: llcp: Limit size of SDP URI [ Upstream commit fe9c842695e26d8116b61b80bfb905356f07834b ] The tlv_len is u8, so we need to limit the size of the SDP URI. Enforce this both in the NLA policy and in the code that performs the allocation and copy, to avoid writing past the end of the allocated buffer. Fixes: d9b8d8e19b073 ("NFC: llcp: Service Name Lookup netlink interface") Signed-off-by: Kees Cook Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e5ea0a89bf7b2efb19beebaa683e42f6e99a1b85 Author: Naftali Goldstein Date: Thu Dec 28 15:53:04 2017 +0200 iwlwifi: mvm: always init rs with 20mhz bandwidth rates [ Upstream commit 6b7a5aea71b342ec0593d23b08383e1f33da4c9a ] In AP mode, when a new station associates, rs is initialized immediately upon association completion, before the phy context is updated with the association parameters, so the sta bandwidth might be wider than the phy context allows. To avoid this issue, always initialize rs with 20mhz bandwidth rate, and after authorization, when the phy context is already up-to-date, re-init rs with the correct bw. Signed-off-by: Naftali Goldstein Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6e752ba6436bc51d66ca9b302ae0a3d35427ec2b Author: Sara Sharon Date: Thu Dec 21 15:05:28 2017 +0200 iwlwifi: mvm: fix IBSS for devices that support station type API [ Upstream commit fc07bd8ce19bff9e7479c04077ddb5957d1a27be ] In IBSS, the mac80211 sets the cab_queue to be invalid. However, the multicast station uses it, so we need to override it. A previous patch did it, but it was nested inside the if's and was applied only for legacy FWs that don't support the new station type API, instead of being applied for all paths. In addition, add a missing NL80211_IFTYPE_ADHOC to the initialization of the queues in iwl_mvm_mac_ctxt_init() Fixes: ee48b72211f8 ("iwlwifi: mvm: support ibss in dqa mode") Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8c1cc43e745d86092f1c5b2d0a58d7879b119d27 Author: Sara Sharon Date: Tue Mar 29 10:56:57 2016 +0300 iwlwifi: mvm: fix security bug in PN checking [ Upstream commit 5ab2ba931255d8bf03009c06d58dce97de32797c ] A previous patch allowed the same PN for packets originating from the same AMSDU by copying PN only for the last packet in the series. This however is bogus since we cannot assume the last frame will be received on the same queue, and if it is received on a different ueue we will end up not incrementing the PN and possibly let the next packet to have the same PN and pass through. Change the logic instead to driver explicitly indicate for the second sub frame and on to be allowed to have the same PN as the first subframe. Indicate it to mac80211 as well for the fallback queue. Fixes: f1ae02b186d9 ("iwlwifi: mvm: allow same PN for de-aggregated AMSDU") Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1510627c63b77210f9501c4c1c13b915883dec78 Author: Robin Murphy Date: Thu Feb 15 14:05:54 2018 +0000 ARM: dts: rockchip: Fix DWMMC clocks [ Upstream commit e78c637127ee7683d606737f2e62b5da6fd7b1c3 ] Trying to boot an RK3328 box with an HS200-capable eMMC, I see said eMMC fail to initialise as it can't run its tuning procedure, because the sample clock is missing. Upon closer inspection, whilst the clock is present in the DT, its name is subtly incorrect per the binding, so __of_clk_get_by_name() never finds it. By inspection, the drive clock suffers from a similar problem, so has never worked properly either. This error has propagated across the 32-bit DTs too, so fix those up. Fixes: 187d7967a5ee ("ARM: dts: rockchip: add the sdio/sdmmc node for rk3036") Fixes: faea098e1808 ("ARM: dts: rockchip: add core rk3036 dtsi") Fixes: 9848ebeb952d ("ARM: dts: rockchip: add core rk3228 dtsi") Signed-off-by: Robin Murphy Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 23b738ce746a151c13f2c53ea6cd95e350e3d659 Author: Robin Murphy Date: Thu Feb 15 14:05:53 2018 +0000 arm64: dts: rockchip: Fix DWMMC clocks [ Upstream commit ca9eee95a2decc6f60bed65b5b836a26bff825c1 ] Trying to boot an RK3328 box with an HS200-capable eMMC, I see said eMMC fail to initialise as it can't run its tuning procedure, because the sample clock is missing. Upon closer inspection, whilst the clock is present in the DT, its name is subtly incorrect per the binding, so __of_clk_get_by_name() never finds it. By inspection, the drive clock suffers from a similar problem, so has never worked properly either. Fix up all instances of the incorrect clock names across the 64-bit DTs. Fixes: d717f7352ec6 ("arm64: dts: rockchip: add sdmmc/sdio/emmc nodes for RK3328 SoCs") Fixes: b790c2cab5ca ("arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88 board") Signed-off-by: Robin Murphy Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 357b528e6b701314c34f10afa34a408c4eca0f65 Author: Jason Gunthorpe Date: Tue Feb 13 12:18:40 2018 +0200 IB/uverbs: Fix unbalanced unlock on error path for rdma_explicit_destroy [ Upstream commit ec6f8401c48a86809237e86878a6fac6b281118f ] If remove_commit fails then the lock is left locked while the uobj still exists. Eventually the kernel will deadlock. lockdep detects this and says: test/4221 is leaving the kernel with locks still held! 1 lock held by test/4221: #0: (&ucontext->cleanup_rwsem){.+.+}, at: [<000000001e5c7523>] rdma_explicit_destroy+0x37/0x120 [ib_uverbs] Fixes: 4da70da23e9b ("IB/core: Explicitly destroy an object while keeping uobject") Signed-off-by: Leon Romanovsky Reviewed-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5b0622bfe6371b132a4e54d1cb2e7534386fa801 Author: Matan Barak Date: Tue Feb 13 12:18:35 2018 +0200 IB/uverbs: Fix possible oops with duplicate ioctl attributes [ Upstream commit 4d39a959bc1f3d164b5a54147fdeb19f84b1ed58 ] If the same attribute is listed twice by the user in the ioctl attribute list then error unwind can cause the kernel to deref garbage. This happens when an object with WRITE access is sent twice. The second parse properly fails but corrupts the state required for the error unwind it triggers. Fixing this by making duplicates in the attribute list invalid. This is not something we need to support. The ioctl interface is currently recommended to be disabled in kConfig. Signed-off-by: Matan Barak Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cdd37f48d6a09caa30f35b3068e0922e604d8408 Author: Matan Barak Date: Tue Feb 13 12:18:32 2018 +0200 IB/uverbs: Fix method merging in uverbs_ioctl_merge [ Upstream commit 3d89459e2ef92cc0e5a50dde868780ccda9786c1 ] Fix a bug in uverbs_ioctl_merge that looked at the object's iterator number instead of the method's iterator number when merging methods. While we're at it, make the uverbs_ioctl_merge code a bit more clear and faster. Fixes: 118620d3686b ('IB/core: Add uverbs merge trees functionality') Signed-off-by: Matan Barak Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 44ef222ad099c0293e360eaba84193b9ad467a5d Author: Joe Lee Date: Mon Feb 12 14:24:46 2018 +0200 xhci: workaround for AMD Promontory disabled ports wakeup [ Upstream commit bde0716d1f076e4c913c7946bcc858f71243c7a0 ] For AMD Promontory xHCI host, although you can disable USB ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the PORT_WAKE_BITS. [commit and code comment rephrasing -Mathias] Signed-off-by: Joe Lee Signed-off-by: Mathias Nyman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 94203f213c1938aec35f063c411bc5a73a9b814b Author: Boris Pismenny Date: Wed Feb 14 10:46:06 2018 +0200 tls: retrun the correct IV in getsockopt [ Upstream commit a1dfa6812b682eef750412dd5a90e7d38d7af068 ] Current code returns four bytes of salt followed by four bytes of IV. This patch returns all eight bytes of IV. fixes: 3c4d7559159b ("tls: kernel TLS support") Signed-off-by: Boris Pismenny Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cec7d77a1db83c6b9dfdac5b6963cd1cdaaacb77 Author: Thomas Falcon Date: Tue Feb 13 18:23:43 2018 -0600 ibmvnic: Clean RX pool buffers during device close [ Upstream commit d0869c0071e40c4407d1a4d7c9497653cf47253b ] During device close or reset, there were some cases of outstanding RX socket buffers not being freed. Include a function similar to the one that already exists to clean TX socket buffers in this case. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 322d7195572de565d170b04f2d7d819b21e75ee8 Author: Thomas Falcon Date: Tue Feb 13 18:23:42 2018 -0600 ibmvnic: Free RX socket buffer in case of adapter error [ Upstream commit 4b9b0f01350500173f17e2b2e65beb4df4ef99c7 ] If a RX buffer is returned to the client driver with an error, free the corresponding socket buffer before continuing. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4431066edd13f20964626689ccabd7ac315444a7 Author: Thomas Falcon Date: Tue Feb 13 15:32:50 2018 -0600 ibmvnic: Wait until reset is complete to set carrier on [ Upstream commit cc85c02edfe48a34865ae00f7d22298a3fdd17aa ] Pushes back setting the carrier on until the end of the reset code. This resolves a bug where a watchdog timer was detecting that a TX queue had stalled before the adapter reset was complete. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ddca5c776fff3dac6f3b5ef94dbb25133fd4799b Author: Geert Uytterhoeven Date: Tue Jan 2 16:25:35 2018 +0100 ARM: OMAP1: clock: Fix debugfs_create_*() usage [ Upstream commit 8cbbf1745dcde7ba7e423dc70619d223de90fd43 ] When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, depending on data type. Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs. Correct all wrong usage: - clk.rate is unsigned long, not u32, - clk.flags is u8, not u32, which exposed the successive clk.rate_offset and clk.src_offset fields. Signed-off-by: Geert Uytterhoeven Acked-by: Aaro Koskinen Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d615dddc6e0c298fc42454364fe48b884c979a4c Author: Tony Lindgren Date: Fri Feb 9 09:35:56 2018 -0800 ARM: OMAP2+: Fix sar_base inititalization for HS omaps [ Upstream commit fe27f16794f313f5fc16f6d2f42d8c2b2f4d70cc ] HS omaps use irq_save_secure_context() instead of irq_save_context() so sar_base will never get initialized and irq_sar_clear() gets called with a wrong address for HS omaps from irq_restore_context(). Starting with commit f4b9f40ae95b ("ARM: OMAP4+: Initialize SAR RAM base early for proper CPU1 reset for kexec") we have it available, and this ideally would been fixed with that commit already. Fixes: f4b9f40ae95b ("ARM: OMAP4+: Initialize SAR RAM base early for proper CPU1 reset for kexec") Cc: Andrew F. Davis Cc: Dave Gerlach Cc: Keerthy Cc: Santosh Shilimkar Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c22e3886fc6549624f4f588efa8d9ef4c70b51a7 Author: Tony Lindgren Date: Fri Feb 9 08:15:53 2018 -0800 ARM: OMAP3: Fix prm wake interrupt for resume [ Upstream commit d3be6d2a08bd26580562d9714d3d97ea9ba22c73 ] For platform_suspend_ops, the finish call is too late to re-enable wake irqs and we need re-enable wake irqs on wake call instead. Otherwise noirq resume for devices has already happened. And then dev_pm_disarm_wake_irq() has already disabled the dedicated wake irqs when the interrupt triggers and the wake irq is never handled. For devices that are already in PM runtime suspended state when we enter suspend this means that a possible wake irq will never trigger. And this can lead into a situation where a device has a pending padconf wake irq, and the device will stay unresponsive to any further wake irqs. This issue can be easily reproduced by setting serial console log level to zero, letting the serial console idle, and suspend the system from an ssh terminal. Then try to wake up the system by typing to the serial console. Note that this affects only omap3 PRM interrupt as that's currently the only omap variant that does anything in omap_pm_wake(). In general, for the wake irqs to work, the interrupt must have either IRQF_NO_SUSPEND or IRQF_EARLY_RESUME set for it to trigger before dev_pm_disarm_wake_irq() disables the wake irqs. Reported-by: Grygorii Strashko Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7ffe100ce67c9ca9e2ef41dacac94793d8cdbde7 Author: Qi Hou Date: Thu Jan 11 12:54:43 2018 +0800 ARM: OMAP2+: timer: fix a kmemleak caused in omap_get_timer_dt [ Upstream commit db35340c536f1af0108ec9a0b2126a05d358d14a ] When more than one GP timers are used as kernel system timers and the corresponding nodes in device-tree are marked with the same "disabled" property, then the "attr" field of the property will be initialized more than once as the property being added to sys file system via __of_add_property_sysfs(). In __of_add_property_sysfs(), the "name" field of pp->attr.attr is set directly to the return value of safe_name(), without taking care of whether it's already a valid pointer to a memory block. If it is, its old value will always be overwritten by the new one and the memory block allocated before will a "ghost", then a kmemleak happened. That the same "disabled" property being added to different nodes of device tree would cause that kind of kmemleak overhead, at least once. To fix it, allocate the property dynamically, and delete static one. Signed-off-by: Qi Hou Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b2f5d98f3300b4035a700fb1cfdb5e07cc2b45bf Author: Anders Roxell Date: Tue Feb 6 16:20:44 2018 -0600 selftests: memfd: add config fragment for fuse [ Upstream commit 9a606f8d55cfc932ec02172aaed4124fdc150047 ] The memfd test requires to insert the fuse module (CONFIG_FUSE_FS). Signed-off-by: Anders Roxell Signed-off-by: Daniel Díaz Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b9ddf39dd5791da516d56bd013c174b60c7884e0 Author: Naresh Kamboju Date: Wed Feb 7 14:47:20 2018 +0530 selftests: pstore: Adding config fragment CONFIG_PSTORE_RAM=m [ Upstream commit 9a379e77033f02c4a071891afdf0f0a01eff8ccb ] pstore_tests and pstore_post_reboot_tests need CONFIG_PSTORE_RAM=m Signed-off-by: Naresh Kamboju Acked-by: Kees Cook Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a666ad4bbcfbf9db0d9402d98d2406abf1cbabc9 Author: Dominik Brodowski Date: Sun Feb 11 11:59:50 2018 +0100 selftest/vDSO: fix O= [ Upstream commit 70b574e7d719bdf96d26528cb289f3e782e83979 ] The vDSO selftests ignored the O= or KBUILD_OUTPUT= parameters. Fix it. Signed-off-by: Dominik Brodowski Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 198e26a0efefb21c9854adc630011837bca45a72 Author: Anders Roxell Date: Tue Feb 6 16:23:39 2018 -0600 selftests: sync: missing CFLAGS while compiling [ Upstream commit b2c93e300a11b419b4c67ce08e16fa1436d8118c ] Based on patch: https://patchwork.kernel.org/patch/10042045/ arch64-linux-gnu-gcc -c sync.c -o sync/sync.o sync.c:42:29: fatal error: linux/sync_file.h: No such file or directory #include ^ CFLAGS is not used during the compile step, so the system instead of kernel headers are used. Fix this by adding CFLAGS to the OBJS compile rule. Reported-by: Lei Yang Signed-off-by: Anders Roxell Signed-off-by: Daniel Díaz Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4adc95c5a020996a2088b44f9e3bbf2e0b518efb Author: Dong Bo Date: Fri Jan 26 11:21:49 2018 +0800 libata: Fix compile warning with ATA_DEBUG enabled [ Upstream commit 0d3e45bc6507bd1f8728bf586ebd16c2d9e40613 ] This fixs the following comile warnings with ATA_DEBUG enabled, which detected by Linaro GCC 5.2-2015.11: drivers/ata/libata-scsi.c: In function 'ata_scsi_dump_cdb': ./include/linux/kern_levels.h:5:18: warning: format '%d' expects argument of type 'int', but argument 6 has type 'u64 {aka long long unsigned int}' [-Wformat=] tj: Patch hand-applied and description trimmed. Signed-off-by: Dong Bo Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit afe088b034b4dde7abebe6cd104d7129d0a58ef8 Author: Shawn Lin Date: Fri Feb 9 16:51:48 2018 +0800 arm64: dts: rockchip: correct ep-gpios for rk3399-sapphire [ Upstream commit 2b7d2ed1af2e2c0c90a1a8b97926b7b6c6cb03ed ] The endpoint control gpio for rk3399-sapphire boards is gpio2_a4, so correct it now. Signed-off-by: Shawn Lin Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fa4cf9010ed60b11b8693d67b7f1dc117e0000b5 Author: Kamil Trzciński Date: Mon Jan 22 18:46:22 2018 +0100 arm64: dts: rockchip: fix rock64 gmac2io stability issues [ Upstream commit 73e42e18669934fa96cf2bb54291da54177076d7 ] This commit enables thresh dma mode as this forces to disable checksuming, and chooses delay values which make the interface stable. These changes are needed, because ROCK64 is faced with two problems: 1. tx checksuming does not work with packets larger than 1498, 2. the default delays for tx/rx are not stable when using 1Gbps connection. Delays were found out with: https://github.com/ayufan-rock64/linux-build/tree/master/recipes/gmac-delays-test Signed-off-by: Kamil Trzciński Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6fc72fd1565bcd7f872ad89cd0c7a60a7cf68c96 Author: Jason Wang Date: Sun Feb 11 11:28:12 2018 +0800 ptr_ring: prevent integer overflow when calculating size [ Upstream commit 54e02162d4454a99227f520948bf4494c3d972d0 ] Switch to use dividing to prevent integer overflow when size is too big to calculate allocation size properly. Reported-by: Eric Biggers Fixes: 6e6e41c31122 ("ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE") Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 052eb2d6dc619700281b1f70bb0eb9304ec04b07 Author: Ulf Magnusson Date: Mon Feb 5 02:21:31 2018 +0100 ARC: Fix malformed ARC_EMUL_UNALIGNED default [ Upstream commit 827cc2fa024dd6517d62de7a44c7b42f32af371b ] 'default N' should be 'default n', though they happen to have the same effect here, due to undefined symbols (N in this case) evaluating to n in a tristate sense. Remove the default from ARC_EMUL_UNALIGNED instead of changing it. bool and tristate symbols implicitly default to n. Discovered with the https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ulfalizer_Kconfiglib_blob_master_examples_list-5Fundefined.py&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=c14YS-cH-kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=WxxD8ozR7QQUVzNCBksiznaisBGO_crN7PBOvAoju8s&s=1LmxsNqxwT-7wcInVpZ6Z1J27duZKSoyKxHIJclXU_M&e= script. Signed-off-by: Ulf Magnusson Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0f097096b77abc51ea9b17643b6113f1d53205e9 Author: Peter Oh Date: Fri Jan 26 14:02:37 2018 -0800 mac80211: mesh: fix wrong mesh TTL offset calculation [ Upstream commit c4de37ee2b55deac7d6aeac33e02e3d6be243898 ] mesh TTL offset in Mesh Channel Switch Parameters element depends on not only Secondary Channel Offset element, but also affected by HT Control field and Wide Bandwidth Channel Switch element. So use element structure to manipulate mesh channel swich param IE after removing its constant attribution to correct the miscalculation. Signed-off-by: Peter Oh Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 49e30752177f405a1acf0c42253d4bf7fdef64f9 Author: James Hogan Date: Fri Feb 2 22:14:09 2018 +0000 MIPS: generic: Fix machine compatible matching [ Upstream commit 9a9ab3078e2744a1a55163cfaec73a5798aae33e ] We now have a platform (Ranchu) in the "generic" platform which matches based on the FDT compatible string using mips_machine_is_compatible(), however that function doesn't stop at a blank struct of_device_id::compatible as that is an array in the struct, not a pointer to a string. Fix the loop completion to check the first byte of the compatible array rather than the address of the compatible array in the struct. Fixes: eed0eabd12ef ("MIPS: generic: Introduce generic DT-based board support") Signed-off-by: James Hogan Reviewed-by: Paul Burton Reviewed-by: Matt Redfearn Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18580/ Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3084902aa9fd314cca547ae9a4ba2c73845e1202 Author: Nicholas Piggin Date: Sat May 26 14:27:49 2018 +1000 powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit commit a048a07d7f4535baa4cbad6bc024f175317ab938 upstream. On some CPUs we can prevent a vulnerability related to store-to-load forwarding by preventing store forwarding between privilege domains, by inserting a barrier in kernel entry and exit paths. This is known to be the case on at least Power7, Power8 and Power9 powerpc CPUs. Barriers must be inserted generally before the first load after moving to a higher privilege, and after the last store before moving to a lower privilege, HV and PR privilege transitions must be protected. Barriers are added as patch sections, with all kernel/hypervisor entry points patched, and the exit points to lower privilge levels patched similarly to the RFI flush patching. Firmware advertisement is not implemented yet, so CPU flush types are hard coded. Thanks to Michal Suchánek for bug fixes and review. Signed-off-by: Nicholas Piggin Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Neuling Signed-off-by: Michal Suchánek Signed-off-by: Michael Ellerman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b90a6bddc8af8bf82ae4a7251a464c3b45bcd168 Author: Michael Ellerman Date: Sat May 26 14:27:48 2018 +1000 powerpc/64s: Fix section mismatch warnings from setup_rfi_flush() commit 501a78cbc17c329fabf8e9750a1e9ab810c88a0e upstream. The recent LPM changes to setup_rfi_flush() are causing some section mismatch warnings because we removed the __init annotation on setup_rfi_flush(): The function setup_rfi_flush() references the function __init ppc64_bolted_size(). the function __init memblock_alloc_base(). The references are actually in init_fallback_flush(), but that is inlined into setup_rfi_flush(). These references are safe because: - only pseries calls setup_rfi_flush() at runtime - pseries always passes L1D_FLUSH_FALLBACK at boot - so the fallback flush area will always be allocated - so the check in init_fallback_flush() will always return early: /* Only allocate the fallback flush area once (at boot time). */ if (l1d_flush_fallback_area) return; - and therefore we won't actually call the freed init routines. We should rework the code to make it safer by default rather than relying on the above, but for now as a quick-fix just add a __ref annotation to squash the warning. Fixes: abf110f3e1ce ("powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 1618f211f96e3725615074a92f05dfe19be53b44 Author: Mauricio Faria de Oliveira Date: Sat May 26 14:27:47 2018 +1000 powerpc/pseries: Restore default security feature flags on setup commit 6232774f1599028a15418179d17f7df47ede770a upstream. After migration the security feature flags might have changed (e.g., destination system with unpatched firmware), but some flags are not set/clear again in init_cpu_char_feature_flags() because it assumes the security flags to be the defaults. Additionally, if the H_GET_CPU_CHARACTERISTICS hypercall fails then init_cpu_char_feature_flags() does not run again, which potentially might leave the system in an insecure or sub-optimal configuration. So, just restore the security feature flags to the defaults assumed by init_cpu_char_feature_flags() so it can set/clear them correctly, and to ensure safe settings are in place in case the hypercall fail. Fixes: f636c14790ea ("powerpc/pseries: Set or clear security feature flags") Depends-on: 19887d6a28e2 ("powerpc: Move default security feature flags") Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f092a180128e00e520ba721b111b184c09fc3536 Author: Mauricio Faria de Oliveira Date: Sat May 26 14:27:46 2018 +1000 powerpc: Move default security feature flags commit e7347a86830f38dc3e40c8f7e28c04412b12a2e7 upstream. This moves the definition of the default security feature flags (i.e., enabled by default) closer to the security feature flags. This can be used to restore current flags to the default flags. Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit a28ff26d5e4426c9d5587e981e020818adde93fb Author: Mauricio Faria de Oliveira Date: Sat May 26 14:27:45 2018 +1000 powerpc/pseries: Fix clearing of security feature flags commit 0f9bdfe3c77091e8704d2e510eb7c2c2c6cde524 upstream. The H_CPU_BEHAV_* flags should be checked for in the 'behaviour' field of 'struct h_cpu_char_result' -- 'character' is for H_CPU_CHAR_* flags. Found by playing around with QEMU's implementation of the hypercall: H_CPU_CHAR=0xf000000000000000 H_CPU_BEHAV=0x0000000000000000 This clears H_CPU_BEHAV_FAVOUR_SECURITY and H_CPU_BEHAV_L1D_FLUSH_PR so pseries_setup_rfi_flush() disables 'rfi_flush'; and it also clears H_CPU_CHAR_L1D_THREAD_PRIV flag. So there is no RFI flush mitigation at all for cpu_show_meltdown() to report; but currently it does: Original kernel: # cat /sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: RFI Flush Patched kernel: # cat /sys/devices/system/cpu/vulnerabilities/meltdown Not affected H_CPU_CHAR=0x0000000000000000 H_CPU_BEHAV=0xf000000000000000 This sets H_CPU_BEHAV_BNDS_CHK_SPEC_BAR so cpu_show_spectre_v1() should report vulnerable; but currently it doesn't: Original kernel: # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Not affected Patched kernel: # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Vulnerable Brown-paper-bag-by: Michael Ellerman Fixes: f636c14790ea ("powerpc/pseries: Set or clear security feature flags") Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 046e9adae42afa8d7c12c05fdad8aefa99ca90c2 Author: Michael Ellerman Date: Sat May 26 14:27:44 2018 +1000 powerpc/64s: Wire up cpu_show_spectre_v2() commit d6fbe1c55c55c6937cbea3531af7da84ab7473c3 upstream. Add a definition for cpu_show_spectre_v2() to override the generic version. This has several permuations, though in practice some may not occur we cater for any combination. The most verbose is: Mitigation: Indirect branch serialisation (kernel only), Indirect branch cache disabled, ori31 speculation barrier enabled We don't treat the ori31 speculation barrier as a mitigation on its own, because it has to be *used* by code in order to be a mitigation and we don't know if userspace is doing that. So if that's all we see we say: Vulnerable, ori31 speculation barrier enabled Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 6e77feadbfbc9fa5ca760c1df88492cadbf1fb5c Author: Michael Ellerman Date: Sat May 26 14:27:43 2018 +1000 powerpc/64s: Wire up cpu_show_spectre_v1() commit 56986016cb8cd9050e601831fe89f332b4e3c46e upstream. Add a definition for cpu_show_spectre_v1() to override the generic version. Currently this just prints "Not affected" or "Vulnerable" based on the firmware flag. Although the kernel does have array_index_nospec() in a few places, we haven't yet audited all the powerpc code to see where it's necessary, so for now we don't list that as a mitigation. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 7a62b0f64804b1987225377c2944a86f9db63f37 Author: Michael Ellerman Date: Sat May 26 14:27:42 2018 +1000 powerpc/pseries: Use the security flags in pseries_setup_rfi_flush() commit 2e4a16161fcd324b1f9bf6cb6856529f7eaf0689 upstream. Now that we have the security flags we can simplify the code in pseries_setup_rfi_flush() because the security flags have pessimistic defaults. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 3bf1695bbb24a848f7b6258fb5e9725833d6ddc4 Author: Michael Ellerman Date: Sat May 26 14:27:41 2018 +1000 powerpc/powernv: Use the security flags in pnv_setup_rfi_flush() commit 37c0bdd00d3ae83369ab60a6712c28e11e6458d5 upstream. Now that we have the security flags we can significantly simplify the code in pnv_setup_rfi_flush(), because we can use the flags instead of checking device tree properties and because the security flags have pessimistic defaults. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit d71a3e0a2d0a9be5174fac1be0d97f67a16d8c8f Author: Michael Ellerman Date: Sat May 26 14:27:40 2018 +1000 powerpc/64s: Enhance the information in cpu_show_meltdown() commit ff348355e9c72493947be337bb4fae4fc1a41eba upstream. Now that we have the security feature flags we can make the information displayed in the "meltdown" file more informative. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ae8afdf604d3393141b5b6e5f52af247caedf87f Author: Michael Ellerman Date: Sat May 26 14:27:39 2018 +1000 powerpc/64s: Move cpu_show_meltdown() commit 8ad33041563a10b34988800c682ada14b2612533 upstream. This landed in setup_64.c for no good reason other than we had nowhere else to put it. Now that we have a security-related file, that is a better place for it so move it. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f2fdeebd8537b946363384e37447bd5862b39df3 Author: Michael Ellerman Date: Sat May 26 14:27:38 2018 +1000 powerpc/powernv: Set or clear security feature flags commit 77addf6e95c8689e478d607176b399a6242a777e upstream. Now that we have feature flags for security related things, set or clear them based on what we see in the device tree provided by firmware. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 9ba774cc0f752380e5a788258249f2062d042cdc Author: Michael Ellerman Date: Sat May 26 14:27:37 2018 +1000 powerpc/pseries: Set or clear security feature flags commit f636c14790ead6cc22cf62279b1f8d7e11a67116 upstream. Now that we have feature flags for security related things, set or clear them based on what we receive from the hypercall. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit e2ba26dba5307d01fb9dd2ab813ee3b10f424cb0 Author: Michael Ellerman Date: Sat May 26 14:27:36 2018 +1000 powerpc: Add security feature flags for Spectre/Meltdown commit 9a868f634349e62922c226834aa23e3d1329ae7f upstream. This commit adds security feature flags to reflect the settings we receive from firmware regarding Spectre/Meltdown mitigations. The feature names reflect the names we are given by firmware on bare metal machines. See the hostboot source for details. Arguably these could be firmware features, but that then requires them to be read early in boot so they're available prior to asm feature patching, but we don't actually want to use them for patching. We may also want to dynamically update them in future, which would be incompatible with the way firmware features work (at the moment at least). So for now just make them separate flags. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4c5463a5a374c119a17a62f39ac3d1e2f8b7ea8d Author: Michael Ellerman Date: Sat May 26 14:27:35 2018 +1000 powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags commit c4bc36628d7f8b664657d8bd6ad1c44c177880b7 upstream. Add some additional values which have been defined for the H_GET_CPU_CHARACTERISTICS hypercall. Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit d1cb5ff450d3ae87f57f680d9dcb707460302f8c Author: Michael Ellerman Date: Sat May 26 14:27:34 2018 +1000 powerpc/rfi-flush: Call setup_rfi_flush() after LPM migration commit 921bc6cf807ceb2ab8005319cf39f33494d6b100 upstream. We might have migrated to a machine that uses a different flush type, or doesn't need flushing at all. Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 123f6d5ccaa2c3614b12bd12da14cab2b79f637f Author: Mauricio Faria de Oliveira Date: Sat May 26 14:27:33 2018 +1000 powerpc/rfi-flush: Differentiate enabled and patched flush types commit 0063d61ccfc011f379a31acaeba6de7c926fed2c upstream. Currently the rfi-flush messages print 'Using flush' for all enabled_flush_types, but that is not necessarily true -- as now the fallback flush is always enabled on pseries, but the fixup function overwrites its nop/branch slot with other flush types, if available. So, replace the 'Using flush' messages with ' flush is available'. Also, print the patched flush types in the fixup function, so users can know what is (not) being used (e.g., the slower, fallback flush, or no flush type at all if flush is disabled via the debugfs switch). Suggested-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 6af06dcdea08b1eace8088f6b39852d80a66312f Author: Michael Ellerman Date: Sat May 26 14:27:32 2018 +1000 powerpc/rfi-flush: Always enable fallback flush on pseries commit 84749a58b6e382f109abf1e734bc4dd43c2c25bb upstream. This ensures the fallback flush area is always allocated on pseries, so in case a LPAR is migrated from a patched to an unpatched system, it is possible to enable the fallback flush in the target system. Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit d744f8457f2f0cc8c019ccbcf1432ea96896cb8b Author: Michael Ellerman Date: Sat May 26 14:27:31 2018 +1000 powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again commit abf110f3e1cea40f5ea15e85f5d67c39c14568a7 upstream. For PowerVM migration we want to be able to call setup_rfi_flush() again after we've migrated the partition. To support that we need to check that we're not trying to allocate the fallback flush area after memblock has gone away (i.e., boot-time only). Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 5412a9d91d650ffbe8af17ffbf2f65f84fbd58e3 Author: Michael Ellerman Date: Sat May 26 14:27:30 2018 +1000 powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code commit 1e2a9fc7496955faacbbed49461d611b704a7505 upstream. rfi_flush_enable() includes a check to see if we're already enabled (or disabled), and in that case does nothing. But that means calling setup_rfi_flush() a 2nd time doesn't actually work, which is a bit confusing. Move that check into the debugfs code, where it really belongs. Signed-off-by: Michael Ellerman Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit bf434b31bad640ef4ec34e5f92c5dc95b9e4ed44 Author: Michael Ellerman Date: Sat May 26 14:27:29 2018 +1000 powerpc/powernv: Support firmware disable of RFI flush commit eb0a2d2620ae431c543963c8c7f08f597366fc60 upstream. Some versions of firmware will have a setting that can be configured to disable the RFI flush, add support for it. Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush settings") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit dff1a7e6c3ae2b79cdc23503d732a2b8c19a0296 Author: Michael Ellerman Date: Sat May 26 14:27:28 2018 +1000 powerpc/pseries: Support firmware disable of RFI flush commit 582605a429e20ae68fd0b041b2e840af296edd08 upstream. Some versions of firmware will have a setting that can be configured to disable the RFI flush, add support for it. Fixes: 8989d56878a7 ("powerpc/pseries: Query hypervisor for RFI flush settings") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 2245d95d9f7a2746af23962e212ea556dc4ea653 Author: Nicholas Piggin Date: Sat May 26 14:27:27 2018 +1000 powerpc/64s: Improve RFI L1-D cache flush fallback commit bdcb1aefc5b3f7d0f1dc8b02673602bca2ff7a4b upstream. The fallback RFI flush is used when firmware does not provide a way to flush the cache. It's a "displacement flush" that evicts useful data by displacing it with an uninteresting buffer. The flush has to take care to work with implementation specific cache replacment policies, so the recipe has been in flux. The initial slow but conservative approach is to touch all lines of a congruence class, with dependencies between each load. It has since been determined that a linear pattern of loads without dependencies is sufficient, and is significantly faster. Measuring the speed of a null syscall with RFI fallback flush enabled gives the relative improvement: P8 - 1.83x P9 - 1.75x The flush also becomes simpler and more adaptable to different cache geometries. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 421e1fadb0b0a648cc75afd5b3c826fa7daeaffc Author: David Vrabel Date: Fri May 18 16:55:46 2018 +0100 x86/kvm: fix LAPIC timer drift when guest uses periodic mode commit d8f2f498d9ed0c5010bc1bbc1146f94c8bf9f8cc upstream. Since 4.10, commit 8003c9ae204e (KVM: LAPIC: add APIC Timer periodic/oneshot mode VMX preemption timer support), guests using periodic LAPIC timers (such as FreeBSD 8.4) would see their timers drift significantly over time. Differences in the underlying clocks and numerical errors means the periods of the two timers (hv and sw) are not the same. This difference will accumulate with every expiry resulting in a large error between the hv and sw timer. This means the sw timer may be running slow when compared to the hv timer. When the timer is switched from hv to sw, the now active sw timer will expire late. The guest VCPU is reentered and it switches to using the hv timer. This timer catches up, injecting multiple IRQs into the guest (of which the guest only sees one as it does not get to run until the hv timer has caught up) and thus the guest's timer rate is low (and becomes increasing slower over time as the sw timer lags further and further behind). I believe a similar problem would occur if the hv timer is the slower one, but I have not observed this. Fix this by synchronizing the deadlines for both timers to the same time source on every tick. This prevents the errors from accumulating. Fixes: 8003c9ae204e21204e49816c5ea629357e283b06 Cc: Wanpeng Li Signed-off-by: David Vrabel Cc: stable@vger.kernel.org Reviewed-by: Paolo Bonzini Reviewed-by: Wanpeng Li Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit b3ce16455c4b4de25e1c0dc23d0d4c03d5324e86 Author: Jim Mattson Date: Wed May 9 14:29:35 2018 -0700 kvm: x86: IA32_ARCH_CAPABILITIES is always supported commit 1eaafe91a0df4157521b6417b3dd8430bf5f52f0 upstream. If there is a possibility that a VM may migrate to a Skylake host, then the hypervisor should report IA32_ARCH_CAPABILITIES.RSBA[bit 2] as being set (future work, of course). This implies that CPUID.(EAX=7,ECX=0):EDX.ARCH_CAPABILITIES[bit 29] should be set. Therefore, kvm should report this CPUID bit as being supported whether or not the host supports it. Userspace is still free to clear the bit if it chooses. For more information on RSBA, see Intel's white paper, "Retpoline: A Branch Target Injection Mitigation" (Document Number 337131-001), currently available at https://bugzilla.kernel.org/show_bug.cgi?id=199511. Since the IA32_ARCH_CAPABILITIES MSR is emulated in kvm, there is no dependency on hardware support for this feature. Signed-off-by: Jim Mattson Reviewed-by: Konrad Rzeszutek Wilk Fixes: 28c1c9fabf48 ("KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES") Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit e765fd97e0c208623b810687a1f8d0a9b280dbbb Author: Wei Huang Date: Tue May 1 09:49:54 2018 -0500 KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changed commit c4d2188206bafa177ea58e9a25b952baa0bf7712 upstream. The CPUID bits of OSXSAVE (function=0x1) and OSPKE (func=0x7, leaf=0x0) allows user apps to detect if OS has set CR4.OSXSAVE or CR4.PKE. KVM is supposed to update these CPUID bits when CR4 is updated. Current KVM code doesn't handle some special cases when updates come from emulator. Here is one example: Step 1: guest boots Step 2: guest OS enables XSAVE ==> CR4.OSXSAVE=1 and CPUID.OSXSAVE=1 Step 3: guest hot reboot ==> QEMU reset CR4 to 0, but CPUID.OSXAVE==1 Step 4: guest os checks CPUID.OSXAVE, detects 1, then executes xgetbv Step 4 above will cause an #UD and guest crash because guest OS hasn't turned on OSXAVE yet. This patch solves the problem by comparing the the old_cr4 with cr4. If the related bits have been changed, kvm_update_cpuid() needs to be called. Signed-off-by: Wei Huang Reviewed-by: Bandan Das Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit 16c463a4ecfa9f6720a79df3dcb49cbf89905051 Author: David Hildenbrand Date: Wed May 9 16:12:17 2018 +0200 KVM: s390: vsie: fix < 8k check for the itdba commit f4a551b72358facbbe5714248dff78404272feee upstream. By missing an "L", we might detect some addresses to be <8k, although they are not. e.g. for itdba = 100001fff !(gpa & ~0x1fffU) -> 1 !(gpa & ~0x1fffUL) -> 0 So we would report a SIE validity intercept although everything is fine. Fixes: 166ecb3 ("KVM: s390: vsie: support transactional execution") Reported-by: Dan Carpenter Reviewed-by: Christian Borntraeger Reviewed-by: Janosch Frank Reviewed-by: Cornelia Huck Signed-off-by: David Hildenbrand Signed-off-by: Janosch Frank Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 9c5eee605677b460e6f759e6875769cc104d5ee0 Author: Konrad Rzeszutek Wilk Date: Mon May 21 17:54:49 2018 -0400 KVM/VMX: Expose SSBD properly to guests commit 0aa48468d00959c8a37cd3ac727284f4f7359151 upstream. The X86_FEATURE_SSBD is an synthetic CPU feature - that is it bit location has no relevance to the real CPUID 0x7.EBX[31] bit position. For that we need the new CPU feature name. Fixes: 52817587e706 ("x86/cpufeatures: Disentangle SSBD enumeration") Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Cc: kvm@vger.kernel.org Cc: "Radim Krčmář" Cc: stable@vger.kernel.org Cc: "H. Peter Anvin" Cc: Paolo Bonzini Link: https://lkml.kernel.org/r/20180521215449.26423-2-konrad.wilk@oracle.com Signed-off-by: Greg Kroah-Hartman commit 058dfcf9c24f74f30a78f7c837b784054736cdf1 Author: Gustavo A. R. Silva Date: Fri May 25 14:47:57 2018 -0700 kernel/sys.c: fix potential Spectre v1 issue commit 23d6aef74da86a33fa6bb75f79565e0a16ee97c2 upstream. `resource' can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap) kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap) Fix this by sanitizing *resource* before using it to index current->signal->rlim Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Link: http://lkml.kernel.org/r/20180515030038.GA11822@embeddedor.com Signed-off-by: Gustavo A. R. Silva Reviewed-by: Andrew Morton Cc: Alexei Starovoitov Cc: Dan Williams Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1da530fe155d8c0d93d532ebd0df03955ebf931d Author: David Hildenbrand Date: Fri May 25 14:48:11 2018 -0700 kasan: fix memory hotplug during boot commit 3f1959721558a976aaf9c2024d5bc884e6411bf7 upstream. Using module_init() is wrong. E.g. ACPI adds and onlines memory before our memory notifier gets registered. This makes sure that ACPI memory detected during boot up will not result in a kernel crash. Easily reproducible with QEMU, just specify a DIMM when starting up. Link: http://lkml.kernel.org/r/20180522100756.18478-3-david@redhat.com Fixes: 786a8959912e ("kasan: disable memory hotplug") Signed-off-by: David Hildenbrand Acked-by: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b052960484fd40d6144a78773313c17154443177 Author: David Hildenbrand Date: Fri May 25 14:48:08 2018 -0700 kasan: free allocated shadow memory on MEM_CANCEL_ONLINE commit ed1596f9ab958dd156a66c9ff1029d3761c1786a upstream. We have to free memory again when we cancel onlining, otherwise a later onlining attempt will fail. Link: http://lkml.kernel.org/r/20180522100756.18478-2-david@redhat.com Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug") Signed-off-by: David Hildenbrand Acked-by: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9c7821c67a71884d338639ec00dc8f8519705214 Author: Andrey Ryabinin Date: Fri May 25 14:47:38 2018 -0700 mm/kasan: don't vfree() nonexistent vm_area commit 0f901dcbc31f88ae41a2aaa365f7802b5d520a28 upstream. KASAN uses different routines to map shadow for hot added memory and memory obtained in boot process. Attempt to offline memory onlined by normal boot process leads to this: Trying to vfree() nonexistent vm area (000000005d3b34b9) WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190 Call Trace: kasan_mem_notifier+0xad/0xb9 notifier_call_chain+0x166/0x260 __blocking_notifier_call_chain+0xdb/0x140 __offline_pages+0x96a/0xb10 memory_subsys_offline+0x76/0xc0 device_offline+0xb8/0x120 store_mem_state+0xfa/0x120 kernfs_fop_write+0x1d5/0x320 __vfs_write+0xd4/0x530 vfs_write+0x105/0x340 SyS_write+0xb0/0x140 Obviously we can't call vfree() to free memory that wasn't allocated via vmalloc(). Use find_vm_area() to see if we can call vfree(). Unfortunately it's a bit tricky to properly unmap and free shadow allocated during boot, so we'll have to keep it. If memory will come online again that shadow will be reused. Matthew asked: how can you call vfree() on something that isn't a vmalloc address? vfree() is able to free any address returned by __vmalloc_node_range(). And __vmalloc_node_range() gives you any address you ask. It doesn't have to be an address in [VMALLOC_START, VMALLOC_END] range. That's also how the module_alloc()/module_memfree() works on architectures that have designated area for modules. [aryabinin@virtuozzo.com: improve comments] Link: http://lkml.kernel.org/r/dabee6ab-3a7a-51cd-3b86-5468718e0390@virtuozzo.com [akpm@linux-foundation.org: fix typos, reflow comment] Link: http://lkml.kernel.org/r/20180201163349.8700-1-aryabinin@virtuozzo.com Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug") Signed-off-by: Andrey Ryabinin Reported-by: Paul Menzel Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Matthew Wilcox Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit afdc490b36b02426f54c166eb794fc009c48a6de Author: Davidlohr Bueso Date: Fri May 25 14:47:30 2018 -0700 ipc/shm: fix shmat() nil address after round-down when remapping commit 8f89c007b6dec16a1793cb88de88fcc02117bbbc upstream. shmat()'s SHM_REMAP option forbids passing a nil address for; this is in fact the very first thing we check for. Andrea reported that for SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check, but we need to check again if the address was rounded down to nil. As of this patch, such cases will return -EINVAL. Link: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805 Signed-off-by: Davidlohr Bueso Reported-by: Andrea Arcangeli Cc: Joe Lawrence Cc: Manfred Spraul Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 67dd0bad818914614e77c00ca2f259d2ad69f5a3 Author: Davidlohr Bueso Date: Fri May 25 14:47:27 2018 -0700 Revert "ipc/shm: Fix shmat mmap nil-page protection" commit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream. Patch series "ipc/shm: shmat() fixes around nil-page". These patches fix two issues reported[1] a while back by Joe and Andrea around how shmat(2) behaves with nil-page. The first reverts a commit that it was incorrectly thought that mapping nil-page (address=0) was a no no with MAP_FIXED. This is not the case, with the exception of SHM_REMAP; which is address in the second patch. I chose two patches because it is easier to backport and it explicitly reverts bogus behaviour. Both patches ought to be in -stable and ltp testcases need updated (the added testcase around the cve can be modified to just test for SHM_RND|SHM_REMAP). [1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805 This patch (of 2): Commit 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection") worked on the idea that we should not be mapping as root addr=0 and MAP_FIXED. However, it was reported that this scenario is in fact valid, thus making the patch both bogus and breaks userspace as well. For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem initialization[1]. [1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347 Link: http://lkml.kernel.org/r/20180503203243.15045-2-dave@stgolabs.net Fixes: 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection") Signed-off-by: Davidlohr Bueso Reported-by: Joe Lawrence Reported-by: Andrea Arcangeli Cc: Manfred Spraul Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0472f94cef2e2ba43c809875c13d7221d7f264c3 Author: Matthew Wilcox Date: Fri May 25 14:47:24 2018 -0700 idr: fix invalid ptr dereference on item delete commit 7a4deea1aa8bddfed4ef1b35fc2b6732563d8ad5 upstream. If the radix tree underlying the IDR happens to be full and we attempt to remove an id which is larger than any id in the IDR, we will call __radix_tree_delete() with an uninitialised 'slot' pointer, at which point anything could happen. This was easiest to hit with a single entry at id 0 and attempting to remove a non-0 id, but it could have happened with 64 entries and attempting to remove an id >= 64. Roman said: The syzcaller test boils down to opening /dev/kvm, creating an eventfd, and calling a couple of KVM ioctls. None of this requires superuser. And the result is dereferencing an uninitialized pointer which is likely a crash. The specific path caught by syzbot is via KVM_HYPERV_EVENTD ioctl which is new in 4.17. But I guess there are other user-triggerable paths, so cc:stable is probably justified. Matthew added: We have around 250 calls to idr_remove() in the kernel today. Many of them pass an ID which is embedded in the object they're removing, so they're safe. Picking a few likely candidates: drivers/firewire/core-cdev.c looks unsafe; the ID comes from an ioctl. drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c is similar drivers/atm/nicstar.c could be taken down by a handcrafted packet Link: http://lkml.kernel.org/r/20180518175025.GD6361@bombadil.infradead.org Fixes: 0a835c4f090a ("Reimplement IDR and IDA using the radix tree") Reported-by: Debugged-by: Roman Kagan Signed-off-by: Matthew Wilcox Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2a039b93679fb2e974bedf5b0d76da81731474ba Author: Jens Axboe Date: Mon May 21 12:21:14 2018 -0600 sr: pass down correctly sized SCSI sense buffer commit f7068114d45ec55996b9040e98111afa56e010fe upstream. We're casting the CDROM layer request_sense to the SCSI sense buffer, but the former is 64 bytes and the latter is 96 bytes. As we generally allocate these on the stack, we end up blowing up the stack. Fix this by wrapping the scsi_execute() call with a properly sized sense buffer, and copying back the bits for the CDROM layer. Cc: stable@vger.kernel.org Reported-by: Piotr Gabriel Kosinski Reported-by: Daniel Shapira Tested-by: Kees Cook Fixes: 82ed4db499b8 ("block: split scsi_request out of struct request") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a59bd819576d9dc0ca279f2c1a4b3903ca786d12 Author: Lidong Chen Date: Tue May 8 16:50:16 2018 +0800 IB/umem: Use the correct mm during ib_umem_release commit 8e907ed4882714fd13cfe670681fc6cb5284c780 upstream. User-space may invoke ibv_reg_mr and ibv_dereg_mr in different threads. If ibv_dereg_mr is called after the thread which invoked ibv_reg_mr has exited, get_pid_task will return NULL and ib_umem_release will not decrease mm->pinned_vm. Instead of using threads to locate the mm, use the overall tgid from the ib_ucontext struct instead. This matches the behavior of ODP and disassociate in handling the mm of the process that called ibv_reg_mr. Cc: Fixes: 87773dd56d54 ("IB: ib_umem_release() should decrement mm->pinned_vm from ib_umem_get") Signed-off-by: Lidong Chen Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 7a5b3b91f858b8b63131fedd0d51c17c4e7b498f Author: Michael J. Ruhl Date: Wed May 2 06:42:51 2018 -0700 IB/hfi1: Use after free race condition in send context error path commit f9e76ca3771bf23d2142a81a88ddd8f31f5c4c03 upstream. A pio send egress error can occur when the PSM library attempts to to send a bad packet. That issue is still being investigated. The pio error interrupt handler then attempts to progress the recovery of the errored pio send context. Code inspection reveals that the handling lacks the necessary locking if that recovery interleaves with a PSM close of the "context" object contains the pio send context. The lack of the locking can cause the recovery to access the already freed pio send context object and incorrectly deduce that the pio send context is actually a kernel pio send context as shown by the NULL deref stack below: [] _dev_info+0x6c/0x90 [] sc_restart+0x70/0x1f0 [hfi1] [] ? __schedule+0x424/0x9b0 [] sc_halted+0x15/0x20 [hfi1] [] process_one_work+0x17a/0x440 [] worker_thread+0x126/0x3c0 [] ? manage_workers.isra.24+0x2a0/0x2a0 [] kthread+0xcf/0xe0 [] ? insert_kthread_work+0x40/0x40 [] ret_from_fork+0x58/0x90 [] ? insert_kthread_work+0x40/0x40 This is the best case scenario and other scenarios can corrupt the already freed memory. Fix by adding the necessary locking in the pio send context error handler. Cc: # 4.9.x Reviewed-by: Mike Marciniszyn Reviewed-by: Dennis Dalessandro Signed-off-by: Michael J. Ruhl Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit df07f27184409a3d1ff4abc553a6f4a0366841ef Author: Michael Neuling Date: Fri May 18 11:37:42 2018 +1000 powerpc/64s: Clear PCR on boot commit faf37c44a105f3608115785f17cbbf3500f8bc71 upstream. Clear the PCR (Processor Compatibility Register) on boot to ensure we are not running in a compatibility mode. We've seen this cause problems when a crash (and kdump) occurs while running compat mode guests. The kdump kernel then runs with the PCR set and causes problems. The symptom in the kdump kernel (also seen in petitboot after fast-reboot) is early userspace programs taking sigills on newer instructions (seen in libc). Signed-off-by: Michael Neuling Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 92169a015bdd69ca7cb31cc517d009256148a970 Author: Will Deacon Date: Mon May 21 17:44:57 2018 +0100 arm64: lse: Add early clobbers to some input/output asm operands commit 32c3fa7cdf0c4a3eb8405fc3e13398de019e828b upstream. For LSE atomics that read and write a register operand, we need to ensure that these operands are annotated as "early clobber" if the register is written before all of the input operands have been consumed. Failure to do so can result in the compiler allocating the same register to both operands, leading to splats such as: Unable to handle kernel paging request at virtual address 11111122222221 [...] x1 : 1111111122222222 x0 : 1111111122222221 Process swapper/0 (pid: 1, stack limit = 0x000000008209f908) Call trace: test_atomic64+0x1360/0x155c where x0 has been allocated as both the value to be stored and also the atomic_t pointer. This patch adds the missing clobbers. Cc: Cc: Dave Martin Cc: Robin Murphy Reported-by: Mark Salter Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 760e4d7e89a53599a628cf7f176a4145b0e9dd29 Author: Thomas Hellstrom Date: Wed May 23 16:11:24 2018 +0200 drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros commit 938ae7259c908ad031da35d551da297640bb640c upstream. Depending on whether the kernel is compiled with frame-pointer or not, the temporary memory location used for the bp parameter in these macros is referenced relative to the stack pointer or the frame pointer. Hence we can never reference that parameter when we've modified either the stack pointer or the frame pointer, because then the compiler would generate an incorrect stack reference. Fix this by pushing the temporary memory parameter on a known location on the stack before modifying the stack- and frame pointers. Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul Reviewed-by: Sinclair Yeh Signed-off-by: Greg Kroah-Hartman commit a0f8cbce7b573a2d646e9fbbc33d59007d99c8e6 Author: Joe Jin Date: Thu May 17 12:33:28 2018 -0700 xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream. When run raidconfig from Dom0 we found that the Xen DMA heap is reduced, but Dom Heap is increased by the same size. Tracing raidconfig we found that the related ioctl() in megaraid_sas will call dma_alloc_coherent() to apply memory. If the memory allocated by Dom0 is not in the DMA area, it will exchange memory with Xen to meet the requiment. Later drivers call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent() the check condition (dev_addr + size - 1 <= dma_mask) is always false, it prevents calling xen_destroy_contiguous_region() to return the memory to the Xen DMA heap. This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing coherent alloc/dealloc check before swizzling the MFNs.". Signed-off-by: Joe Jin Tested-by: John Sobecki Reviewed-by: Rzeszutek Wilk Cc: stable@vger.kernel.org Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 4182f5a075f134b93ed4ba79bfd3ed8f9fd1e8da Author: Sudip Mukherjee Date: Sat May 19 22:29:36 2018 +0100 libata: blacklist Micron 500IT SSD with MU01 firmware commit 136d769e0b3475d71350aa3648a116a6ee7a8f6c upstream. While whitelisting Micron M500DC drives, the tweaked blacklist entry enabled queued TRIM from M500IT variants also. But these do not support queued TRIM. And while using those SSDs with the latest kernel we have seen errors and even the partition table getting corrupted. Some part from the dmesg: [ 6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133 [ 6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 6.741026] ata1.00: supports DRM functions and may not be fully accessible [ 6.759887] ata1.00: configured for UDMA/133 [ 6.762256] scsi 0:0:0:0: Direct-Access ATA Micron_M500IT_MT MU01 PQ: 0 ANSI: 5 and then for the error: [ 120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen [ 120.860338] ata1.00: irq_stat 0x40000008 [ 120.860342] ata1.00: failed command: SEND FPDMA QUEUED [ 120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout) [ 120.860353] ata1.00: status: { DRDY } [ 120.860543] ata1: hard resetting link [ 121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 121.166376] ata1.00: supports DRM functions and may not be fully accessible [ 121.186238] ata1.00: supports DRM functions and may not be fully accessible [ 121.204445] ata1.00: configured for UDMA/133 [ 121.204454] ata1.00: device reported invalid CHS sector 0 [ 121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 [ 121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current] [ 121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4 [ 121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00 [ 121.204559] print_req_error: I/O error, dev sda, sector 272512 After few reboots with these errors, and the SSD is corrupted. After blacklisting it, the errors are not seen and the SSD does not get corrupted any more. Fixes: 243918be6393 ("libata: Do not blacklist Micron M500DC") Cc: Martin K. Petersen Cc: stable@vger.kernel.org Signed-off-by: Sudip Mukherjee Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 21712abb8ba2703185f4ea71c4355618bebc6b22 Author: Tejun Heo Date: Tue May 8 14:21:56 2018 -0700 libata: Blacklist some Sandisk SSDs for NCQ commit 322579dcc865b94b47345ad1b6002ad167f85405 upstream. Sandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up regularly under sustained moderate load with NCQ enabled. Blacklist for now. Signed-off-by: Tejun Heo Reported-by: Dave Jones Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f2a3c8bb4d102330bb0a5d60d729a29c26e2ebcc Author: Corneliu Doban Date: Fri May 18 15:03:57 2018 -0700 mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus commit 3de06d5a1f05c11c94cbb68af14dbfa7fb81d78b upstream. The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to properly reset the host controller (reset all) on initialization after exiting deep sleep. Signed-off-by: Corneliu Doban Signed-off-by: Scott Branden Reviewed-by: Ray Jui Reviewed-by: Srinath Mannam Fixes: c833e92bbb60 ("mmc: sdhci-iproc: support standard byte register accesses") Cc: stable@vger.kernel.org # v4.10+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4da8f20a992c83f363f9302d5c316a4da4fc7485 Author: Corneliu Doban Date: Fri May 18 15:03:56 2018 -0700 mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register commit 5f651b870485ee60f5abbbd85195a6852978894a upstream. When the host controller accepts only 32bit writes, the value of the 16bit TRANSFER_MODE register, that has the same 32bit address as the 16bit COMMAND register, needs to be saved and it will be written in a 32bit write together with the command as this will trigger the host to send the command on the SD interface. When sending the tuning command, TRANSFER_MODE is written and then sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and write it again resulting in wrong value to be written because the initial write value was saved in a shadow and the read-back returned a wrong value, from the register. Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE when a saved value exist. Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are saved for a different reason, although a scenario that will cause the mentioned problem on this registers is not probable. Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver") Signed-off-by: Corneliu Doban Signed-off-by: Scott Branden Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ebedf0b290473b0bfb782a5354af85c98262b655 Author: Srinath Mannam Date: Fri May 18 15:03:55 2018 -0700 mmc: sdhci-iproc: remove hard coded mmc cap 1.8v commit 4c94238f37af87a2165c3fb491b4a8b50e90649c upstream. Remove hard coded mmc cap 1.8v from platform data as it is board specific. The 1.8v DDR mmc caps can be enabled using DTS property for those boards that support it. Fixes: b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data") Signed-off-by: Srinath Mannam Signed-off-by: Scott Branden Reviewed-by: Ray Jui Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f440ea85d429e59f63d626e017403cb09d9adbdb Author: Al Viro Date: Fri May 4 08:23:01 2018 -0400 do d_instantiate/unlock_new_inode combinations safely commit 1e2e547a93a00ebc21582c06ca3c6cfea2a309ee upstream. For anything NFS-exported we do _not_ want to unlock new inode before it has grown an alias; original set of fixes got the ordering right, but missed the nasty complication in case of lockdep being enabled - unlock_new_inode() does lockdep_annotate_inode_mutex_key(inode) which can only be done before anyone gets a chance to touch ->i_mutex. Unfortunately, flipping the order and doing unlock_new_inode() before d_instantiate() opens a window when mkdir can race with open-by-fhandle on a guessed fhandle, leading to multiple aliases for a directory inode and all the breakage that follows from that. Correct solution: a new primitive (d_instantiate_new()) combining these two in the right order - lockdep annotate, then d_instantiate(), then the rest of unlock_new_inode(). All combinations of d_instantiate() with unlock_new_inode() should be converted to that. Cc: stable@kernel.org # 2.6.29 and later Tested-by: Mike Marshall Reviewed-by: Andreas Dilger Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit ba3fbb7afde9a70ac2f902fa62b79793789c3328 Author: Ben Hutchings Date: Thu May 17 22:34:39 2018 +0100 ALSA: timer: Fix pause event notification commit 3ae180972564846e6d794e3615e1ab0a1e6c4ef9 upstream. Commit f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock") combined the start/continue and stop/pause functions, and in doing so changed the event code for the pause case to SNDRV_TIMER_EVENT_CONTINUE. Change it back to SNDRV_TIMER_EVENT_PAUSE. Fixes: f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock") Signed-off-by: Ben Hutchings Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fbcede36bbfd69a9df511a22d14bccaaf36b412a Author: Al Viro Date: Sun May 20 16:46:23 2018 -0400 aio: fix io_destroy(2) vs. lookup_ioctx() race commit baf10564fbb66ea222cae66fbff11c444590ffd9 upstream. kill_ioctx() used to have an explicit RCU delay between removing the reference from ->ioctx_table and percpu_ref_kill() dropping the refcount. At some point that delay had been removed, on the theory that percpu_ref_kill() itself contained an RCU delay. Unfortunately, that was the wrong kind of RCU delay and it didn't care about rcu_read_lock() used by lookup_ioctx(). As the result, we could get ctx freed right under lookup_ioctx(). Tejun has fixed that in a6d7cff472e ("fs/aio: Add explicit RCU grace period when freeing kioctx"); however, that fix is not enough. Suppose io_destroy() from one thread races with e.g. io_setup() from another; CPU1 removes the reference from current->mm->ioctx_table[...] just as CPU2 has picked it (under rcu_read_lock()). Then CPU1 proceeds to drop the refcount, getting it to 0 and triggering a call of free_ioctx_users(), which proceeds to drop the secondary refcount and once that reaches zero calls free_ioctx_reqs(). That does INIT_RCU_WORK(&ctx->free_rwork, free_ioctx); queue_rcu_work(system_wq, &ctx->free_rwork); and schedules freeing the whole thing after RCU delay. In the meanwhile CPU2 has gotten around to percpu_ref_get(), bumping the refcount from 0 to 1 and returned the reference to io_setup(). Tejun's fix (that queue_rcu_work() in there) guarantees that ctx won't get freed until after percpu_ref_get(). Sure, we'd increment the counter before ctx can be freed. Now we are out of rcu_read_lock() and there's nothing to stop freeing of the whole thing. Unfortunately, CPU2 assumes that since it has grabbed the reference, ctx is *NOT* going away until it gets around to dropping that reference. The fix is obvious - use percpu_ref_tryget_live() and treat failure as miss. It's not costlier than what we currently do in normal case, it's safe to call since freeing *is* delayed and it closes the race window - either lookup_ioctx() comes before percpu_ref_kill() (in which case ctx->users won't reach 0 until the caller of lookup_ioctx() drops it) or lookup_ioctx() fails, ctx->users is unaffected and caller of lookup_ioctx() doesn't see the object in question at all. Cc: stable@kernel.org Fixes: a6d7cff472e "fs/aio: Add explicit RCU grace period when freeing kioctx" Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit b9659ff375cbb965bbfa3cbce1336b917aa0831e Author: Dave Chinner Date: Fri May 11 11:20:57 2018 +1000 fs: don't scan the inode cache before SB_BORN is set commit 79f546a696bff2590169fb5684e23d65f4d9f591 upstream. We recently had an oops reported on a 4.14 kernel in xfs_reclaim_inodes_count() where sb->s_fs_info pointed to garbage and so the m_perag_tree lookup walked into lala land. It produces an oops down this path during the failed mount: radix_tree_gang_lookup_tag+0xc4/0x130 xfs_perag_get_tag+0x37/0xf0 xfs_reclaim_inodes_count+0x32/0x40 xfs_fs_nr_cached_objects+0x11/0x20 super_cache_count+0x35/0xc0 shrink_slab.part.66+0xb1/0x370 shrink_node+0x7e/0x1a0 try_to_free_pages+0x199/0x470 __alloc_pages_slowpath+0x3a1/0xd20 __alloc_pages_nodemask+0x1c3/0x200 cache_grow_begin+0x20b/0x2e0 fallback_alloc+0x160/0x200 kmem_cache_alloc+0x111/0x4e0 The problem is that the superblock shrinker is running before the filesystem structures it depends on have been fully set up. i.e. the shrinker is registered in sget(), before ->fill_super() has been called, and the shrinker can call into the filesystem before fill_super() does it's setup work. Essentially we are exposed to both use-after-free and use-before-initialisation bugs here. To fix this, add a check for the SB_BORN flag in super_cache_count. In general, this flag is not set until ->fs_mount() completes successfully, so we know that it is set after the filesystem setup has completed. This matches the trylock_super() behaviour which will not let super_cache_scan() run if SB_BORN is not set, and hence will not allow the superblock shrinker from entering the filesystem while it is being set up or after it has failed setup and is being torn down. Cc: stable@kernel.org Signed-Off-By: Dave Chinner Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 1e5edf32e44d74f211d958c3fbe117f8f356010e Author: Al Viro Date: Sun May 6 12:15:20 2018 -0400 affs_lookup(): close a race with affs_remove_link() commit 30da870ce4a4e007c901858a96e9e394a1daa74a upstream. we unlock the directory hash too early - if we are looking at secondary link and primary (in another directory) gets removed just as we unlock, we could have the old primary moved in place of the secondary, leaving us to look into freed entry (and leaving our dentry with ->d_fsdata pointing to a freed entry). Cc: stable@vger.kernel.org # 2.4.4+ Acked-by: David Sterba Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 2871a701329c40f4d2e1581e19beae88a4715fd4 Author: Colin Ian King Date: Mon May 14 18:23:50 2018 +0100 KVM: Fix spelling mistake: "cop_unsuable" -> "cop_unusable" commit ba3696e94d9d590d9a7e55f68e81c25dba515191 upstream. Trivial fix to spelling mistake in debugfs_entries text. Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM") Signed-off-by: Colin Ian King Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kernel-janitors@vger.kernel.org Cc: # 3.10+ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit bba75a0ccdb58317dda14464ae1c8dabfa55b230 Author: Maciej W. Rozycki Date: Mon May 14 16:49:43 2018 +0100 MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs commit 9a3a92ccfe3620743d4ae57c987dc8e9c5f88996 upstream. Check the TIF_32BIT_FPREGS task setting of the tracee rather than the tracer in determining the layout of floating-point general registers in the floating-point context, correcting access to odd-numbered registers for o32 tracees where the setting disagrees between the two processes. Fixes: 597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries") Signed-off-by: Maciej W. Rozycki Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: # 3.14+ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit 769fc447cced0178dacdeb414a82ba70a7bd1188 Author: Maciej W. Rozycki Date: Mon Apr 30 15:56:47 2018 +0100 MIPS: ptrace: Expose FIR register through FP regset commit 71e909c0cdad28a1df1fa14442929e68615dee45 upstream. Correct commit 7aeb753b5353 ("MIPS: Implement task_user_regset_view.") and expose the FIR register using the unused 4 bytes at the end of the NT_PRFPREG regset. Without that register included clients cannot use the PTRACE_GETREGSET request to retrieve the complete FPU register set and have to resort to one of the older interfaces, either PTRACE_PEEKUSR or PTRACE_GETFPREGS, to retrieve the missing piece of data. Also the register is irreversibly missing from core dumps. This register is architecturally hardwired and read-only so the write path does not matter. Ignore data supplied on writes then. Fixes: 7aeb753b5353 ("MIPS: Implement task_user_regset_view.") Signed-off-by: James Hogan Signed-off-by: Maciej W. Rozycki Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: # 3.13+ Patchwork: https://patchwork.linux-mips.org/patch/19273/ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit 368b70857dd7d8a39735a2faa2f844a38f932d35 Author: NeilBrown Date: Fri Apr 27 09:28:34 2018 +1000 MIPS: c-r4k: Fix data corruption related to cache coherence commit 55a2aa08b3af519a9693f99cdf7fa6d8b62d9f65 upstream. When DMA will be performed to a MIPS32 1004K CPS, the L1-cache for the range needs to be flushed and invalidated first. The code currently takes one of two approaches. 1/ If the range is less than the size of the dcache, then HIT type requests flush/invalidate cache lines for the particular addresses. HIT-type requests a globalised by the CPS so this is safe on SMP. 2/ If the range is larger than the size of dcache, then INDEX type requests flush/invalidate the whole cache. INDEX type requests affect the local cache only. CPS does not propagate them in any way. So this invalidation is not safe on SMP CPS systems. Data corruption due to '2' can quite easily be demonstrated by repeatedly "echo 3 > /proc/sys/vm/drop_caches" and then sha1sum a file that is several times the size of available memory. Dropping caches means that large contiguous extents (large than dcache) are more likely. This was not a problem before Linux-4.8 because option 2 was never used if CONFIG_MIPS_CPS was defined. The commit which removed that apparently didn't appreciate the full consequence of the change. We could, in theory, globalize the INDEX based flush by sending an IPI to other cores. These cache invalidation routines can be called with interrupts disabled and synchronous IPI require interrupts to be enabled. Asynchronous IPI may not trigger writeback soon enough. So we cannot use IPI in practice. We can already test if IPI would be needed for an INDEX operation with r4k_op_needs_ipi(R4K_INDEX). If this is true then we mustn't try the INDEX approach as we cannot use IPI. If this is false (e.g. when there is only one core and hence one L1 cache) then it is safe to use the INDEX approach without IPI. This patch avoids options 2 if r4k_op_needs_ipi(R4K_INDEX), and so eliminates the corruption. Fixes: c00ab4896ed5 ("MIPS: Remove cpu_has_safe_index_cacheops") Signed-off-by: NeilBrown Cc: Ralf Baechle Cc: Paul Burton Cc: linux-mips@linux-mips.org Cc: # 4.8+ Patchwork: https://patchwork.linux-mips.org/patch/19259/ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman