commit 7a9ed084b55a775eab0d27be744c22905511208c Author: Alexandre Frade Date: Wed May 11 15:55:24 2022 +0000 Linux 5.15.38-xanmod1-tt Signed-off-by: Alexandre Frade commit 592abb6699a60dba79f8e1bb5d2e09d67d77e26d Merge: beecca8e7809 81a1317facca Author: Alexandre Frade Date: Wed May 11 15:46:09 2022 +0000 Merge commit '5.15' into 5.15-tt commit 81a1317facca927bd2a65402e5ef19e810a894a1 Author: Alexandre Frade Date: Wed May 11 00:12:58 2022 +0000 XANMOD: block/mq-deadline: Equal read and write priority for responsiveness Signed-off-by: Alexandre Frade commit de5cb1096f5844e085e222307ed69f221580a183 Author: Alexandre Frade Date: Tue May 10 21:09:50 2022 +0000 Merge fix [2/2]: net-tcp_bbr: v2 patchset Signed-off-by: Alexandre Frade commit 248825f9ab551b4dd4d5a8c4d3dcf16520521b0b Merge: 5322cb851f07 3fbf24b73f4a Author: Alexandre Frade Date: Tue May 10 20:52:53 2022 +0000 Merge tag 'v5.15.38' into 5.15 This is the 5.15.38 stable release commit 5322cb851f07f3dfd31c5bbad471670214a2a0ff Author: Alexandre Frade Date: Tue May 10 20:52:38 2022 +0000 Merge fix [1/2]: net-tcp_bbr: v2 patchset Signed-off-by: Alexandre Frade commit 3fbf24b73f4a5bc8fd39a6b7a29145451c1039ce Author: Greg Kroah-Hartman Date: Mon May 9 09:14:44 2022 +0200 Linux 5.15.38 Link: https://lore.kernel.org/r/20220504153053.873100034@linuxfoundation.org Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 151322c24e8781a75cd9ec14049ef91a084da0b0 Author: Alexey Kardashevskiy Date: Wed Mar 9 17:18:22 2022 +1100 powerpc/64: Add UADDR64 relocation support commit d799769188529abc6cbf035a10087a51f7832b6b upstream. When ld detects unaligned relocations, it emits R_PPC64_UADDR64 relocations instead of R_PPC64_RELATIVE. Currently R_PPC64_UADDR64 are detected by arch/powerpc/tools/relocs_check.sh and expected not to work. Below is a simple chunk to trigger this behaviour (this disables optimization for the demonstration purposes only, this also happens with -O1/-O2 when CONFIG_PRINTK_INDEX=y, for example): \#pragma GCC push_options \#pragma GCC optimize ("O0") struct entry { const char *file; int line; } __attribute__((packed)); static const struct entry e1 = { .file = __FILE__, .line = __LINE__ }; static const struct entry e2 = { .file = __FILE__, .line = __LINE__ }; ... prom_printf("e1=%s %lx %lx\n", e1.file, (unsigned long) e1.file, mfmsr()); prom_printf("e2=%s %lx\n", e2.file, (unsigned long) e2.file); \#pragma GCC pop_options This adds support for UADDR64 for 64bit. This reuses __dynamic_symtab from the 32bit code which supports more relocation types already. Because RELACOUNT includes only R_PPC64_RELATIVE, this replaces it with RELASZ which is the size of all relocation records. Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Cc: Nathan Chancellor Link: https://lore.kernel.org/r/20220309061822.168173-1-aik@ozlabs.ru Signed-off-by: Greg Kroah-Hartman commit ec1bb681eee2f179fc7166a620766a48b0aa8c23 Author: Peter Zijlstra Date: Sun Apr 17 17:03:40 2022 +0200 objtool: Fix type of reloc::addend commit c087c6e7b551b7f208c0b852304f044954cf2bb3 upstream. Elf{32,64}_Rela::r_addend is of type: Elf{32,64}_Sword, that means that our reloc::addend needs to be long or face tuncation issues when we do elf_rebuild_reloc_section(): - 107: 48 b8 00 00 00 00 00 00 00 00 movabs $0x0,%rax 109: R_X86_64_64 level4_kernel_pgt+0x80000067 + 107: 48 b8 00 00 00 00 00 00 00 00 movabs $0x0,%rax 109: R_X86_64_64 level4_kernel_pgt-0x7fffff99 Fixes: 627fce14809b ("objtool: Add ORC unwind table generation") Signed-off-by: Peter Zijlstra (Intel) Acked-by: Josh Poimboeuf Link: https://lkml.kernel.org/r/20220419203807.596871927@infradead.org Signed-off-by: Greg Kroah-Hartman commit 19ffee7d62311111dabbb89d946ca22b1b867807 Author: Peter Zijlstra Date: Sun Apr 17 17:03:36 2022 +0200 objtool: Fix code relocs vs weak symbols commit 4abff6d48dbcea8200c7ea35ba70c242d128ebf3 upstream. Occasionally objtool driven code patching (think .static_call_sites .retpoline_sites etc..) goes sideways and it tries to patch an instruction that doesn't match. Much head-scatching and cursing later the problem is as outlined below and affects every section that objtool generates for us, very much including the ORC data. The below uses .static_call_sites because it's convenient for demonstration purposes, but as mentioned the ORC sections, .retpoline_sites and __mount_loc are all similarly affected. Consider: foo-weak.c: extern void __SCT__foo(void); __attribute__((weak)) void foo(void) { return __SCT__foo(); } foo.c: extern void __SCT__foo(void); extern void my_foo(void); void foo(void) { my_foo(); return __SCT__foo(); } These generate the obvious code (gcc -O2 -fcf-protection=none -fno-asynchronous-unwind-tables -c foo*.c): foo-weak.o: 0000000000000000 : 0: e9 00 00 00 00 jmpq 5 1: R_X86_64_PLT32 __SCT__foo-0x4 foo.o: 0000000000000000 : 0: 48 83 ec 08 sub $0x8,%rsp 4: e8 00 00 00 00 callq 9 5: R_X86_64_PLT32 my_foo-0x4 9: 48 83 c4 08 add $0x8,%rsp d: e9 00 00 00 00 jmpq 12 e: R_X86_64_PLT32 __SCT__foo-0x4 Now, when we link these two files together, you get something like (ld -r -o foos.o foo-weak.o foo.o): foos.o: 0000000000000000 : 0: e9 00 00 00 00 jmpq 5 1: R_X86_64_PLT32 __SCT__foo-0x4 5: 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:0x0(%rax,%rax,1) f: 90 nop 0000000000000010 : 10: 48 83 ec 08 sub $0x8,%rsp 14: e8 00 00 00 00 callq 19 15: R_X86_64_PLT32 my_foo-0x4 19: 48 83 c4 08 add $0x8,%rsp 1d: e9 00 00 00 00 jmpq 22 1e: R_X86_64_PLT32 __SCT__foo-0x4 Noting that ld preserves the weak function text, but strips the symbol off of it (hence objdump doing that funny negative offset thing). This does lead to 'interesting' unused code issues with objtool when ran on linked objects, but that seems to be working (fingers crossed). So far so good.. Now lets consider the objtool static_call output section (readelf output, old binutils): foo-weak.o: Relocation section '.rela.static_call_sites' at offset 0x2c8 contains 1 entry: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000 .text + 0 0000000000000004 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 foo.o: Relocation section '.rela.static_call_sites' at offset 0x310 contains 2 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000 .text + d 0000000000000004 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 foos.o: Relocation section '.rela.static_call_sites' at offset 0x430 contains 4 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000000 0000000100000002 R_X86_64_PC32 0000000000000000 .text + 0 0000000000000004 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 0000000000000008 0000000100000002 R_X86_64_PC32 0000000000000000 .text + 1d 000000000000000c 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 So we have two patch sites, one in the dead code of the weak foo and one in the real foo. All is well. *HOWEVER*, when the toolchain strips unused section symbols it generates things like this (using new enough binutils): foo-weak.o: Relocation section '.rela.static_call_sites' at offset 0x2c8 contains 1 entry: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000 foo + 0 0000000000000004 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 foo.o: Relocation section '.rela.static_call_sites' at offset 0x310 contains 2 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000 foo + d 0000000000000004 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 foos.o: Relocation section '.rela.static_call_sites' at offset 0x430 contains 4 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000000 0000000100000002 R_X86_64_PC32 0000000000000000 foo + 0 0000000000000004 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 0000000000000008 0000000100000002 R_X86_64_PC32 0000000000000000 foo + d 000000000000000c 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 And now we can see how that foos.o .static_call_sites goes side-ways, we now have _two_ patch sites in foo. One for the weak symbol at foo+0 (which is no longer a static_call site!) and one at foo+d which is in fact the right location. This seems to happen when objtool cannot find a section symbol, in which case it falls back to any other symbol to key off of, however in this case that goes terribly wrong! As such, teach objtool to create a section symbol when there isn't one. Fixes: 44f6a7c0755d ("objtool: Fix seg fault with Clang non-section symbols") Signed-off-by: Peter Zijlstra (Intel) Acked-by: Josh Poimboeuf Link: https://lkml.kernel.org/r/20220419203807.655552918@infradead.org Signed-off-by: Greg Kroah-Hartman commit 80c71d76e88ab3cdbb76e4a2e65828048f1114a7 Author: Christophe Leroy Date: Wed Mar 23 11:51:55 2022 +0100 eeprom: at25: Use DMA safe buffers commit 5b47b751b760ee1c74a51660fd096aa148a362cd upstream. Reading EEPROM fails with following warning: [ 16.357496] ------------[ cut here ]------------ [ 16.357529] fsl_spi b01004c0.spi: rejecting DMA map of vmalloc memory [ 16.357698] WARNING: CPU: 0 PID: 371 at include/linux/dma-mapping.h:326 fsl_spi_cpm_bufs+0x2a0/0x2d8 [ 16.357775] CPU: 0 PID: 371 Comm: od Not tainted 5.16.11-s3k-dev-01743-g19beecbfe9d6-dirty #109 [ 16.357806] NIP: c03fbc9c LR: c03fbc9c CTR: 00000000 [ 16.357825] REGS: e68d9b20 TRAP: 0700 Not tainted (5.16.11-s3k-dev-01743-g19beecbfe9d6-dirty) [ 16.357849] MSR: 00029032 CR: 24002282 XER: 00000000 [ 16.357931] [ 16.357931] GPR00: c03fbc9c e68d9be0 c26d06a0 00000039 00000001 c0d36364 c0e96428 00000027 [ 16.357931] GPR08: 00000001 00000000 00000023 3fffc000 24002282 100d3dd6 100a2ffc 00000000 [ 16.357931] GPR16: 100cd280 100b0000 00000000 aff54f7e 100d0000 100d0000 00000001 100cf328 [ 16.357931] GPR24: 100cf328 00000000 00000003 e68d9e30 c156b410 e67ab4c0 e68d9d38 c24ab278 [ 16.358253] NIP [c03fbc9c] fsl_spi_cpm_bufs+0x2a0/0x2d8 [ 16.358292] LR [c03fbc9c] fsl_spi_cpm_bufs+0x2a0/0x2d8 [ 16.358325] Call Trace: [ 16.358336] [e68d9be0] [c03fbc9c] fsl_spi_cpm_bufs+0x2a0/0x2d8 (unreliable) [ 16.358388] [e68d9c00] [c03fcb44] fsl_spi_bufs.isra.0+0x94/0x1a0 [ 16.358436] [e68d9c20] [c03fd970] fsl_spi_do_one_msg+0x254/0x3dc [ 16.358483] [e68d9cb0] [c03f7e50] __spi_pump_messages+0x274/0x8a4 [ 16.358529] [e68d9ce0] [c03f9d30] __spi_sync+0x344/0x378 [ 16.358573] [e68d9d20] [c03fb52c] spi_sync+0x34/0x60 [ 16.358616] [e68d9d30] [c03b4dec] at25_ee_read+0x138/0x1a8 [ 16.358667] [e68d9e50] [c04a8fb8] bin_attr_nvmem_read+0x98/0x110 [ 16.358725] [e68d9e60] [c0204b14] kernfs_fop_read_iter+0xc0/0x1fc [ 16.358774] [e68d9e80] [c0168660] vfs_read+0x284/0x410 [ 16.358821] [e68d9f00] [c016925c] ksys_read+0x6c/0x11c [ 16.358863] [e68d9f30] [c00160e0] ret_from_syscall+0x0/0x28 ... [ 16.359608] ---[ end trace a4ce3e34afef0cb5 ]--- [ 16.359638] fsl_spi b01004c0.spi: unable to map tx dma This is due to the AT25 driver using buffers on stack, which is not possible with CONFIG_VMAP_STACK. As mentionned in kernel Documentation (Documentation/spi/spi-summary.rst): - Follow standard kernel rules, and provide DMA-safe buffers in your messages. That way controller drivers using DMA aren't forced to make extra copies unless the hardware requires it (e.g. working around hardware errata that force the use of bounce buffering). Modify the driver to use a buffer located in the at25 device structure which is allocated via kmalloc during probe. Protect writes in this new buffer with the driver's mutex. Fixes: b587b13a4f67 ("[PATCH] SPI eeprom driver") Cc: stable Signed-off-by: Christophe Leroy Link: https://lore.kernel.org/r/230a9486fc68ea0182df46255e42a51099403642.1648032613.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 7d0010f628409b6c2b65013de97972b3934c2df9 Author: Namhyung Kim Date: Fri Apr 15 17:40:48 2022 -0700 perf symbol: Remove arch__symbols__fixup_end() commit a5d20d42a2f2dc2b2f9e9361912062732414090d upstream. Now the generic code can handle kallsyms fixup properly so no need to keep the arch-functions anymore. Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition") Signed-off-by: Namhyung Kim Acked-by: Ian Rogers Cc: Heiko Carstens Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Leo Yan Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Mathieu Poirier Cc: Michael Ellerman Cc: Michael Petlan Cc: Peter Zijlstra Cc: Song Liu Cc: Will Deacon Cc: linux-s390@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Link: https://lore.kernel.org/r/20220416004048.1514900-4-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit ea47db3bac7ad361845e350d2759e9d25b992353 Author: Daniel Starke Date: Fri Apr 22 00:10:25 2022 -0700 tty: n_gsm: fix software flow control handling commit f4f7d63287217ba25e5c80f5faae5e4f7118790e upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.4.8.1 states that XON/XOFF characters shall be used instead of Fcon/Fcoff command in advanced option mode to handle flow control. Chapter 5.4.8.2 describes how XON/XOFF characters shall be handled. Basic option mode only used Fcon/Fcoff commands and no XON/XOFF characters. These are treated as data bytes here. The current implementation uses the gsm_mux field 'constipated' to handle flow control from the remote peer and the gsm_dlci field 'constipated' to handle flow control from each DLCI. The later is unrelated to this patch. The gsm_mux field is correctly set for Fcon/Fcoff commands in gsm_control_message(). However, the same is not true for XON/XOFF characters in gsm1_receive(). Disable software flow control handling in the tty to allow explicit handling by n_gsm. Add the missing handling in advanced option mode for gsm_mux in gsm1_receive() to comply with the standard. This patch depends on the following commit: Commit 8838b2af23ca ("tty: n_gsm: fix SW flow control encoding/handling") Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220422071025.5490-3-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit ab49c23668ea6dd439c7539c301eacf6f970aea9 Author: Daniel Starke Date: Thu Apr 14 02:42:25 2022 -0700 tty: n_gsm: fix incorrect UA handling commit ff9166c623704337bd6fe66fce2838d9768a6634 upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.4.4.2 states that any received unnumbered acknowledgment (UA) with its poll/final (PF) bit set to 0 shall be discarded. Currently, all UA frame are handled in the same way regardless of the PF bit. This does not comply with the standard. Remove the UA case in gsm_queue() to process only UA frames with PF bit set to 1 to abide the standard. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-20-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit e0a84ae1c6624441cae1481754cf3fbf36f32e70 Author: Daniel Starke Date: Thu Apr 14 02:42:22 2022 -0700 tty: n_gsm: fix reset fifo race condition commit 73029a4d7161f8b6c0934553145ef574d2d0c645 upstream. gsmtty_write() and gsm_dlci_data_output() properly guard the fifo access. However, gsm_dlci_close() and gsmtty_flush_buffer() modifies the fifo but do not guard this. Add a guard here to prevent race conditions on parallel writes to the fifo. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-17-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit f92783b7568e2ece82259d5eb5b3197684ec86f2 Author: Daniel Starke Date: Thu Apr 14 02:42:19 2022 -0700 tty: n_gsm: fix missing tty wakeup in convergence layer type 2 commit 1adf6fee58ca25fb6720b8d34c919dcf5425cc9c upstream. gsm_control_modem() informs the virtual tty that more data can be written after receiving a control signal octet via modem status command (MSC). However, gsm_dlci_data() fails to do the same after receiving a control signal octet from the convergence layer type 2 header. Add tty_wakeup() in gsm_dlci_data() for convergence layer type 2 to fix this. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-14-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit aeacc7e81c71c1ad030e534554ccbc5984c72cb6 Author: Daniel Starke Date: Thu Apr 14 02:42:18 2022 -0700 tty: n_gsm: fix wrong signal octets encoding in MSC commit 317f86af7f5d19f286ed2d181cbaef4a188c7f19 upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. The value of the modem status command (MSC) frame contains an address field, control signal and optional break signal octet. The address field is encoded as described in chapter 5.2.1.2 with only one octet (may be extended to more in future versions of the standard). Whereas the control signal and break signal octet are always one byte each. This is strange at first glance as it makes the EA bit redundant. However, the same two octets are also encoded as header in convergence layer type 2 as described in chapter 5.5.2. No header length field is given and the only way to test if there is an optional break signal octet is via the EA flag which extends the control signal octet with a break signal octet. Now it becomes obvious how the EA bit for those two octets shall be encoded in the MSC frame. The current implementation treats the signal octet different for MSC frame and convergence layer type 2 header even though the standard describes it for both in the same way. Use the EA bit to encode the signal octets not only in the convergence layer type 2 header but also in the MSC frame in the same way with either 1 or 2 bytes in case of an optional break signal. Adjust the receiving path accordingly in gsm_control_modem(). Fixes: 3ac06b905655 ("tty: n_gsm: Fix for modems with brk in modem status control") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-13-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit ef2f08ee00b0b1378a2414714fe92514d8c74ced Author: Daniel Starke Date: Thu Apr 14 02:42:17 2022 -0700 tty: n_gsm: fix wrong command frame length field encoding commit 398867f59f956985f4c324f173eff7b946e14bd8 upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.4.6.1 states that each command frame shall be made up from type, length and value. Looking for example in chapter 5.4.6.3.5 at the description for the encoding of a flow control on command it becomes obvious, that the type and length field is always present whereas the value may be zero bytes long. The current implementation omits the length field if the value is not present. This is wrong. Correct this by always sending the length in gsm_control_transmit(). So far only the modem status command (MSC) has included a value and encoded its length directly. Therefore, also change gsmtty_modem_update(). Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-12-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit e51f35470383bd0311781453f896e01491338a25 Author: Daniel Starke Date: Thu Apr 14 02:42:16 2022 -0700 tty: n_gsm: fix wrong command retry handling commit d0bcdffcad5a22f202e3bf37190c0dd8c080ea92 upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.7.3 states that the valid range for the maximum number of retransmissions (N2) is from 0 to 255 (both including). gsm_config() fails to limit this range correctly. Furthermore, gsm_control_retransmit() handles this number incorrectly by performing N2 - 1 retransmission attempts. Setting N2 to zero results in more than 255 retransmission attempts. Fix the range check in gsm_config() and the value handling in gsm_control_send() and gsm_control_retransmit() to comply with 3GPP 27.010. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-11-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit 73defa00a7bcb461e035d631180bda42afae445a Author: Daniel Starke Date: Thu Apr 14 02:42:15 2022 -0700 tty: n_gsm: fix missing explicit ldisc flush commit 17eac652028501df7ea296b1d9b9c134db262b7d upstream. In gsm_cleanup_mux() the muxer is closed down and all queues are removed. However, removing the queues is done without explicit control of the underlying buffers. Flush those before freeing up our queues to ensure that all outgoing queues are cleared consistently. Otherwise, a new mux connection establishment attempt may time out while the underlying tty is still busy sending out the remaining data from the previous connection. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-10-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit 2484787cde3db0d64120e5a16e27c0fed5b2510e Author: Daniel Starke Date: Thu Apr 14 02:42:14 2022 -0700 tty: n_gsm: fix wrong DLCI release order commit deefc58bafb4841df7f0a0d85d89a1c819db9743 upstream. The current DLCI release order starts with the control channel followed by the user channels. Reverse this order to keep the control channel open until all user channels have been released. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-9-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit 0a7fe1a47ca5ed9d48cd7fdd153506937e7d97b3 Author: Daniel Starke Date: Thu Apr 14 02:42:13 2022 -0700 tty: n_gsm: fix insufficient txframe size commit 535bf600de75a859698892ee873521a48d289ec1 upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.7.2 states that the maximum frame size (N1) refers to the length of the information field (i.e. user payload). However, 'txframe' stores the whole frame including frame header, checksum and start/end flags. We also need to consider the byte stuffing overhead. Define constant for the protocol overhead and adjust the 'txframe' size calculation accordingly to reserve enough space for a complete mux frame including byte stuffing for advanced option mode. Note that no byte stuffing is applied to the start and end flag. Also use MAX_MTU instead of MAX_MRU as this buffer is used for data transmission. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-8-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit 87e1b4f90703eaaeec18d8e88dd1f138175ff888 Author: Florian Westphal Date: Thu Apr 28 09:39:21 2022 +0200 netfilter: nft_socket: only do sk lookups when indev is available commit 743b83f15d4069ea57c3e40996bf4a1077e0cdc1 upstream. Check if the incoming interface is available and NFT_BREAK in case neither skb->sk nor input device are set. Because nf_sk_lookup_slow*() assume packet headers are in the 'in' direction, use in postrouting is not going to yield a meaningful result. Same is true for the forward chain, so restrict the use to prerouting, input and output. Use in output work if a socket is already attached to the skb. Fixes: 554ced0a6e29 ("netfilter: nf_tables: add support for native socket matching") Reported-and-tested-by: Topi Miettinen Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit a93d2d3189e82fdea8ffe3127318266331a59195 Author: Daniel Starke Date: Thu Apr 14 02:42:12 2022 -0700 tty: n_gsm: fix malformed counter for out of frame data commit a24b4b2f660b7ddf3f484b37600bba382cb28a9d upstream. The gsm_mux field 'malformed' represents the number of malformed frames received. However, gsm1_receive() also increases this counter for any out of frame byte. Fix this by ignoring out of frame data for the malformed counter. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-7-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit 0d6289c4a0e1727590cde1f07378a88fab8fb198 Author: Daniel Starke Date: Thu Apr 14 02:42:10 2022 -0700 tty: n_gsm: fix wrong signal octet encoding in convergence layer type 2 commit 06d5afd4d640eea67f5623e76cd5fc03359b7f3c upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.5.2 describes that the signal octet in convergence layer type 2 can be either one or two bytes. The length is encoded in the EA bit. This is set 1 for the last byte in the sequence. gsmtty_modem_update() handles this correctly but gsm_dlci_data_output() fails to set EA to 1. There is no case in which we encode two signal octets as there is no case in which we send out a break signal. Therefore, always set the EA bit to 1 for the signal octet to fix this. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-5-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit 4e1beef38c351a85403b835e128329cf9edbe0b0 Author: Daniel Starke Date: Thu Apr 14 02:42:09 2022 -0700 tty: n_gsm: fix mux cleanup after unregister tty device commit 284260f278b706364fb4c88a7b56ba5298d5973c upstream. Internally, we manage the alive state of the mux channels and mux itself with the field member 'dead'. This makes it possible to notify the user if the accessed underlying link is already gone. On the other hand, however, removing the virtual ttys before terminating the channels may result in peer messages being received without any internal target. Move the mux cleanup procedure from gsmld_detach_gsm() to gsmld_close() to fix this by keeping the virtual ttys open until the mux has been cleaned up. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-4-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit 8b19dfb3e8174824315325691d869be90a3a96c2 Author: Daniel Starke Date: Thu Apr 14 02:42:08 2022 -0700 tty: n_gsm: fix decoupled mux resource commit 1ec92e9742774bf42614fceea3bf6b50c9409225 upstream. The active mux instances are managed in the gsm_mux array and via mux_get() and mux_put() functions separately. This gives a very loose coupling between the actual instance and the gsm_mux array which manages it. It also results in unnecessary lockings which makes it prone to failures. And it creates a race condition if more than the maximum number of mux instances are requested while the user changes the parameters of an active instance. The user may loose ownership of the current mux instance in this case. Fix this by moving the gsm_mux array handling to the mux allocation and deallocation functions. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-3-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit 7f71387d9f3bd83e183d38f7dd7b05165900fc03 Author: Daniel Starke Date: Thu Apr 14 02:42:07 2022 -0700 tty: n_gsm: fix restart handling via CLD command commit aa371e96f05dcb36a88298f5cb70aa7234d5e8b8 upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.8.2 states that both sides will revert to the non-multiplexed mode via a close-down message (CLD). The usual program flow is as following: - start multiplex mode by sending AT+CMUX to the mobile - establish the control channel (DLCI 0) - establish user channels (DLCI >0) - terminate user channels - send close-down message (CLD) - revert to AT protocol (i.e. leave multiplexed mode) The AT protocol is out of scope of the n_gsm driver. However, gsm_disconnect() sends CLD if gsm_config() detects that the requested parameters require the mux protocol to restart. The next immediate action is to start the mux protocol by opening DLCI 0 again. Any responder side which handles CLD commands correctly forces us to fail at this point because AT+CMUX needs to be sent to the mobile to start the mux again. Therefore, remove the CLD command in this phase and keep both sides in multiplexed mode. Remove the gsm_disconnect() function as it become unnecessary and merge the remaining parts into gsm_cleanup_mux() to handle the termination order and locking correctly. Fixes: 71e077915396 ("tty: n_gsm: do not send/receive in ldisc close path") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-2-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit a87a36badd949dfb2d88b0b272550864c44d9e31 Author: Namhyung Kim Date: Fri Apr 15 17:40:47 2022 -0700 perf symbol: Update symbols__fixup_end() commit 8799ebce84d672aae1dc3170510f6a3e66f96b11 upstream. Now arch-specific functions all do the same thing. When it fixes the symbol address it needs to check the boundary between the kernel image and modules. For the last symbol in the previous region, it cannot know the exact size as it's discarded already. Thus it just uses a small page size (4096) and rounds it up like the last symbol. Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition") Signed-off-by: Namhyung Kim Acked-by: Ian Rogers Cc: Heiko Carstens Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Leo Yan Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Mathieu Poirier Cc: Michael Ellerman Cc: Michael Petlan Cc: Peter Zijlstra Cc: Song Liu Cc: Will Deacon Cc: linux-s390@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Link: https://lore.kernel.org/r/20220416004048.1514900-3-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit cf7bf78f10bd668049213c29b4631fd812188b7e Author: Namhyung Kim Date: Fri Apr 15 17:40:46 2022 -0700 perf symbol: Pass is_kallsyms to symbols__fixup_end() commit 838425f2defe5262906b698752d28fd2fca1aac2 upstream. The symbol fixup is necessary for symbols in kallsyms since they don't have size info. So we use the next symbol's address to calculate the size. Now it's also used for user binaries because sometimes they miss size for hand-written asm functions. There's a arch-specific function to handle kallsyms differently but currently it cannot distinguish kallsyms from others. Pass this information explicitly to handle it properly. Note that those arch functions will be moved to the generic function so I didn't added it to the arch-functions. Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition") Signed-off-by: Namhyung Kim Acked-by: Ian Rogers Cc: Heiko Carstens Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Leo Yan Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Mathieu Poirier Cc: Michael Ellerman Cc: Michael Petlan Cc: Peter Zijlstra Cc: Song Liu Cc: Will Deacon Cc: linux-s390@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Link: https://lore.kernel.org/r/20220416004048.1514900-2-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit f858bd6536e1136765097171c338c9457a1f390d Author: Borislav Petkov Date: Tue Apr 19 09:52:41 2022 -0700 x86/cpu: Load microcode during restore_processor_state() commit f9e14dbbd454581061c736bf70bf5cbb15ac927c upstream. When resuming from system sleep state, restore_processor_state() restores the boot CPU MSRs. These MSRs could be emulated by microcode. If microcode is not loaded yet, writing to emulated MSRs leads to unchecked MSR access error: ... PM: Calling lapic_suspend+0x0/0x210 unchecked MSR access error: WRMSR to 0x10f (tried to write 0x0...0) at rIP: ... (native_write_msr) Call Trace: ? restore_processor_state x86_acpi_suspend_lowlevel acpi_suspend_enter suspend_devices_and_enter pm_suspend.cold state_store kobj_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write __x64_sys_write do_syscall_64 entry_SYSCALL_64_after_hwframe RIP: 0033:0x7fda13c260a7 To ensure microcode emulated MSRs are available for restoration, load the microcode on the boot CPU before restoring these MSRs. [ Pawan: write commit message and productize it. ] Fixes: e2a1256b17b1 ("x86/speculation: Restore speculation related MSRs during S3 resume") Reported-by: Kyle D. Pelton Signed-off-by: Borislav Petkov Signed-off-by: Pawan Gupta Tested-by: Kyle D. Pelton Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=215841 Link: https://lore.kernel.org/r/4350dfbf785cd482d3fafa72b2b49c83102df3ce.1650386317.git.pawan.kumar.gupta@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2333d2a72ba1332b0e81f76f1a9a516b863374d6 Author: Tim Harvey Date: Tue Apr 5 12:35:09 2022 -0700 ARM: dts: imx8mm-venice-gw{71xx,72xx,73xx}: fix OTG controller OC mode commit 4c79865f3e8a2db93ec1e844509edfebe5a6ae56 upstream. The GW71xx, GW72xx and GW73xx boards have USB1 routed to a USB OTG connectors and USB2 routed to a USB hub. The OTG connector has a over-currently protection with an active-low pin and the USB1 to HUB connection has no over-current protection (as the HUB itself implements this for its downstream ports). Add proper dt nodes to specify the over-current pin polarity for USB1 and disable over-current protection for USB2. Fixes: 6f30b27c5ef5 ("arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 0dc5cad09e3217955954c3d5ae1c9200e6c6888e Author: Eugen Hristev Date: Mon Mar 7 13:38:27 2022 +0200 ARM: dts: at91: sama7g5ek: enable pull-up on flexcom3 console lines commit 3f7ce6d7091765ed6c67c5d78aa364b9d17e3aab upstream. Flexcom3 is used as board console serial. There are no pull-ups on these lines on the board. This means that if a cable is not connected (that has pull-ups included), stray characters could appear on the console as the floating pins voltage levels are interpreted as incoming characters. To avoid this problem, enable the internal pull-ups on these lines. Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Eugen Hristev Reviewed-by: Tudor Ambarus Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20220307113827.2419331-1-eugen.hristev@microchip.com Signed-off-by: Greg Kroah-Hartman commit cf12ce1bd71d8fcfeacd0fd4b08af9e8950e7938 Author: Filipe Manana Date: Wed Apr 6 17:07:54 2022 +0100 btrfs: fix leaked plug after failure syncing log on zoned filesystems commit 50ff57888d0b13440e7f4cde05dc339ee8d0f1f8 upstream. On a zoned filesystem, if we fail to allocate the root node for the log root tree while syncing the log, we end up returning without finishing the IO plug we started before, resulting in leaking resources as we have started writeback for extent buffers of a log tree before. That allocation failure, which typically is either -ENOMEM or -ENOSPC, is not fatal and the fsync can safely fallback to a full transaction commit. So release the IO plug if we fail to allocate the extent buffer for the root of the log root tree when syncing the log on a zoned filesystem. Fixes: 3ddebf27fcd3a9 ("btrfs: zoned: reorder log node allocation on zoned filesystem") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 65b785cdb39763cd8f043c93a39e76052e9b0479 Author: Kees Cook Date: Thu Apr 21 09:55:04 2022 -0700 thermal: int340x: Fix attr.show callback prototype commit d0f6cfb2bd165b0aa307750e07e03420859bd554 upstream. Control Flow Integrity (CFI) instrumentation of the kernel noticed that the caller, dev_attr_show(), and the callback, odvp_show(), did not have matching function prototypes, which would cause a CFI exception to be raised. Correct the prototype by using struct device_attribute instead of struct kobj_attribute. Reported-and-tested-by: Joao Moreira Link: https://lore.kernel.org/lkml/067ce8bd4c3968054509831fa2347f4f@overdrivepizza.com/ Fixes: 006f006f1e5c ("thermal/int340x_thermal: Export OEM vendor variables") Cc: 5.8+ # 5.8+ Signed-off-by: Kees Cook Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f3106b0b0113f919289139676924ecaa3b6d81ef Author: Ville Syrjälä Date: Thu Apr 21 16:36:34 2022 +0300 ACPI: processor: idle: Avoid falling back to C3 type C-states commit fc45e55ebc58dbf622cb89ddbf797589c7a5510b upstream. The "safe state" index is used by acpi_idle_enter_bm() to avoid entering a C-state that may require bus mastering to be disabled on entry in the cases when this is not going to happen. For this reason, it should not be set to point to C3 type of C-states, because they may require bus mastering to be disabled on entry in principle. This was broken by commit d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state") which inadvertently allowed the "safe state" index to point to C3 type of C-states. This results in a machine that won't boot past the point when it first enters C3. Restore the correct behaviour (either demote to C1/C2, or use C3 but also set ARB_DIS=1). I hit this on a Fujitsu Siemens Lifebook S6010 (P3) machine. Fixes: d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state") Cc: 5.16+ # 5.16+ Signed-off-by: Ville Syrjälä Tested-by: Woody Suwalski [ rjw: Subject and changelog adjustments ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d2bc6fc51e584a3f0cbdf65f8fbfd5b923c44b49 Author: Dinh Nguyen Date: Wed Apr 20 10:23:45 2022 -0500 net: ethernet: stmmac: fix write to sgmii_adapter_base commit 5fd1fe4807f91ea0cca043114d929faa11bd4190 upstream. I made a mistake with the commit a6aaa0032424 ("net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link"). I should have tested against both scenario of having a SGMII interface and one without. Without the SGMII PCS TSE adpater, the sgmii_adapter_base address is NULL, thus a write to this address will fail. Cc: stable@vger.kernel.org Fixes: a6aaa0032424 ("net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link") Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20220420152345.27415-1-dinguyen@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4e308b21bc16231c90112d839859c9e38f7ef986 Author: Imre Deak Date: Thu Apr 21 19:22:21 2022 +0300 drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses commit 4ae4dd2e26fdfebf0b8c6af6c325383eadfefdb4 upstream. Fix typo in the _SEL_FETCH_PLANE_BASE_1_B register base address. Fixes: a5523e2ff074a5 ("drm/i915: Add PSR2 selective fetch registers") References: https://gitlab.freedesktop.org/drm/intel/-/issues/5400 Cc: José Roberto de Souza Cc: # v5.9+ Signed-off-by: Imre Deak Reviewed-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20220421162221.2261895-1-imre.deak@intel.com (cherry picked from commit af2cbc6ef967f61711a3c40fca5366ea0bc7fecc) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 67434e132b8c9d3fb59f0bc27da6d0a0488cf92b Author: Jouni Högander Date: Wed Apr 13 11:28:26 2022 +0300 drm/i915: Check EDID for HDR static metadata when choosing blc commit c05d8332f5d23fa3b521911cbe55a2b67fb21248 upstream. We have now seen panel (XMG Core 15 e21 laptop) advertizing support for Intel proprietary eDP backlight control via DPCD registers, but actually working only with legacy pwm control. This patch adds panel EDID check for possible HDR static metadata and Intel proprietary eDP backlight control is used only if that exists. Missing HDR static metadata is ignored if user specifically asks for Intel proprietary eDP backlight control via enable_dpcd_backlight parameter. v2 : - Ignore missing HDR static metadata if Intel proprietary eDP backlight control is forced via i915.enable_dpcd_backlight - Printout info message if panel is missing HDR static metadata and support for Intel proprietary eDP backlight control is detected Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5284 Cc: Lyude Paul Cc: Mika Kahola Cc: Jani Nikula Cc: Filippo Falezza Cc: stable@vger.kernel.org Signed-off-by: Jouni Högander Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220413082826.120634-1-jouni.hogander@intel.com Reviewed-by: Lyude Paul (cherry picked from commit b4b157577cb1de13bee8bebc3576f1de6799a921) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 891883c426b8b782fba5ebd3cade7184be701693 Author: Martin Willi Date: Tue Apr 19 15:47:00 2022 +0200 netfilter: Update ip6_route_me_harder to consider L3 domain commit 8ddffdb9442a9d60b4a6e679ac48d7d21403a674 upstream. The commit referenced below fixed packet re-routing if Netfilter mangles a routing key property of a packet and the packet is routed in a VRF L3 domain. The fix, however, addressed IPv4 re-routing, only. This commit applies the same behavior for IPv6. While at it, untangle the nested ternary operator to make the code more readable. Fixes: 6d8b49c3a3a3 ("netfilter: Update ip_route_me_harder to consider L3 domain") Cc: stable@vger.kernel.org Signed-off-by: Martin Willi Reviewed-by: David Ahern Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit c63fbe063ffba067469d33897621547983b8af87 Author: Md Sadre Alam Date: Mon Apr 18 13:18:27 2022 +0530 mtd: rawnand: qcom: fix memory corruption that causes panic commit ba7542eb2dd5dfc75c457198b88986642e602065 upstream. This patch fixes a memory corruption that occurred in the nand_scan() path for Hynix nand device. On boot, for Hynix nand device will panic at a weird place: | Unable to handle kernel NULL pointer dereference at virtual address 00000070 | [00000070] *pgd=00000000 | Internal error: Oops: 5 [#1] PREEMPT SMP ARM | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-01473-g13ae1769cfb0 #38 | Hardware name: Generic DT based system | PC is at nandc_set_reg+0x8/0x1c | LR is at qcom_nandc_command+0x20c/0x5d0 | pc : [] lr : [] psr: 00000113 | sp : c14adc50 ip : c14ee208 fp : c0cc970c | r10: 000000a3 r9 : 00000000 r8 : 00000040 | r7 : c16f6a00 r6 : 00000090 r5 : 00000004 r4 :c14ee040 | r3 : 00000000 r2 : 0000000b r1 : 00000000 r0 :c14ee040 | Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none | Control: 10c5387d Table: 8020406a DAC: 00000051 | Register r0 information: slab kmalloc-2k start c14ee000 pointer offset 64 size 2048 | Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) | nandc_set_reg from qcom_nandc_command+0x20c/0x5d0 | qcom_nandc_command from nand_readid_op+0x198/0x1e8 | nand_readid_op from hynix_nand_has_valid_jedecid+0x30/0x78 | hynix_nand_has_valid_jedecid from hynix_nand_init+0xb8/0x454 | hynix_nand_init from nand_scan_with_ids+0xa30/0x14a8 | nand_scan_with_ids from qcom_nandc_probe+0x648/0x7b0 | qcom_nandc_probe from platform_probe+0x58/0xac The problem is that the nand_scan()'s qcom_nand_attach_chip callback is updating the nandc->max_cwperpage from 1 to 4 or 8 based on page size. This causes the sg_init_table of clear_bam_transaction() in the driver's qcom_nandc_command() to memset much more than what was initially allocated by alloc_bam_transaction(). This patch will update nandc->max_cwperpage 1 to 4 or 8 based on page size in qcom_nand_attach_chip call back after freeing the previously allocated memory for bam txn as per nandc->max_cwperpage = 1 and then again allocating bam txn as per nandc->max_cwperpage = 4 or 8 based on page size in qcom_nand_attach_chip call back itself. Cc: stable@vger.kernel.org Fixes: 6a3cec64f18c ("mtd: rawnand: qcom: convert driver to nand_scan()") Reported-by: Konrad Dybcio Reviewed-by: Manivannan Sadhasivam Co-developed-by: Sricharan R Signed-off-by: Sricharan R Signed-off-by: Md Sadre Alam Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/1650268107-5363-1-git-send-email-quic_mdalam@quicinc.com Signed-off-by: Greg Kroah-Hartman commit 30083f0492042e2150622fed224d7533fdc1cbe7 Author: Zqiang Date: Wed Apr 27 12:41:56 2022 -0700 kasan: prevent cpu_quarantine corruption when CPU offline and cache shrink occur at same time commit 31fa985b4196f8a66f027672e9bf2b81fea0417c upstream. kasan_quarantine_remove_cache() is called in kmem_cache_shrink()/ destroy(). The kasan_quarantine_remove_cache() call is protected by cpuslock in kmem_cache_destroy() to ensure serialization with kasan_cpu_offline(). However the kasan_quarantine_remove_cache() call is not protected by cpuslock in kmem_cache_shrink(). When a CPU is going offline and cache shrink occurs at same time, the cpu_quarantine may be corrupted by interrupt (per_cpu_remove_cache operation). So add a cpu_quarantine offline flags check in per_cpu_remove_cache(). [akpm@linux-foundation.org: add comment, per Zqiang] Link: https://lkml.kernel.org/r/20220414025925.2423818-1-qiang1.zhang@intel.com Signed-off-by: Zqiang Reviewed-by: Dmitry Vyukov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 051e78dc1f97e3af8a5929e9c3ea744633785b1b Author: Damien Le Moal Date: Tue Apr 12 20:52:35 2022 +0900 zonefs: Clear inode information flags on inode creation commit 694852ead287a3433126e7ebda397b242dc99624 upstream. Ensure that the i_flags field of struct zonefs_inode_info is cleared to 0 when initializing a zone file inode, avoiding seeing the flag ZONEFS_ZONE_OPEN being incorrectly set. Fixes: b5c00e975779 ("zonefs: open/close zone on file open/close") Cc: Signed-off-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Reviewed-by: Chaitanya Kulkarni Reviewed-by: Hans Holmberg Signed-off-by: Greg Kroah-Hartman commit 534c3f29acdda03bc0e50f1e6c9526252cb93d07 Author: Damien Le Moal Date: Tue Apr 12 17:41:37 2022 +0900 zonefs: Fix management of open zones commit 1da18a296f5ba4f99429e62a7cf4fdbefa598902 upstream. The mount option "explicit_open" manages the device open zone resources to ensure that if an application opens a sequential file for writing, the file zone can always be written by explicitly opening the zone and accounting for that state with the s_open_zones counter. However, if some zones are already open when mounting, the device open zone resource usage status will be larger than the initial s_open_zones value of 0. Ensure that this inconsistency does not happen by closing any sequential zone that is open when mounting. Furthermore, with ZNS drives, closing an explicitly open zone that has not been written will change the zone state to "closed", that is, the zone will remain in an active state. Since this can then cause failures of explicit open operations on other zones if the drive active zone resources are exceeded, we need to make sure that the zone is not active anymore by resetting it instead of closing it. To address this, zonefs_zone_mgmt() is modified to change a REQ_OP_ZONE_CLOSE request into a REQ_OP_ZONE_RESET for sequential zones that have not been written. Fixes: b5c00e975779 ("zonefs: open/close zone on file open/close") Cc: Signed-off-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Reviewed-by: Hans Holmberg Signed-off-by: Greg Kroah-Hartman commit 746140625a0f6e8b6e16e999618d3236855a668c Author: Ville Syrjälä Date: Wed Apr 20 16:44:17 2022 +0300 Revert "ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40" commit 20e582e16af24b074e583f9551fad557882a3c9d upstream. This reverts commit bfe55a1f7fd6bfede16078bf04c6250fbca11588. This was presumably misdiagnosed as an inability to use C3 at all when I suspect the real problem is just misconfiguration of C3 vs. ARB_DIS. Signed-off-by: Ville Syrjälä Cc: 5.16+ # 5.16+ Tested-by: Woody Suwalski Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2688d967ec65cb6e18b3174d4803f6b7cb863e64 Author: Sidhartha Kumar Date: Thu Apr 21 16:35:52 2022 -0700 selftest/vm: verify remap destination address in mremap_test [ Upstream commit 18d609daa546c919fd36b62a7b510c18de4b4af8 ] Because mremap does not have a MAP_FIXED_NOREPLACE flag, it can destroy existing mappings. This causes a segfault when regions such as text are remapped and the permissions are changed. Verify the requested mremap destination address does not overlap any existing mappings by using mmap's MAP_FIXED_NOREPLACE flag. Keep incrementing the destination address until a valid mapping is found or fail the current test once the max address is reached. Link: https://lkml.kernel.org/r/20220420215721.4868-2-sidhartha.kumar@oracle.com Signed-off-by: Sidhartha Kumar Reviewed-by: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a17404fcbfd0d893f3c111d2af036592ffbc0d42 Author: Sidhartha Kumar Date: Thu Apr 21 16:35:49 2022 -0700 selftest/vm: verify mmap addr in mremap_test [ Upstream commit 9c85a9bae267f6b5e5e374d0d023bbbe9db096d3 ] Avoid calling mmap with requested addresses that are less than the system's mmap_min_addr. When run as root, mmap returns EACCES when trying to map addresses < mmap_min_addr. This is not one of the error codes for the condition to retry the mmap in the test. Rather than arbitrarily retrying on EACCES, don't attempt an mmap until addr > vm.mmap_min_addr. Add a munmap call after an alignment check as the mappings are retained after the retry and can reach the vm.max_map_count sysctl. Link: https://lkml.kernel.org/r/20220420215721.4868-1-sidhartha.kumar@oracle.com Signed-off-by: Sidhartha Kumar Reviewed-by: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c18b69393b4fb47831b4ebe93d8669d47fe777f1 Author: Alexey Kardashevskiy Date: Thu Apr 21 12:57:56 2022 +1000 powerpc/perf: Fix 32bit compile [ Upstream commit bb82c574691daf8f7fa9a160264d15c5804cb769 ] The "read_bhrb" global symbol is only called under CONFIG_PPC64 of arch/powerpc/perf/core-book3s.c but it is compiled for both 32 and 64 bit anyway (and LLVM fails to link this on 32bit). This fixes it by moving bhrb.o to obj64 targets. Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220421025756.571995-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit 9a90c13f72e7ee1cbe8eecc8b1002dabb8f77f2c Author: Duoming Zhou Date: Sun Apr 17 20:55:19 2022 +0800 drivers: net: hippi: Fix deadlock in rr_close() [ Upstream commit bc6de2878429e85c1f1afaa566f7b5abb2243eef ] There is a deadlock in rr_close(), which is shown below: (Thread 1) | (Thread 2) | rr_open() rr_close() | add_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rr_timer() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold rrpriv->lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need rrpriv->lock in position (2) of thread 2. As a result, rr_close() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock. Signed-off-by: Duoming Zhou Link: https://lore.kernel.org/r/20220417125519.82618-1-duoming@zju.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3bb73c4cc265ed824f184505d1bedb554309a144 Author: Ronnie Sahlberg Date: Thu Apr 21 11:15:36 2022 +1000 cifs: destage any unwritten data to the server before calling copychunk_write [ Upstream commit f5d0f921ea362636e4a2efb7c38d1ead373a8700 ] because the copychunk_write might cover a region of the file that has not yet been sent to the server and thus fail. A simple way to reproduce this is: truncate -s 0 /mnt/testfile; strace -f -o x -ttT xfs_io -i -f -c 'pwrite 0k 128k' -c 'fcollapse 16k 24k' /mnt/testfile the issue is that the 'pwrite 0k 128k' becomes rearranged on the wire with the 'fcollapse 16k 24k' due to write-back caching. fcollapse is implemented in cifs.ko as a SMB2 IOCTL(COPYCHUNK_WRITE) call and it will fail serverside since the file is still 0b in size serverside until the writes have been destaged. To avoid this we must ensure that we destage any unwritten data to the server before calling COPYCHUNK_WRITE. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1997373 Reported-by: Xiaoli Feng Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 4640802e1cd497ce23041c44b91a9a68d81ccb8b Author: Mikulas Patocka Date: Tue Apr 19 09:56:23 2022 -0400 x86: __memcpy_flushcache: fix wrong alignment if size > 2^32 [ Upstream commit a6823e4e360fe975bd3da4ab156df7c74c8b07f3 ] The first "if" condition in __memcpy_flushcache is supposed to align the "dest" variable to 8 bytes and copy data up to this alignment. However, this condition may misbehave if "size" is greater than 4GiB. The statement min_t(unsigned, size, ALIGN(dest, 8) - dest); casts both arguments to unsigned int and selects the smaller one. However, the cast truncates high bits in "size" and it results in misbehavior. For example: suppose that size == 0x100000001, dest == 0x200000002 min_t(unsigned, size, ALIGN(dest, 8) - dest) == min_t(0x1, 0xe) == 0x1; ... dest += 0x1; so we copy just one byte "and" dest remains unaligned. This patch fixes the bug by replacing unsigned with size_t. Signed-off-by: Mikulas Patocka Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5bf8eda3815a3d7740a073257d6a32e1a6be47f9 Author: suresh kumar Date: Sat Apr 16 16:44:10 2022 +0530 bonding: do not discard lowest hash bit for non layer3+4 hashing [ Upstream commit 49aefd131739df552f83c566d0665744c30b1d70 ] Commit b5f862180d70 was introduced to discard lowest hash bit for layer3+4 hashing but it also removes last bit from non layer3+4 hashing Below script shows layer2+3 hashing will result in same slave to be used with above commit. $ cat hash.py #/usr/bin/python3.6 h_dests=[0xa0, 0xa1] h_source=0xe3 hproto=0x8 saddr=0x1e7aa8c0 daddr=0x17aa8c0 for h_dest in h_dests: hash = (h_dest ^ h_source ^ hproto ^ saddr ^ daddr) hash ^= hash >> 16 hash ^= hash >> 8 print(hash) print("with last bit removed") for h_dest in h_dests: hash = (h_dest ^ h_source ^ hproto ^ saddr ^ daddr) hash ^= hash >> 16 hash ^= hash >> 8 hash = hash >> 1 print(hash) Output: $ python3.6 hash.py 522133332 522133333 <-------------- will result in both slaves being used with last bit removed 261066666 261066666 <-------------- only single slave used Signed-off-by: suresh kumar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d276bcc5f72e2adbee921d5313c15b790da59ef0 Author: Namjae Jeon Date: Wed Apr 13 10:01:36 2022 +0900 ksmbd: set fixed sector size to FS_SECTOR_SIZE_INFORMATION [ Upstream commit 02655a70b7cc0f534531ee65fa72692f4d31a944 ] Currently ksmbd is using ->f_bsize from vfs_statfs() as sector size. If fat/exfat is a local share, ->f_bsize is a cluster size that is too large to be used as a sector size. Sector sizes larger than 4K cause problem occurs when mounting an iso file through windows client. The error message can be obtained using Mount-DiskImage command, the error is: "Mount-DiskImage : The sector size of the physical disk on which the virtual disk resides is not supported." This patch reports fixed 4KB sector size if ->s_blocksize is bigger than 4KB. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit df30cbfd3d8a70e61ce59f63ce5ed2261799ac10 Author: Namjae Jeon Date: Tue Apr 5 12:04:43 2022 +0900 ksmbd: increment reference count of parent fp [ Upstream commit 8510a043d334ecdf83d4604782f288db6bf21d60 ] Add missing increment reference count of parent fp in ksmbd_lookup_fd_inode(). Signed-off-by: Namjae Jeon Reviewed-by: Hyunchul Lee Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 50f79a2abb6582022b5c079f0101662ee577765c Author: Duoming Zhou Date: Thu Apr 7 23:44:30 2022 +0800 arch: xtensa: platforms: Fix deadlock in rs_close() [ Upstream commit eb5adc70754d26a260f8b42d39db42da0d0af500 ] There is a deadlock in rs_close(), which is shown below: (Thread 1) | (Thread 2) | rs_open() rs_close() | mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rs_poll() del_timer_sync() | spin_lock() //(2) (wait timer to stop) | ... We hold timer_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need timer_lock in position (2) of thread 2. As a result, rs_close() will block forever. This patch deletes the redundant timer_lock in order to prevent the deadlock. Because there is no race condition between rs_close, rs_open and rs_poll. Signed-off-by: Duoming Zhou Message-Id: <20220407154430.22387-1-duoming@zju.edu.cn> Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 52c3a04f9ec2a16a4204d6274db338cb8d5b2d74 Author: Ye Bin Date: Tue Mar 22 09:24:19 2022 +0800 ext4: fix bug_on in start_this_handle during umount filesystem [ Upstream commit b98535d091795a79336f520b0708457aacf55c67 ] We got issue as follows: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:389! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 9 PID: 131 Comm: kworker/9:1 Not tainted 5.17.0-862.14.0.6.x86_64-00001-g23f87daf7d74-dirty #197 Workqueue: events flush_stashed_error_work RIP: 0010:start_this_handle+0x41c/0x1160 RSP: 0018:ffff888106b47c20 EFLAGS: 00010202 RAX: ffffed10251b8400 RBX: ffff888128dc204c RCX: ffffffffb52972ac RDX: 0000000000000200 RSI: 0000000000000004 RDI: ffff888128dc2050 RBP: 0000000000000039 R08: 0000000000000001 R09: ffffed10251b840a R10: ffff888128dc204f R11: ffffed10251b8409 R12: ffff888116d78000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff888128dc2000 FS: 0000000000000000(0000) GS:ffff88839d680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000001620068 CR3: 0000000376c0e000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: jbd2__journal_start+0x38a/0x790 jbd2_journal_start+0x19/0x20 flush_stashed_error_work+0x110/0x2b3 process_one_work+0x688/0x1080 worker_thread+0x8b/0xc50 kthread+0x26f/0x310 ret_from_fork+0x22/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Above issue may happen as follows: umount read procfs error_work ext4_put_super flush_work(&sbi->s_error_work); ext4_mb_seq_groups_show ext4_mb_load_buddy_gfp ext4_mb_init_group ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_validate_block_bitmap ext4_error ext4_handle_error schedule_work(&EXT4_SB(sb)->s_error_work); ext4_unregister_sysfs(sb); jbd2_journal_destroy(sbi->s_journal); journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; flush_stashed_error_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT); To solve this issue, we call 'ext4_unregister_sysfs() before flushing s_error_work in ext4_put_super(). Signed-off-by: Ye Bin Reviewed-by: Jan Kara Reviewed-by: Ritesh Harjani Link: https://lore.kernel.org/r/20220322012419.725457-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit dd2f7fcb2a432d0a468bbf746fbba7fd7f359fb5 Author: Zheyu Ma Date: Tue Apr 5 20:10:38 2022 +0800 ASoC: wm8731: Disable the regulator when probing fails [ Upstream commit 92ccbf17eeacf510cf1eed9c252d9332ca24f02d ] When the driver fails during probing, the driver should disable the regulator, not just handle it in wm8731_hw_init(). The following log reveals it: [ 17.812483] WARNING: CPU: 1 PID: 364 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0 [ 17.815958] RIP: 0010:_regulator_put+0x3ec/0x4e0 [ 17.824467] Call Trace: [ 17.824774] [ 17.825040] regulator_bulk_free+0x82/0xe0 [ 17.825514] devres_release_group+0x319/0x3d0 [ 17.825882] i2c_device_probe+0x766/0x940 [ 17.829198] i2c_register_driver+0xb5/0x130 Signed-off-by: Zheyu Ma Link: https://lore.kernel.org/r/20220405121038.4094051-1-zheyuma97@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2c5ca9bde710305fc3fd7a05f24882d0a2fcca11 Author: Chao Song Date: Wed Apr 6 14:23:41 2022 -0500 ASoC: Intel: soc-acpi: correct device endpoints for max98373 [ Upstream commit 97326be14df7bacc6ba5c62c0556298c27ea0432 ] The left speaker of max98373 uses spk_r_endpoint, and right speaker uses spk_l_endpoint, this is obviously wrong. This patch corrects the endpoints for max98373 codec. Signed-off-by: Chao Song Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220406192341.271465-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 27e724bf7c51c8e2e175951bbe6b662f26646239 Author: Pengcheng Yang Date: Tue Apr 26 18:03:39 2022 +0800 tcp: fix F-RTO may not work correctly when receiving DSACK [ Upstream commit d9157f6806d1499e173770df1f1b234763de5c79 ] Currently DSACK is regarded as a dupack, which may cause F-RTO to incorrectly enter "loss was real" when receiving DSACK. Packetdrill to demonstrate: // Enable F-RTO and TLP 0 `sysctl -q net.ipv4.tcp_frto=2` 0 `sysctl -q net.ipv4.tcp_early_retrans=3` 0 `sysctl -q net.ipv4.tcp_congestion_control=cubic` // Establish a connection +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 // RTT 10ms, RTO 210ms +.1 < S 0:0(0) win 32792 +0 > S. 0:0(0) ack 1 <...> +.01 < . 1:1(0) ack 1 win 257 +0 accept(3, ..., ...) = 4 // Send 2 data segments +0 write(4, ..., 2000) = 2000 +0 > P. 1:2001(2000) ack 1 // TLP +.022 > P. 1001:2001(1000) ack 1 // Continue to send 8 data segments +0 write(4, ..., 10000) = 10000 +0 > P. 2001:10001(8000) ack 1 // RTO +.188 > . 1:1001(1000) ack 1 // The original data is acked and new data is sent(F-RTO step 2.b) +0 < . 1:1(0) ack 2001 win 257 +0 > P. 10001:12001(2000) ack 1 // D-SACK caused by TLP is regarded as a dupack, this results in // the incorrect judgment of "loss was real"(F-RTO step 3.a) +.022 < . 1:1(0) ack 2001 win 257 // Never-retransmitted data(3001:4001) are acked and // expect to switch to open state(F-RTO step 3.b) +0 < . 1:1(0) ack 4001 win 257 +0 %{ assert tcpi_ca_state == 0, tcpi_ca_state }% Fixes: e33099f96d99 ("tcp: implement RFC5682 F-RTO") Signed-off-by: Pengcheng Yang Acked-by: Neal Cardwell Tested-by: Neal Cardwell Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/1650967419-2150-1-git-send-email-yangpc@wangsu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8de15dad3c77c6f17302f91855bd6dc0f80aa113 Author: Dany Madden Date: Wed Apr 27 18:51:46 2022 -0500 Revert "ibmvnic: Add ethtool private flag for driver-defined queue limits" [ Upstream commit aeaf59b78712c7a1827c76f086acff4f586e072f ] This reverts commit 723ad916134784b317b72f3f6cf0f7ba774e5dae When client requests channel or ring size larger than what the server can support the server will cap the request to the supported max. So, the client would not be able to successfully request resources that exceed the server limit. Fixes: 723ad9161347 ("ibmvnic: Add ethtool private flag for driver-defined queue limits") Signed-off-by: Dany Madden Link: https://lore.kernel.org/r/20220427235146.23189-1-drt@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 881c48b61fbbbc7c6d80784a29c9cca1b90d88c9 Author: Leon Romanovsky Date: Wed Apr 27 10:31:52 2022 -0700 ixgbe: ensure IPsec VF<->PF compatibility [ Upstream commit f049efc7f7cd2f3c419f55040928eaefb13b3636 ] The VF driver can forward any IPsec flags and such makes the function is not extendable and prone to backward/forward incompatibility. If new software runs on VF, it won't know that PF configured something completely different as it "knows" only XFRM_OFFLOAD_INBOUND flag. Fixes: eda0333ac293 ("ixgbe: add VF IPsec management") Reviewed-by: Raed Salem Signed-off-by: Leon Romanovsky Reviewed-by: Shannon Nelson Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Link: https://lore.kernel.org/r/20220427173152.443102-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3bc7a1f85d5b9071b20941ff580df57a6c8c507c Author: Timothy Hayes Date: Thu Apr 21 17:52:03 2022 +0100 perf arm-spe: Fix addresses of synthesized SPE events [ Upstream commit 4e13f6706d5aee1a6b835a44f6cf4971a921dcb8 ] This patch corrects a bug whereby synthesized events from SPE samples are missing virtual addresses. Fixes: 54f7815efef7fad9 ("perf arm-spe: Fill address info for samples") Reviewed-by: Leo Yan Signed-off-by: Timothy Hayes Cc: Alexander Shishkin Cc: bpf@vger.kernel.org Cc: Jiri Olsa Cc: John Fastabend Cc: John Garry Cc: KP Singh Cc: Leo Yan Cc: linux-arm-kernel@lists.infradead.org Cc: Mark Rutland Cc: Martin KaFai Lau Cc: Mathieu Poirier Cc: Namhyung Kim Cc: netdev@vger.kernel.org Cc: Song Liu Cc: Will Deacon Cc: Yonghong Song Link: https://lore.kernel.org/r/20220421165205.117662-2-timothy.hayes@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 3591293c19dfe2853ad6790d80557dbf724fb4f9 Author: Andreas Gruenbacher Date: Thu Apr 28 14:51:33 2022 +0200 gfs2: No short reads or writes upon glock contention [ Upstream commit 296abc0d91d8b65d42224dd33452ace14491ad08 ] Commit 00bfe02f4796 ("gfs2: Fix mmap + page fault deadlocks for buffered I/O") changed gfs2_file_read_iter() and gfs2_file_buffered_write() to allow dropping the inode glock while faulting in user buffers. When the lock was dropped, a short result was returned to indicate that the operation was interrupted. As pointed out by Linus (see the link below), this behavior is broken and the operations should always re-acquire the inode glock and resume the operation instead. Link: https://lore.kernel.org/lkml/CAHk-=whaz-g_nOOoo8RRiWNjnv2R+h6_xk2F1J4TuSRxk1MtLw@mail.gmail.com/ Fixes: 00bfe02f4796 ("gfs2: Fix mmap + page fault deadlocks for buffered I/O") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit b5afb477d2f8e1fa87af7d37ab22f6c619a20c63 Author: Andreas Gruenbacher Date: Thu Mar 24 23:13:26 2022 +0100 gfs2: Make sure not to return short direct writes [ Upstream commit 3bde4c48586074202044456285a97ccdf9048988 ] When direct writes fail with -ENOTBLK because we're writing into a hole (gfs2_iomap_begin()) or because of a page invalidation failure (iomap_dio_rw()), we're falling back to buffered writes. In that case, when we lose the inode glock in gfs2_file_buffered_write(), we want to re-acquire it instead of returning a short write. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit fe24959a79c9c036e377adaff44beee81a58d5ff Author: Andreas Gruenbacher Date: Thu Mar 17 14:20:38 2022 +0100 gfs2: Minor retry logic cleanup [ Upstream commit 124c458a401a2497f796e4f2d6cafac6edbea8e9 ] Clean up the retry logic in the read and write functions somewhat. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit e4ea3286b1aa136e478779a791260a8f8d9e77f4 Author: Andreas Gruenbacher Date: Tue Nov 9 13:57:17 2021 +0100 gfs2: Prevent endless loops in gfs2_file_buffered_write [ Upstream commit 554c577cee95bdc1d03d9f457e57dc96eb791845 ] Currently, instead of performing a short write, iomap_file_buffered_write will fail when part of its iov iterator cannot be read. In contrast, gfs2_file_buffered_write will loop around if it can read part of the iov iterator, so we can end up in an endless loop. This should be fixed in iomap_file_buffered_write (and also generic_perform_write), but this comes a bit late in the 5.16 development cycle, so work around it in the filesystem by trimming the iov iterator to the known-good size for now. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit a83ee2d81b34a5c2c4acdc9e5ea05ef6d6f3b5d6 Author: Yang Yingliang Date: Tue Apr 26 20:52:31 2022 +0800 net: fec: add missing of_node_put() in fec_enet_init_stop_mode() [ Upstream commit d2b52ec056d5bddb055c8f21d7489a23548d0838 ] Put device node in error path in fec_enet_init_stop_mode(). Fixes: 8a448bf832af ("net: ethernet: fec: move GPR register offset and bit into DT") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20220426125231.375688-1-yangyingliang@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 925ebcac26e480f15e94cdc6e248d67cc198fb77 Author: Manish Chopra Date: Tue Apr 26 08:39:13 2022 -0700 bnx2x: fix napi API usage sequence [ Upstream commit af68656d66eda219b7f55ce8313a1da0312c79e1 ] While handling PCI errors (AER flow) driver tries to disable NAPI [napi_disable()] after NAPI is deleted [__netif_napi_del()] which causes unexpected system hang/crash. System message log shows the following: ======================================= [ 3222.537510] EEH: Detected PCI bus error on PHB#384-PE#800000 [ 3222.537511] EEH: This PCI device has failed 2 times in the last hour and will be permanently disabled after 5 failures. [ 3222.537512] EEH: Notify device drivers to shutdown [ 3222.537513] EEH: Beginning: 'error_detected(IO frozen)' [ 3222.537514] EEH: PE#800000 (PCI 0384:80:00.0): Invoking bnx2x->error_detected(IO frozen) [ 3222.537516] bnx2x: [bnx2x_io_error_detected:14236(eth14)]IO error detected [ 3222.537650] EEH: PE#800000 (PCI 0384:80:00.0): bnx2x driver reports: 'need reset' [ 3222.537651] EEH: PE#800000 (PCI 0384:80:00.1): Invoking bnx2x->error_detected(IO frozen) [ 3222.537651] bnx2x: [bnx2x_io_error_detected:14236(eth13)]IO error detected [ 3222.537729] EEH: PE#800000 (PCI 0384:80:00.1): bnx2x driver reports: 'need reset' [ 3222.537729] EEH: Finished:'error_detected(IO frozen)' with aggregate recovery state:'need reset' [ 3222.537890] EEH: Collect temporary log [ 3222.583481] EEH: of node=0384:80:00.0 [ 3222.583519] EEH: PCI device/vendor: 168e14e4 [ 3222.583557] EEH: PCI cmd/status register: 00100140 [ 3222.583557] EEH: PCI-E capabilities and status follow: [ 3222.583744] EEH: PCI-E 00: 00020010 012c8da2 00095d5e 00455c82 [ 3222.583892] EEH: PCI-E 10: 10820000 00000000 00000000 00000000 [ 3222.583893] EEH: PCI-E 20: 00000000 [ 3222.583893] EEH: PCI-E AER capability register set follows: [ 3222.584079] EEH: PCI-E AER 00: 13c10001 00000000 00000000 00062030 [ 3222.584230] EEH: PCI-E AER 10: 00002000 000031c0 000001e0 00000000 [ 3222.584378] EEH: PCI-E AER 20: 00000000 00000000 00000000 00000000 [ 3222.584416] EEH: PCI-E AER 30: 00000000 00000000 [ 3222.584416] EEH: of node=0384:80:00.1 [ 3222.584454] EEH: PCI device/vendor: 168e14e4 [ 3222.584491] EEH: PCI cmd/status register: 00100140 [ 3222.584492] EEH: PCI-E capabilities and status follow: [ 3222.584677] EEH: PCI-E 00: 00020010 012c8da2 00095d5e 00455c82 [ 3222.584825] EEH: PCI-E 10: 10820000 00000000 00000000 00000000 [ 3222.584826] EEH: PCI-E 20: 00000000 [ 3222.584826] EEH: PCI-E AER capability register set follows: [ 3222.585011] EEH: PCI-E AER 00: 13c10001 00000000 00000000 00062030 [ 3222.585160] EEH: PCI-E AER 10: 00002000 000031c0 000001e0 00000000 [ 3222.585309] EEH: PCI-E AER 20: 00000000 00000000 00000000 00000000 [ 3222.585347] EEH: PCI-E AER 30: 00000000 00000000 [ 3222.586872] RTAS: event: 5, Type: Platform Error (224), Severity: 2 [ 3222.586873] EEH: Reset without hotplug activity [ 3224.762767] EEH: Beginning: 'slot_reset' [ 3224.762770] EEH: PE#800000 (PCI 0384:80:00.0): Invoking bnx2x->slot_reset() [ 3224.762771] bnx2x: [bnx2x_io_slot_reset:14271(eth14)]IO slot reset initializing... [ 3224.762887] bnx2x 0384:80:00.0: enabling device (0140 -> 0142) [ 3224.768157] bnx2x: [bnx2x_io_slot_reset:14287(eth14)]IO slot reset --> driver unload Uninterruptible tasks ===================== crash> ps | grep UN 213 2 11 c000000004c89e00 UN 0.0 0 0 [eehd] 215 2 0 c000000004c80000 UN 0.0 0 0 [kworker/0:2] 2196 1 28 c000000004504f00 UN 0.1 15936 11136 wickedd 4287 1 9 c00000020d076800 UN 0.0 4032 3008 agetty 4289 1 20 c00000020d056680 UN 0.0 7232 3840 agetty 32423 2 26 c00000020038c580 UN 0.0 0 0 [kworker/26:3] 32871 4241 27 c0000002609ddd00 UN 0.1 18624 11648 sshd 32920 10130 16 c00000027284a100 UN 0.1 48512 12608 sendmail 33092 32987 0 c000000205218b00 UN 0.1 48512 12608 sendmail 33154 4567 16 c000000260e51780 UN 0.1 48832 12864 pickup 33209 4241 36 c000000270cb6500 UN 0.1 18624 11712 sshd 33473 33283 0 c000000205211480 UN 0.1 48512 12672 sendmail 33531 4241 37 c00000023c902780 UN 0.1 18624 11648 sshd EEH handler hung while bnx2x sleeping and holding RTNL lock =========================================================== crash> bt 213 PID: 213 TASK: c000000004c89e00 CPU: 11 COMMAND: "eehd" #0 [c000000004d477e0] __schedule at c000000000c70808 #1 [c000000004d478b0] schedule at c000000000c70ee0 #2 [c000000004d478e0] schedule_timeout at c000000000c76dec #3 [c000000004d479c0] msleep at c0000000002120cc #4 [c000000004d479f0] napi_disable at c000000000a06448 ^^^^^^^^^^^^^^^^ #5 [c000000004d47a30] bnx2x_netif_stop at c0080000018dba94 [bnx2x] #6 [c000000004d47a60] bnx2x_io_slot_reset at c0080000018a551c [bnx2x] #7 [c000000004d47b20] eeh_report_reset at c00000000004c9bc #8 [c000000004d47b90] eeh_pe_report at c00000000004d1a8 #9 [c000000004d47c40] eeh_handle_normal_event at c00000000004da64 And the sleeping source code ============================ crash> dis -ls c000000000a06448 FILE: ../net/core/dev.c LINE: 6702 6697 { 6698 might_sleep(); 6699 set_bit(NAPI_STATE_DISABLE, &n->state); 6700 6701 while (test_and_set_bit(NAPI_STATE_SCHED, &n->state)) * 6702 msleep(1); 6703 while (test_and_set_bit(NAPI_STATE_NPSVC, &n->state)) 6704 msleep(1); 6705 6706 hrtimer_cancel(&n->timer); 6707 6708 clear_bit(NAPI_STATE_DISABLE, &n->state); 6709 } EEH calls into bnx2x twice based on the system log above, first through bnx2x_io_error_detected() and then bnx2x_io_slot_reset(), and executes the following call chains: bnx2x_io_error_detected() +-> bnx2x_eeh_nic_unload() +-> bnx2x_del_all_napi() +-> __netif_napi_del() bnx2x_io_slot_reset() +-> bnx2x_netif_stop() +-> bnx2x_napi_disable() +->napi_disable() Fix this by correcting the sequence of NAPI APIs usage, that is delete the NAPI after disabling it. Fixes: 7fa6f34081f1 ("bnx2x: AER revised") Reported-by: David Christensen Tested-by: David Christensen Signed-off-by: Manish Chopra Signed-off-by: Ariel Elior Link: https://lore.kernel.org/r/20220426153913.6966-1-manishc@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 87fe5a392d2752e9b9846d26786c164d93159a13 Author: Maxim Mikityanskiy Date: Tue Apr 26 18:49:49 2022 +0300 tls: Skip tls_append_frag on zero copy size [ Upstream commit a0df71948e9548de819a6f1da68f5f1742258a52 ] Calling tls_append_frag when max_open_record_len == record->len might add an empty fragment to the TLS record if the call happens to be on the page boundary. Normally tls_append_frag coalesces the zero-sized fragment to the previous one, but not if it's on page boundary. If a resync happens then, the mlx5 driver posts dump WQEs in tx_post_resync_dump, and the empty fragment may become a data segment with byte_count == 0, which will confuse the NIC and lead to a CQE error. This commit fixes the described issue by skipping tls_append_frag on zero size to avoid adding empty fragments. The fix is not in the driver, because an empty fragment is hardly the desired behavior. Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Link: https://lore.kernel.org/r/20220426154949.159055-1-maximmi@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 815b847af99d8b78131174fa1c32da0195c70e4c Author: Miaoqian Lin Date: Thu Apr 21 17:03:09 2022 +0800 drm/amd/display: Fix memory leak in dcn21_clock_source_create [ Upstream commit 65e54987508b6f0771f56bdfa3ee1926d52785ae ] When dcn20_clk_src_construct() fails, we need to release clk_src. Fixes: 6f4e6361c3ff ("drm/amd/display: Add Renoir resource (v2)") Signed-off-by: Miaoqian Lin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ce9be3baec9b58b3f6e4c721e6498ecfc37e5834 Author: David Yat Sin Date: Mon Apr 18 11:55:58 2022 -0400 drm/amdkfd: Fix GWS queue count [ Upstream commit 7c6b6e18c890f30965b0589b0a57645e1dbccfde ] dqm->gws_queue_count and pdd->qpd.mapped_gws_queue need to be updated each time the queue gets evicted. Fixes: b8020b0304c8 ("drm/amdkfd: Enable over-subscription with >1 GWS queue") Signed-off-by: David Yat Sin Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 54e0b949bf590a644cb6f7600912e6d5902f0ad3 Author: Volodymyr Mytnyk Date: Wed Apr 27 14:09:00 2022 +0300 netfilter: conntrack: fix udp offload timeout sysctl [ Upstream commit 626873c446f7559d5af8b48cefad903ffd85cf4e ] `nf_flowtable_udp_timeout` sysctl option is available only if CONFIG_NFT_FLOW_OFFLOAD enabled. But infra for this flow offload UDP timeout was added under CONFIG_NF_FLOW_TABLE config option. So, if you have CONFIG_NFT_FLOW_OFFLOAD disabled and CONFIG_NF_FLOW_TABLE enabled, the `nf_flowtable_udp_timeout` is not present in sysfs. Please note, that TCP flow offload timeout sysctl option is present even CONFIG_NFT_FLOW_OFFLOAD is disabled. I suppose it was a typo in commit that adds UDP flow offload timeout and CONFIG_NF_FLOW_TABLE should be used instead. Fixes: 975c57504da1 ("netfilter: conntrack: Introduce udp offload timeout configuration") Signed-off-by: Volodymyr Mytnyk Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 37811e46a2329f844cc78d817492586ed7b3598b Author: Jens Axboe Date: Tue Apr 26 19:34:57 2022 -0600 io_uring: check reserved fields for recv/recvmsg [ Upstream commit 5a1e99b61b0c81388cde0c808b3e4173907df19f ] We should check unused fields for non-zero and -EINVAL if they are set, making it consistent with other opcodes. Fixes: aa1fa28fc73e ("io_uring: add support for recvmsg()") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 79c10cb188155196db99bfb1c51ee67f8c587908 Author: Jens Axboe Date: Tue Apr 26 19:34:11 2022 -0600 io_uring: check reserved fields for send/sendmsg [ Upstream commit 588faa1ea5eecb351100ee5d187b9be99210f70d ] We should check unused fields for non-zero and -EINVAL if they are set, making it consistent with other opcodes. Fixes: 0fa03c624d8f ("io_uring: add support for sendmsg()") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ee6d708520b784a97240560d9534210045af4c93 Author: Martin Blumenstingl Date: Mon Apr 25 17:20:27 2022 +0200 net: dsa: lantiq_gswip: Don't set GSWIP_MII_CFG_RMII_CLK [ Upstream commit 71cffebf6358a7f5031f5b208bbdc1cb4db6e539 ] Commit 4b5923249b8fa4 ("net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits") added all known bits in the GSWIP_MII_CFGp register. It helped bring this register into a well-defined state so the driver has to rely less on the bootloader to do things right. Unfortunately it also sets the GSWIP_MII_CFG_RMII_CLK bit without any possibility to configure it. Upon further testing it turns out that all boards which are supported by the GSWIP driver in OpenWrt which use an RMII PHY have a dedicated oscillator on the board which provides the 50MHz RMII reference clock. Don't set the GSWIP_MII_CFG_RMII_CLK bit (but keep the code which always clears it) to fix support for the Fritz!Box 7362 SL in OpenWrt. This is a board with two Atheros AR8030 RMII PHYs. With the "RMII clock" bit set the MAC also generates the RMII reference clock whose signal then conflicts with the signal from the oscillator on the board. This results in a constant cycle of the PHY detecting link up/down (and as a result of that: the two ports using the AR8030 PHYs are not working). At the time of writing this patch there's no known board where the MAC (GSWIP) has to generate the RMII reference clock. If needed this can be implemented in future by providing a device-tree flag so the GSWIP_MII_CFG_RMII_CLK bit can be toggled per port. Fixes: 4b5923249b8fa4 ("net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits") Tested-by: Jan Hoffmann Signed-off-by: Martin Blumenstingl Acked-by: Hauke Mehrtens Link: https://lore.kernel.org/r/20220425152027.2220750-1-martin.blumenstingl@googlemail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8a991ba5ddde4fa6190ceb6f8585e4c934d40dc8 Author: Samuel Holland Date: Sun Apr 24 11:26:21 2022 -0500 drm/sun4i: Remove obsolete references to PHYS_OFFSET [ Upstream commit dc3ae06c5f2170d879ff58696f629d8c3868aec3 ] commit b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a central place") added a platform device notifier that sets the DMA offset for all of the display engine frontend and backend devices. The code applying the offset to DMA buffer physical addresses was then removed from the backend driver in commit 756668ba682e ("drm/sun4i: backend: Remove the MBUS quirks"), but the code subtracting PHYS_OFFSET was left in the frontend driver. As a result, the offset was applied twice in the frontend driver. This likely went unnoticed because it only affects specific configurations (scaling or certain pixel formats) where the frontend is used, on boards with both one of these older SoCs and more than 1 GB of DRAM. In addition, the references to PHYS_OFFSET prevent compiling the driver on architectures where PHYS_OFFSET is not defined. Fixes: b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a central place") Reviewed-by: Jernej Skrabec Signed-off-by: Samuel Holland Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-4-samuel@sholland.org Signed-off-by: Sasha Levin commit ede22fc0bf7ef85d004adc14cca015771aa0b6fb Author: Nathan Rossi Date: Mon Apr 25 07:04:54 2022 +0000 net: dsa: mv88e6xxx: Fix port_hidden_wait to account for port_base_addr [ Upstream commit 24cbdb910bb62b5be3865275e5682be1a7708c0f ] The other port_hidden functions rely on the port_read/port_write functions to access the hidden control port. These functions apply the offset for port_base_addr where applicable. Update port_hidden_wait to use the port_wait_bit so that port_base_addr offsets are accounted for when waiting for the busy bit to change. Without the offset the port_hidden_wait function would timeout on devices that have a non-zero port_base_addr (e.g. MV88E6141), however devices that have a zero port_base_addr would operate correctly (e.g. MV88E6390). Fixes: 609070133aff ("net: dsa: mv88e6xxx: update code operating on hidden registers") Signed-off-by: Nathan Rossi Reviewed-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220425070454.348584-1-nathan@nathanrossi.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9b649f4c56720bf475cab4e0d555b234e50f3a54 Author: Baruch Siach Date: Mon Apr 25 09:27:38 2022 +0300 net: phy: marvell10g: fix return value on error [ Upstream commit 0ed9704b660b259b54743cad8a84a11148f60f0a ] Return back the error value that we get from phy_read_mmd(). Fixes: c84786fa8f91 ("net: phy: marvell10g: read copper results from CSSR1") Signed-off-by: Baruch Siach Reviewed-by: Marek Behún Reviewed-by: Russell King (Oracle) Link: https://lore.kernel.org/r/f47cb031aeae873bb008ba35001607304a171a20.1650868058.git.baruch@tkos.co.il Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 21bf1dc99db49945d56197cfa392a3c741425ea3 Author: Jonathan Lemon Date: Sun Apr 24 09:53:07 2022 -0700 net: bcmgenet: hide status block before TX timestamping [ Upstream commit acac0541d1d65e81e599ec399d34d184d2424401 ] The hardware checksum offloading requires use of a transmit status block inserted before the outgoing frame data, this was updated in '9a9ba2a4aaaa ("net: bcmgenet: always enable status blocks")' However, skb_tx_timestamp() assumes that it is passed a raw frame and PTP parsing chokes on this status block. Fix this by calling __skb_pull(), which hides the TSB before calling skb_tx_timestamp(), so an outgoing PTP packet is parsed correctly. As the data in the skb has already been set up for DMA, and the dma_unmap_* calls use a separately stored address, there is no no effective change in the data transmission. Signed-off-by: Jonathan Lemon Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20220424165307.591145-1-jonathan.lemon@gmail.com Fixes: d03825fba459 ("net: bcmgenet: add skb_tx_timestamp call") Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit abff341ac2f9177a2045a9d12af41a54f678c67f Author: Vladimir Zapolskiy Date: Thu Apr 7 23:09:19 2022 +0300 cpufreq: qcom-cpufreq-hw: Clear dcvs interrupts [ Upstream commit e4e6448638a01905faeda9bf96aa9df7c8ef463c ] It's noted that dcvs interrupts are not self-clearing, thus an interrupt handler runs constantly, which leads to a severe regression in runtime. To fix the problem an explicit write to clear interrupt register is required, note that on OSM platforms the register may not be present. Fixes: 275157b367f4 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Signed-off-by: Vladimir Zapolskiy Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 7356c1f0ae47f61a6d92b7b2732f50dabfb0830a Author: Yang Yingliang Date: Thu Apr 21 21:43:08 2022 +0800 clk: sunxi: sun9i-mmc: check return value after calling platform_get_resource() [ Upstream commit f58ca215cda1975f77b2b762903684a3c101bec9 ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Fixes: 7a6fca879f59 ("clk: sunxi: Add driver for A80 MMC config clocks/resets") Signed-off-by: Yang Yingliang Reviewed-by: Samuel Holland Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220421134308.2885094-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 409789e2cec54cb06fb319250fc2be597a04cf42 Author: Christophe JAILLET Date: Thu Apr 21 16:35:49 2022 +0200 bus: sunxi-rsb: Fix the return value of sunxi_rsb_device_create() [ Upstream commit fff8c10368e64e7f8960f149375c12ca5f3b30af ] This code is really spurious. It always returns an ERR_PTR, even when err is known to be 0 and calls put_device() after a successful device_register() call. It is likely that the return statement in the normal path is missing. Add 'return rdev;' to fix it. Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus") Signed-off-by: Christophe JAILLET Reviewed-by: Samuel Holland Tested-by: Samuel Holland Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/ef2b9576350bba4c8e05e669e9535e9e2a415763.1650551719.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 45b7fca32bbccaac064eb57fa216e1ce5d61959c Author: Eric Dumazet Date: Sun Apr 24 13:35:09 2022 -0700 tcp: make sure treq->af_specific is initialized [ Upstream commit ba5a4fdd63ae0c575707030db0b634b160baddd7 ] syzbot complained about a recent change in TCP stack, hitting a NULL pointer [1] tcp request sockets have an af_specific pointer, which was used before the blamed change only for SYNACK generation in non SYNCOOKIE mode. tcp requests sockets momentarily created when third packet coming from client in SYNCOOKIE mode were not using treq->af_specific. Make sure this field is populated, in the same way normal TCP requests sockets do in tcp_conn_request(). [1] TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending cookies. Check SNMP counters. general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 3695 Comm: syz-executor864 Not tainted 5.18.0-rc3-syzkaller-00224-g5fd1fe4807f9 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tcp_create_openreq_child+0xe16/0x16b0 net/ipv4/tcp_minisocks.c:534 Code: 48 c1 ea 03 80 3c 02 00 0f 85 e5 07 00 00 4c 8b b3 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7e 08 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c9 07 00 00 48 8b 3c 24 48 89 de 41 ff 56 08 48 RSP: 0018:ffffc90000de0588 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888076490330 RCX: 0000000000000100 RDX: 0000000000000001 RSI: ffffffff87d67ff0 RDI: 0000000000000008 RBP: ffff88806ee1c7f8 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff87d67f00 R11: 0000000000000000 R12: ffff88806ee1bfc0 R13: ffff88801b0e0368 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f517fe58700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcead76960 CR3: 000000006f97b000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tcp_v6_syn_recv_sock+0x199/0x23b0 net/ipv6/tcp_ipv6.c:1267 tcp_get_cookie_sock+0xc9/0x850 net/ipv4/syncookies.c:207 cookie_v6_check+0x15c3/0x2340 net/ipv6/syncookies.c:258 tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1131 [inline] tcp_v6_do_rcv+0x1148/0x13b0 net/ipv6/tcp_ipv6.c:1486 tcp_v6_rcv+0x3305/0x3840 net/ipv6/tcp_ipv6.c:1725 ip6_protocol_deliver_rcu+0x2e9/0x1900 net/ipv6/ip6_input.c:422 ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:464 NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:473 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ipv6_rcv+0x27f/0x3b0 net/ipv6/ip6_input.c:297 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5405 __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5519 process_backlog+0x3a0/0x7c0 net/core/dev.c:5847 __napi_poll+0xb3/0x6e0 net/core/dev.c:6413 napi_poll net/core/dev.c:6480 [inline] net_rx_action+0x8ec/0xc60 net/core/dev.c:6567 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 invoke_softirq kernel/softirq.c:432 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:637 irq_exit_rcu+0x5/0x20 kernel/softirq.c:649 sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1097 Fixes: 5b0b9e4c2c89 ("tcp: md5: incorrect tcp_header_len for incoming connections") Signed-off-by: Eric Dumazet Cc: Francesco Ruggeri Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6c4d4334e573fbcaf717ccf676963c8f8262365d Author: Eric Dumazet Date: Sun Apr 24 17:34:07 2022 -0700 tcp: fix potential xmit stalls caused by TCP_NOTSENT_LOWAT [ Upstream commit 4bfe744ff1644fbc0a991a2677dc874475dd6776 ] I had this bug sitting for too long in my pile, it is time to fix it. Thanks to Doug Porter for reminding me of it! We had various attempts in the past, including commit 0cbe6a8f089e ("tcp: remove SOCK_QUEUE_SHRUNK"), but the issue is that TCP stack currently only generates EPOLLOUT from input path, when tp->snd_una has advanced and skb(s) cleaned from rtx queue. If a flow has a big RTT, and/or receives SACKs, it is possible that the notsent part (tp->write_seq - tp->snd_nxt) reaches 0 and no more data can be sent until tp->snd_una finally advances. What is needed is to also check if POLLOUT needs to be generated whenever tp->snd_nxt is advanced, from output path. This bug triggers more often after an idle period, as we do not receive ACK for at least one RTT. tcp_notsent_lowat could be a fraction of what CWND and pacing rate would allow to send during this RTT. In a followup patch, I will remove the bogus call to tcp_chrono_stop(sk, TCP_CHRONO_SNDBUF_LIMITED) from tcp_check_space(). Fact that we have decided to generate an EPOLLOUT does not mean the application has immediately refilled the transmit queue. This optimistic call might have been the reason the bug seemed not too serious. Tested: 200 ms rtt, 1% packet loss, 32 MB tcp_rmem[2] and tcp_wmem[2] $ echo 500000 >/proc/sys/net/ipv4/tcp_notsent_lowat $ cat bench_rr.sh SUM=0 for i in {1..10} do V=`netperf -H remote_host -l30 -t TCP_RR -- -r 10000000,10000 -o LOCAL_BYTES_SENT | egrep -v "MIGRATED|Bytes"` echo $V SUM=$(($SUM + $V)) done echo SUM=$SUM Before patch: $ bench_rr.sh 130000000 80000000 140000000 140000000 140000000 140000000 130000000 40000000 90000000 110000000 SUM=1140000000 After patch: $ bench_rr.sh 430000000 590000000 530000000 450000000 450000000 350000000 450000000 490000000 480000000 460000000 SUM=4680000000 # This is 410 % of the value before patch. Fixes: c9bee3b7fdec ("tcp: TCP_NOTSENT_LOWAT socket option") Signed-off-by: Eric Dumazet Reported-by: Doug Porter Cc: Soheil Hassas Yeganeh Cc: Neal Cardwell Acked-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6b59df7d4d0a132df7b549a165f01c586f50e4d8 Author: Peilin Ye Date: Thu Apr 21 15:09:02 2022 -0700 ip_gre, ip6_gre: Fix race condition on o_seqno in collect_md mode [ Upstream commit 31c417c948d7f6909cb63f0ac3298f3c38f8ce20 ] As pointed out by Jakub Kicinski, currently using TUNNEL_SEQ in collect_md mode is racy for [IP6]GRE[TAP] devices. Consider the following sequence of events: 1. An [IP6]GRE[TAP] device is created in collect_md mode using "ip link add ... external". "ip" ignores "[o]seq" if "external" is specified, so TUNNEL_SEQ is off, and the device is marked as NETIF_F_LLTX (i.e. it uses lockless TX); 2. Someone sets TUNNEL_SEQ on outgoing skb's, using e.g. bpf_skb_set_tunnel_key() in an eBPF program attached to this device; 3. gre_fb_xmit() or __gre6_xmit() processes these skb's: gre_build_header(skb, tun_hlen, flags, protocol, tunnel_id_to_key32(tun_info->key.tun_id), (flags & TUNNEL_SEQ) ? htonl(tunnel->o_seqno++) : 0); ^^^^^^^^^^^^^^^^^ Since we are not using the TX lock (&txq->_xmit_lock), multiple CPUs may try to do this tunnel->o_seqno++ in parallel, which is racy. Fix it by making o_seqno atomic_t. As mentioned by Eric Dumazet in commit b790e01aee74 ("ip_gre: lockless xmit"), making o_seqno atomic_t increases "chance for packets being out of order at receiver" when NETIF_F_LLTX is on. Maybe a better fix would be: 1. Do not ignore "oseq" in external mode. Users MUST specify "oseq" if they want the kernel to allow sequencing of outgoing packets; 2. Reject all outgoing TUNNEL_SEQ packets if the device was not created with "oseq". Unfortunately, that would break userspace. We could now make [IP6]GRE[TAP] devices always NETIF_F_LLTX, but let us do it in separate patches to keep this fix minimal. Suggested-by: Jakub Kicinski Fixes: 77a5196a804e ("gre: add sequence number for collect md mode.") Signed-off-by: Peilin Ye Acked-by: William Tu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e5e985dd99d85ffa8a8758cd1db31e02421f009f Author: Peilin Ye Date: Thu Apr 21 15:08:38 2022 -0700 ip6_gre: Make o_seqno start from 0 in native mode [ Upstream commit fde98ae91f79cab4e020f40c35ed23cbdc59661c ] For IP6GRE and IP6GRETAP devices, currently o_seqno starts from 1 in native mode. According to RFC 2890 2.2., "The first datagram is sent with a sequence number of 0." Fix it. It is worth mentioning that o_seqno already starts from 0 in collect_md mode, see the "if (tunnel->parms.collect_md)" clause in __gre6_xmit(), where tunnel->o_seqno is passed to gre_build_header() before getting incremented. Fixes: c12b395a4664 ("gre: Support GRE over IPv6") Signed-off-by: Peilin Ye Acked-by: William Tu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2dec240fb161d82698731209281c5acbd4cdeb65 Author: Peilin Ye Date: Thu Apr 21 15:07:57 2022 -0700 ip_gre: Make o_seqno start from 0 in native mode [ Upstream commit ff827beb706ed719c766acf36449801ded0c17fc ] For GRE and GRETAP devices, currently o_seqno starts from 1 in native mode. According to RFC 2890 2.2., "The first datagram is sent with a sequence number of 0." Fix it. It is worth mentioning that o_seqno already starts from 0 in collect_md mode, see gre_fb_xmit(), where tunnel->o_seqno is passed to gre_build_header() before getting incremented. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Peilin Ye Acked-by: William Tu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 479dc5d15316f431b1f4416ff737b21d8d3edfb1 Author: liuyacan Date: Thu Apr 21 17:40:27 2022 +0800 net/smc: sync err code when tcp connection was refused [ Upstream commit 4e2e65e2e56c6ceb4ea1719360080c0af083229e ] In the current implementation, when TCP initiates a connection to an unavailable [ip,port], ECONNREFUSED will be stored in the TCP socket, but SMC will not. However, some apps (like curl) use getsockopt(,,SO_ERROR,,) to get the error information, which makes them miss the error message and behave strangely. Fixes: 50717a37db03 ("net/smc: nonblocking connect rework") Signed-off-by: liuyacan Reviewed-by: Tony Lu Acked-by: Karsten Graul Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c59a61ffb118165b76b53788aa4cfb1b91504ec Author: Jian Shen Date: Sun Apr 24 20:57:25 2022 +0800 net: hns3: add return value for mailbox handling in PF [ Upstream commit c59d606296842409a6e5a4828235b0bd46b12bc4 ] Currently, there are some querying mailboxes sent from VF to PF, and VF will wait the PF's handling result. For mailbox HCLGE_MBX_GET_QID_IN_PF and HCLGE_MBX_GET_RSS_KEY, it may fail when the input parameter is invalid, but the prototype of their handler function is void. In this case, PF always return success to VF, which may cause the VF get incorrect result. Fixes it by adding return value for these function. Fixes: 63b1279d9905 ("net: hns3: check queue id range before using") Fixes: 532cfc0df1e4 ("net: hns3: add a check for index in hclge_get_rss_key()") Signed-off-by: Jian Shen Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fc480b465ab613dca79d15a95420105c739ac1ea Author: Jian Shen Date: Sun Apr 24 20:57:24 2022 +0800 net: hns3: add validity check for message data length [ Upstream commit 7d413735cb18ff73aaba3457b16b08332e8d3cc4 ] Add validity check for message data length in function hclge_send_mbx_msg(), avoid unexpected overflow. Fixes: dde1a86e93ca ("net: hns3: Add mailbox support to PF driver") Signed-off-by: Jian Shen Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cfedc70d3c63fff1b001d5ce78a1dda86c55215a Author: Jie Wang Date: Sun Apr 24 20:57:23 2022 +0800 net: hns3: modify the return code of hclge_get_ring_chain_from_mbx [ Upstream commit 48009e9972974c52a5f649f761862dd67bce3d13 ] Currently, function hclge_get_ring_chain_from_mbx will return -ENOMEM if ring_num is bigger than HCLGE_MBX_MAX_RING_CHAIN_PARAM_NUM. It is better to return -EINVAL for the invalid parameter case. So this patch fixes it by return -EINVAL in this abnormal branch. Fixes: 5d02a58dae60 ("net: hns3: fix for buffer overflow smatch warning") Signed-off-by: Jie Wang Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 88c39408187ce118158c6e5e981439578c1d8e1e Author: Jian Shen Date: Sun Apr 24 20:57:20 2022 +0800 net: hns3: clear inited state and stop client after failed to register netdev [ Upstream commit e98365afc1e94ea1609268866a44112b3572c58b ] If failed to register netdev, it needs to clear INITED state and stop client in case of cause problem when concurrency with uninitialized process of driver. Fixes: a289a7e5c1d4 ("net: hns3: put off calling register_netdev() until client initialize complete") Signed-off-by: Jian Shen Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ac01adfa7d6d0d739bc93d88400227b8353375b5 Author: Xiaobing Luo Date: Sat Apr 23 15:12:04 2022 +0000 cpufreq: fix memory leak in sun50i_cpufreq_nvmem_probe [ Upstream commit 1aa24a8f3b5133dae4bc1e57427e345445f3e902 ] -------------------------------------------- unreferenced object 0xffff000010742a00 (size 128): comm "swapper/0", pid 1, jiffies 4294902015 (age 1187.652s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000b4dfebaa>] __kmalloc+0x338/0x474 [<00000000d6e716db>] sun50i_cpufreq_nvmem_probe+0xc4/0x36c [<000000007d6082a0>] platform_probe+0x98/0x11c [<00000000c990f549>] really_probe+0x234/0x5a0 [<000000002d9fecc6>] __driver_probe_device+0x194/0x224 [<00000000cf0b94fa>] driver_probe_device+0x64/0x13c [<00000000f238e4cf>] __device_attach_driver+0xf8/0x180 [<000000006720e418>] bus_for_each_drv+0xf8/0x160 [<00000000df4f14f6>] __device_attach+0x174/0x29c [<00000000782002fb>] device_initial_probe+0x20/0x30 [<00000000c2681b06>] bus_probe_device+0xfc/0x110 [<00000000964cf3bd>] device_add+0x5f0/0xcd0 [<000000004b9264e3>] platform_device_add+0x198/0x390 [<00000000fa82a9d0>] platform_device_register_full+0x178/0x210 [<000000009a5daf13>] sun50i_cpufreq_init+0xf8/0x168 [<000000000377cc7c>] do_one_initcall+0xe4/0x570 -------------------------------------------- if sun50i_cpufreq_get_efuse failed, then opp_tables leak. Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver") Signed-off-by: Xiaobing Luo Reviewed-by: Samuel Holland Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit cdc350a769251c27883b2e14bfd30d9f469fa9a3 Author: Lv Ruyi Date: Sun Apr 24 03:14:30 2022 +0000 pinctrl: pistachio: fix use of irq_of_parse_and_map() [ Upstream commit 0c9843a74a85224a89daa81fa66891dae2f930e1 ] The irq_of_parse_and_map() function returns 0 on failure, and does not return an negative value. Fixes: cefc03e5995e ("pinctrl: Add Pistachio SoC pin control driver") Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Link: https://lore.kernel.org/r/20220424031430.3170759-1-lv.ruyi@zte.com.cn Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 111827dfea31e7d112963841ea40dedb8d7e9039 Author: Fabio Estevam Date: Mon Apr 18 14:47:31 2022 -0300 arm64: dts: imx8mn-ddr4-evk: Describe the 32.768 kHz PMIC clock [ Upstream commit 0310b5aa0656a94102344f1e9ae2892e342a665d ] The ROHM BD71847 PMIC has a 32.768 kHz clock. Describe the PMIC clock to fix the following boot errors: bd718xx-clk bd71847-clk.1.auto: No parent clk found bd718xx-clk: probe of bd71847-clk.1.auto failed with error -22 Based on the same fix done for imx8mm-evk as per commit a6a355ede574 ("arm64: dts: imx8mm-evk: Add 32.768 kHz clock to PMIC") Fixes: 3e44dd09736d ("arm64: dts: imx8mn-ddr4-evk: Add rohm,bd71847 PMIC support") Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a621f6ce1fb362db30f5286630a7ade8910d9dc9 Author: Max Krummenacher Date: Thu Apr 14 10:50:54 2022 +0200 ARM: dts: imx6ull-colibri: fix vqmmc regulator [ Upstream commit 45974e4276a8d6653394f66666fc57d8ffa6de9a ] The correct spelling for the property is gpios. Otherwise, the regulator will neither reserve nor control any GPIOs. Thus, any SD/MMC card which can use UHS-I modes will fail. Fixes: c2e4987e0e02 ("ARM: dts: imx6ull: add Toradex Colibri iMX6ULL support") Signed-off-by: Max Krummenacher Signed-off-by: Denys Drozdov Signed-off-by: Marcel Ziswiler Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5a4da2e23351c4c1a175310123fbdc34e831cee9 Author: Xin Long Date: Wed Apr 20 16:52:41 2022 -0400 sctp: check asoc strreset_chunk in sctp_generate_reconf_event [ Upstream commit 165e3e17fe8fe6a8aab319bc6e631a2e23b9a857 ] A null pointer reference issue can be triggered when the response of a stream reconf request arrives after the timer is triggered, such as: send Incoming SSN Reset Request ---> CPU0: reconf timer is triggered, go to the handler code before hold sk lock <--- reply with Outgoing SSN Reset Request CPU1: process Outgoing SSN Reset Request, and set asoc->strreset_chunk to NULL CPU0: continue the handler code, hold sk lock, and try to hold asoc->strreset_chunk, crash! In Ying Xu's testing, the call trace is: [ ] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ ] RIP: 0010:sctp_chunk_hold+0xe/0x40 [sctp] [ ] Call Trace: [ ] [ ] sctp_sf_send_reconf+0x2c/0x100 [sctp] [ ] sctp_do_sm+0xa4/0x220 [sctp] [ ] sctp_generate_reconf_event+0xbd/0xe0 [sctp] [ ] call_timer_fn+0x26/0x130 This patch is to fix it by returning from the timer handler if asoc strreset_chunk is already set to NULL. Fixes: 7b9438de0cd4 ("sctp: add stream reconf timer") Reported-by: Ying Xu Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 37a04788c5733271a0854734934c3a58498ea62f Author: Nikolay Aleksandrov Date: Thu Apr 21 15:48:05 2022 +0200 wireguard: device: check for metadata_dst with skb_valid_dst() [ Upstream commit 45ac774c33d834fe9d4de06ab5f1022fe8cd2071 ] When we try to transmit an skb with md_dst attached through wireguard we hit a null pointer dereference in wg_xmit() due to the use of dst_mtu() which calls into dst_blackhole_mtu() which in turn tries to dereference dst->dev. Since wireguard doesn't use md_dsts we should use skb_valid_dst(), which checks for DST_METADATA flag, and if it's set, then falls back to wireguard's device mtu. That gives us the best chance of transmitting the packet; otherwise if the blackhole netdev is used we'd get ETH_MIN_MTU. [ 263.693506] BUG: kernel NULL pointer dereference, address: 00000000000000e0 [ 263.693908] #PF: supervisor read access in kernel mode [ 263.694174] #PF: error_code(0x0000) - not-present page [ 263.694424] PGD 0 P4D 0 [ 263.694653] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 263.694876] CPU: 5 PID: 951 Comm: mausezahn Kdump: loaded Not tainted 5.18.0-rc1+ #522 [ 263.695190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014 [ 263.695529] RIP: 0010:dst_blackhole_mtu+0x17/0x20 [ 263.695770] Code: 00 00 00 0f 1f 44 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 10 48 83 e0 fc 8b 40 04 85 c0 75 09 48 8b 07 <8b> 80 e0 00 00 00 c3 66 90 0f 1f 44 00 00 48 89 d7 be 01 00 00 00 [ 263.696339] RSP: 0018:ffffa4a4422fbb28 EFLAGS: 00010246 [ 263.696600] RAX: 0000000000000000 RBX: ffff8ac9c3553000 RCX: 0000000000000000 [ 263.696891] RDX: 0000000000000401 RSI: 00000000fffffe01 RDI: ffffc4a43fb48900 [ 263.697178] RBP: ffffa4a4422fbb90 R08: ffffffff9622635e R09: 0000000000000002 [ 263.697469] R10: ffffffff9b69a6c0 R11: ffffa4a4422fbd0c R12: ffff8ac9d18b1a00 [ 263.697766] R13: ffff8ac9d0ce1840 R14: ffff8ac9d18b1a00 R15: ffff8ac9c3553000 [ 263.698054] FS: 00007f3704c337c0(0000) GS:ffff8acaebf40000(0000) knlGS:0000000000000000 [ 263.698470] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 263.698826] CR2: 00000000000000e0 CR3: 0000000117a5c000 CR4: 00000000000006e0 [ 263.699214] Call Trace: [ 263.699505] [ 263.699759] wg_xmit+0x411/0x450 [ 263.700059] ? bpf_skb_set_tunnel_key+0x46/0x2d0 [ 263.700382] ? dev_queue_xmit_nit+0x31/0x2b0 [ 263.700719] dev_hard_start_xmit+0xd9/0x220 [ 263.701047] __dev_queue_xmit+0x8b9/0xd30 [ 263.701344] __bpf_redirect+0x1a4/0x380 [ 263.701664] __dev_queue_xmit+0x83b/0xd30 [ 263.701961] ? packet_parse_headers+0xb4/0xf0 [ 263.702275] packet_sendmsg+0x9a8/0x16a0 [ 263.702596] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 263.702933] sock_sendmsg+0x5e/0x60 [ 263.703239] __sys_sendto+0xf0/0x160 [ 263.703549] __x64_sys_sendto+0x20/0x30 [ 263.703853] do_syscall_64+0x3b/0x90 [ 263.704162] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 263.704494] RIP: 0033:0x7f3704d50506 [ 263.704789] Code: 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89 [ 263.705652] RSP: 002b:00007ffe954b0b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 263.706141] RAX: ffffffffffffffda RBX: 0000558bb259b490 RCX: 00007f3704d50506 [ 263.706544] RDX: 000000000000004a RSI: 0000558bb259b7b2 RDI: 0000000000000003 [ 263.706952] RBP: 0000000000000000 R08: 00007ffe954b0b90 R09: 0000000000000014 [ 263.707339] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe954b0b90 [ 263.707735] R13: 000000000000004a R14: 0000558bb259b7b2 R15: 0000000000000001 [ 263.708132] [ 263.708398] Modules linked in: bridge netconsole bonding [last unloaded: bridge] [ 263.708942] CR2: 00000000000000e0 Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Link: https://github.com/cilium/cilium/issues/19428 Reported-by: Martynas Pumputis Signed-off-by: Nikolay Aleksandrov Acked-by: Daniel Borkmann Signed-off-by: Jason A. Donenfeld Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d632cba7dee7944f7fee74ce2e46895579b60154 Author: Pengcheng Yang Date: Wed Apr 20 10:34:41 2022 +0800 tcp: ensure to use the most recently sent skb when filling the rate sample [ Upstream commit b253a0680ceadc5d7b4acca7aa2d870326cad8ad ] If an ACK (s)acks multiple skbs, we favor the information from the most recently sent skb by choosing the skb with the highest prior_delivered count. But in the interval between receiving ACKs, we send multiple skbs with the same prior_delivered, because the tp->delivered only changes when we receive an ACK. We used RACK's solution, copying tcp_rack_sent_after() as tcp_skb_sent_after() helper to determine "which packet was sent last?". Later, we will use tcp_skb_sent_after() instead in RACK. Fixes: b9f64820fb22 ("tcp: track data delivery rate for a TCP connection") Signed-off-by: Pengcheng Yang Cc: Paolo Abeni Acked-by: Neal Cardwell Tested-by: Neal Cardwell Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/1650422081-22153-1-git-send-email-yangpc@wangsu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e9b1a51c32972a2e7956d7abda90296ba7f8db1b Author: Marek Vasut Date: Thu Apr 21 16:08:27 2022 +0200 pinctrl: stm32: Keep pinctrl block clock enabled when LEVEL IRQ requested [ Upstream commit 05d8af449d93e04547b4c6b328e39c890bc803f4 ] The current EOI handler for LEVEL triggered interrupts calls clk_enable(), register IO, clk_disable(). The clock manipulation requires locking which happens with IRQs disabled in clk_enable_lock(). Instead of turning the clock on and off all the time, enable the clock in case LEVEL interrupt is requested and keep the clock enabled until all LEVEL interrupts are freed. The LEVEL interrupts are an exception on this platform and seldom used, so this does not affect the common case. This simplifies the LEVEL interrupt handling considerably and also fixes the following splat found when using preempt-rt: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/locking/rtmutex.c:2040 __rt_mutex_trylock+0x37/0x62 Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.109-rt65-stable-standard-00068-g6a5afc4b1217 #85 Hardware name: STM32 (Device Tree Support) [] (unwind_backtrace) from [] (show_stack+0xb/0xc) [] (show_stack) from [] (dump_stack+0x6f/0x84) [] (dump_stack) from [] (__warn+0x7f/0xa4) [] (__warn) from [] (warn_slowpath_fmt+0x3b/0x74) [] (warn_slowpath_fmt) from [] (__rt_mutex_trylock+0x37/0x62) [] (__rt_mutex_trylock) from [] (rt_spin_trylock+0x7/0x16) [] (rt_spin_trylock) from [] (clk_enable_lock+0xb/0x80) [] (clk_enable_lock) from [] (clk_core_enable_lock+0x9/0x18) [] (clk_core_enable_lock) from [] (stm32_gpio_get+0x11/0x24) [] (stm32_gpio_get) from [] (stm32_gpio_irq_trigger+0x1f/0x48) [] (stm32_gpio_irq_trigger) from [] (handle_fasteoi_irq+0x71/0xa8) [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x19/0x22) [] (generic_handle_irq) from [] (__handle_domain_irq+0x55/0x64) [] (__handle_domain_irq) from [] (gic_handle_irq+0x53/0x64) [] (gic_handle_irq) from [] (__irq_svc+0x65/0xc0) Exception stack(0xc0e01f18 to 0xc0e01f60) 1f00: 0000300c 00000000 1f20: 0000300c c010ff01 00000000 00000000 c0e00000 c0e07714 00000001 c0e01f78 1f40: c0e07758 00000000 ef7cd0ff c0e01f68 c010554b c0105542 40000033 ffffffff [] (__irq_svc) from [] (arch_cpu_idle+0xc/0x1e) [] (arch_cpu_idle) from [] (default_idle_call+0x21/0x3c) [] (default_idle_call) from [] (do_idle+0xe3/0x1e4) [] (do_idle) from [] (cpu_startup_entry+0x13/0x14) [] (cpu_startup_entry) from [] (start_kernel+0x397/0x3d4) [] (start_kernel) from [<00000000>] (0x0) ---[ end trace 0000000000000002 ]--- Power consumption measured on STM32MP157C DHCOM SoM is not increased or is below noise threshold. Fixes: 47beed513a85b ("pinctrl: stm32: Add level interrupt support to gpio irq chip") Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Fabien Dessenne Cc: Linus Walleij Cc: Marc Zyngier Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-arm-kernel@lists.infradead.org To: linux-gpio@vger.kernel.org Reviewed-by: Fabien Dessenne Link: https://lore.kernel.org/r/20220421140827.214088-1-marex@denx.de Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit eb90a4269c20d41c840c170f47278ab634c2400f Author: Francesco Ruggeri Date: Wed Apr 20 17:50:26 2022 -0700 tcp: md5: incorrect tcp_header_len for incoming connections [ Upstream commit 5b0b9e4c2c895227c8852488b3f09839233bba54 ] In tcp_create_openreq_child we adjust tcp_header_len for md5 using the remote address in newsk. But that address is still 0 in newsk at this point, and it is only set later by the callers (tcp_v[46]_syn_recv_sock). Use the address from the request socket instead. Fixes: cfb6eeb4c860 ("[TCP]: MD5 Signature Option (RFC2385) support.") Signed-off-by: Francesco Ruggeri Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20220421005026.686A45EC01F2@us226.sjc.aristanetworks.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eea166561f7c70128263637cf99b1576b4bd1be4 Author: Luca Ceresoli Date: Wed Apr 20 16:24:31 2022 +0200 pinctrl: rockchip: fix RK3308 pinmux bits [ Upstream commit 1f3e25a068832f8892a5ff71467622d012f5bc9f ] Some of the pinmuxing bits described in rk3308_mux_recalced_data are wrong, pointing to non-existing registers. Fix the entire table. Also add a comment in front of each entry with the same string that appears in the datasheet to make the table easier to compare with the docs. This fix has been tested on real hardware for the gpio3b3_sel entry. Fixes: 7825aeb7b208 ("pinctrl: rockchip: add rk3308 SoC support") Signed-off-by: Luca Ceresoli Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20220420142432.248565-1-luca.ceresoli@bootlin.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 86d8076e597109348724212b7796e813dd25051e Author: Eyal Birger Date: Wed Apr 20 19:52:19 2022 +0300 bpf, lwt: Fix crash when using bpf_skb_set_tunnel_key() from bpf_xmit lwt hook [ Upstream commit b02d196c44ead1a5949729be9ff08fe781c3e48a ] xmit_check_hhlen() observes the dst for getting the device hard header length to make sure a modified packet can fit. When a helper which changes the dst - such as bpf_skb_set_tunnel_key() - is called as part of the xmit program the accessed dst is no longer valid. This leads to the following splat: BUG: kernel NULL pointer dereference, address: 00000000000000de #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 798 Comm: ping Not tainted 5.18.0-rc2+ #103 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP: 0010:bpf_xmit+0xfb/0x17f Code: c6 c0 4d cd 8e 48 c7 c7 7d 33 f0 8e e8 42 09 fb ff 48 8b 45 58 48 8b 95 c8 00 00 00 48 2b 95 c0 00 00 00 48 83 e0 fe 48 8b 00 <0f> b7 80 de 00 00 00 39 c2 73 22 29 d0 b9 20 0a 00 00 31 d2 48 89 RSP: 0018:ffffb148c0bc7b98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000240008 RCX: 0000000000000000 RDX: 0000000000000010 RSI: 00000000ffffffea RDI: 00000000ffffffff RBP: ffff922a828a4e00 R08: ffffffff8f1350e8 R09: 00000000ffffdfff R10: ffffffff8f055100 R11: ffffffff8f105100 R12: 0000000000000000 R13: ffff922a828a4e00 R14: 0000000000000040 R15: 0000000000000000 FS: 00007f414e8f0080(0000) GS:ffff922afdc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000de CR3: 0000000002d80006 CR4: 0000000000370ef0 Call Trace: lwtunnel_xmit.cold+0x71/0xc8 ip_finish_output2+0x279/0x520 ? __ip_finish_output.part.0+0x21/0x130 Fix by fetching the device hard header length before running the BPF code. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Signed-off-by: Eyal Birger Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220420165219.1755407-1-eyal.birger@gmail.com Signed-off-by: Sasha Levin commit c2a69ac00b42a7a569cbaa4c5607fb3eef563706 Author: Pablo Neira Ayuso Date: Mon Apr 18 12:21:05 2022 +0200 netfilter: nft_set_rbtree: overlap detection with element re-addition after deletion [ Upstream commit babc3dc9524f0bcb5a0ec61f3c3639b11508fad6 ] This patch fixes spurious EEXIST errors. Extend d2df92e98a34 ("netfilter: nft_set_rbtree: handle element re-addition after deletion") to deal with elements with same end flags in the same transation. Reset the overlap flag as described by 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion"). Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion") Fixes: d2df92e98a34 ("netfilter: nft_set_rbtree: handle element re-addition after deletion") Signed-off-by: Pablo Neira Ayuso Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9cc897ca03df52a2fec8632b40d45862fa75d69e Author: Miaoqian Lin Date: Wed Apr 20 19:04:08 2022 +0800 net: dsa: Add missing of_node_put() in dsa_port_link_register_of [ Upstream commit fc06b2867f4cea543505acfb194c2be4ebf0c7d3 ] The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. of_node_put() will check for NULL value. Fixes: a20f997010c4 ("net: dsa: Don't instantiate phylink for CPU/DSA ports unless needed") Signed-off-by: Miaoqian Lin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 72e7940b00b5a0f8d53747fd6c52a53afddd6728 Author: Geert Uytterhoeven Date: Wed Apr 20 09:05:26 2022 +0200 memory: renesas-rpc-if: Fix HF/OSPI data transfer in Manual Mode [ Upstream commit 7e842d70fe599bc13594b650b2144c4b6e6d6bf1 ] HyperFlash devices fail to probe: rpc-if-hyperflash rpc-if-hyperflash: probing of hyperbus device failed In HyperFlash or Octal-SPI Flash mode, the Transfer Data Enable bits (SPIDE) in the Manual Mode Enable Setting Register (SMENR) are derived from half of the transfer size, cfr. the rpcif_bits_set() helper function. However, rpcif_reg_{read,write}() does not take the bus size into account, and does not double all Manual Mode Data Register access sizes when communicating with a HyperFlash or Octal-SPI Flash device. Fix this, and avoid the back-and-forth conversion between transfer size and Transfer Data Enable bits, by explicitly storing the transfer size in struct rpcif, and using that value to determine access size in rpcif_reg_{read,write}(). Enforce that the "high" Manual Mode Read/Write Data Registers (SM[RW]DR1) are only used for 8-byte data accesses. While at it, forbid writing to the Manual Mode Read Data Registers, as they are read-only. Fixes: fff53a551db50f5e ("memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode") Signed-off-by: Geert Uytterhoeven Signed-off-by: Krzysztof Kozlowski Tested-by: Lad Prabhakar Tested-by: Wolfram Sang Reviewed-by: Wolfram Sang Link: https://lore.kernel.org/r/cde9bfacf704c81865f57b15d1b48a4793da4286.1649681476.git.geert+renesas@glider.be Link: https://lore.kernel.org/r/20220420070526.9367-1-krzysztof.kozlowski@linaro.org' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 2075f6f8e627662d4e2d09bc587b9eb5e815333a Author: Marek Vasut Date: Fri Apr 15 23:54:10 2022 +0200 pinctrl: stm32: Do not call stm32_gpio_get() for edge triggered IRQs in EOI [ Upstream commit e74200ebf7c4f6a7a7d1be9f63833ddba251effa ] The stm32_gpio_get() should only be called for LEVEL triggered interrupts, skip calling it for EDGE triggered interrupts altogether to avoid wasting CPU cycles in EOI handler. On this platform, EDGE triggered interrupts are the majority and LEVEL triggered interrupts are the exception no less, and the CPU cycles are not abundant. Fixes: 47beed513a85b ("pinctrl: stm32: Add level interrupt support to gpio irq chip") Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Fabien Dessenne Cc: Linus Walleij Cc: Marc Zyngier Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-arm-kernel@lists.infradead.org To: linux-gpio@vger.kernel.org Link: https://lore.kernel.org/r/20220415215410.498349-1-marex@denx.de Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 291ee6787b3503786a4444d328770b324e2df7f9 Author: Oleksandr Ocheretnyi Date: Sun Apr 17 11:46:47 2022 -0700 mtd: fix 'part' field data corruption in mtd_info [ Upstream commit 37c5f9e80e015d0df17d0c377c18523002986851 ] Commit 46b5889cc2c5 ("mtd: implement proper partition handling") started using "mtd_get_master_ofs()" in mtd callbacks to determine memory offsets by means of 'part' field from mtd_info, what previously was smashed accessing 'master' field in the mtd_set_dev_defaults() method. That provides wrong offset what causes hardware access errors. Just make 'part', 'master' as separate fields, rather than using union type to avoid 'part' data corruption when mtd_set_dev_defaults() is called. Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling") Signed-off-by: Oleksandr Ocheretnyi Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220417184649.449289-1-oocheret@cisco.com Signed-off-by: Sasha Levin commit 6465a2120b2376679b14880e7da5fc8b6007664a Author: Miaoqian Lin Date: Tue Apr 12 08:34:31 2022 +0000 mtd: rawnand: Fix return value check of wait_for_completion_timeout [ Upstream commit 084c16ab423a8890121b902b405823bfec5b4365 ] wait_for_completion_timeout() returns unsigned long not int. It returns 0 if timed out, and positive if completed. The check for <= 0 is ambiguous and should be == 0 here indicating timeout which is the only error case. Fixes: 83738d87e3a0 ("mtd: sh_flctl: Add DMA capabilty") Signed-off-by: Miaoqian Lin Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220412083435.29254-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit 102775603cd9d55957600cbe6b80ac7631a668e3 Author: YueHaibing Date: Sat Apr 9 18:59:58 2022 +0800 pinctrl: mediatek: moore: Fix build error [ Upstream commit 87950929e2ff2236207bdbe14bff8230558b541b ] If EINT_MTK is m and PINCTRL_MTK_V2 is y, build fails: drivers/pinctrl/mediatek/pinctrl-moore.o: In function `mtk_gpio_set_config': pinctrl-moore.c:(.text+0xa6c): undefined reference to `mtk_eint_set_debounce' drivers/pinctrl/mediatek/pinctrl-moore.o: In function `mtk_gpio_to_irq': pinctrl-moore.c:(.text+0xacc): undefined reference to `mtk_eint_find_irq' Select EINT_MTK for PINCTRL_MTK_V2 to fix this. Fixes: 8174a8512e3e ("pinctrl: mediatek: make MediaTek pinctrl v2 driver ready for buidling loadable module") Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20220409105958.37412-1-yuehaibing@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d3dfa4954e35f36506023a3335e58ed6063f394b Author: Heiner Kallweit Date: Fri Apr 15 16:03:10 2022 +0200 phy: amlogic: fix error path in phy_g12a_usb3_pcie_probe() [ Upstream commit 2c8045d48dee703ad8eab2be7d6547765a89c069 ] If clk_prepare_enable() fails we call clk_disable_unprepare() in the error path what results in a warning that the clock is disabled and unprepared already. And if we fail later in phy_g12a_usb3_pcie_probe() then we bail out w/o calling clk_disable_unprepare(). This patch fixes both errors. Fixes: 36077e16c050 ("phy: amlogic: Add Amlogic G12A USB3 + PCIE Combo PHY Driver") Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/8e416f95-1084-ee28-860e-7884f7fa2e32@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b347b850a49f48e26f2cbc4aaac27d009b66a436 Author: Pengcheng Yang Date: Tue Apr 12 19:05:45 2022 +0800 ipvs: correctly print the memory size of ip_vs_conn_tab [ Upstream commit eba1a872cb73314280d5448d934935b23e30b7ca ] The memory size of ip_vs_conn_tab changed after we use hlist instead of list. Fixes: 731109e78415 ("ipvs: use hlist instead of list") Signed-off-by: Pengcheng Yang Acked-by: Julian Anastasov Acked-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 12d3fd4d8c49bc68ae3f2a450ec59a22e895325f Author: Adam Ford Date: Thu Mar 3 11:18:17 2022 -0600 ARM: dts: logicpd-som-lv: Fix wrong pinmuxing on OMAP35 [ Upstream commit 46ff3df87215ff42c0cd2c4bdb7d74540384a69c ] The pinout of the OMAP35 and DM37 variants of the SOM-LV are the same, but the macros which define the pinmuxing are different between OMAP3530 and DM3730. The pinmuxing was correct for for the DM3730, but wrong for the OMAP3530. Since the boot loader was correctly pin-muxing the pins, this was not obvious. As the bootloader not guaranteed to pinmux all the pins any more, this causes an issue, so the pinmux needs to be moved from a common file to their respective board files. Fixes: f8a2e3ff7103 ("ARM: dts: Add minimal support for LogicPD OMAP35xx SOM-LV devkit") Signed-off-by: Adam Ford Message-Id: <20220303171818.11060-1-aford173@gmail.com> Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 6b4928990b14a64deeb42e10136fe69bfd57498d Author: Adam Ford Date: Sat Feb 26 15:48:19 2022 -0600 ARM: dts: am3517-evm: Fix misc pinmuxing [ Upstream commit 942da3af32b2288e674736eb159d1fc676261691 ] The bootloader for the AM3517 has previously done much of the pin muxing, but as the bootloader is moving more and more to a model based on the device tree, it may no longer automatically mux the pins, so it is necessary to add the pinmuxing to the Linux device trees so the respective peripherals can remain functional. Fixes: 6ed1d7997561 ("ARM: dts: am3517-evm: Add support for UI board and Audio") Signed-off-by: Adam Ford Message-Id: <20220226214820.747847-1-aford173@gmail.com> Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 6476c49e8e31a01068055faa20dbcc4a6ca0f434 Author: H. Nikolaus Schaller Date: Tue Mar 8 14:00:20 2022 +0100 ARM: dts: Fix mmc order for omap3-gta04 [ Upstream commit 09269dd050094593fc747f2a5853d189fefcb6b5 ] Commit a1ebdb374199 ("ARM: dts: Fix swapped mmc order for omap3") introduces general mmc aliases. Let's tailor them to the need of the GTA04 board which does not make use of mmc2 and mmc3 interfaces. Fixes: a1ebdb374199 ("ARM: dts: Fix swapped mmc order for omap3") Signed-off-by: H. Nikolaus Schaller Message-Id: Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 4e81598e21229f4c81c515e7d9629d18d877963c Author: Stephen Boyd Date: Tue Apr 12 15:00:33 2022 -0700 interconnect: qcom: sdx55: Drop IP0 interconnects [ Upstream commit 2fb251c265608636fc961b7d38e1a03937e57371 ] Similar to the sc7180 commit, let's drop the IP0 interconnects here because the IP0 resource is also used in the clk-rpmh driver on sdx55. It's bad to have the clk framework and interconnect framework control the same RPMh resource without any coordination. The rpmh driver in the kernel doesn't aggregate resources between clients either, so leaving control to clk-rpmh avoids any issues with unused interconnects turning off IP0 behind the back of the clk framework. Cc: Alex Elder Cc: Manivannan Sadhasivam Cc: Bjorn Andersson Cc: Taniya Das Cc: Mike Tipton Fixes: b2150cab9a97 ("clk: qcom: rpmh: add support for SDX55 rpmh IPA clock") Signed-off-by: Stephen Boyd Reviewed-by: Alex Elder Acked-by: Manivannan Sadhasivam Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220412220033.1273607-3-swboyd@chromium.org Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 344558d201bb4b277b2153aa588512b0c6b750c9 Author: Miaoqian Lin Date: Tue Mar 1 02:58:49 2022 +0000 phy: ti: Add missing pm_runtime_disable() in serdes_am654_probe [ Upstream commit ce88613e5bd579478653a028291098143f2a5bdf ] The pm_runtime_enable() will increase power disable depth. If the probe fails, we should use pm_runtime_disable() to balance pm_runtime_enable(). Add missing pm_runtime_disable() for serdes_am654_probe(). Fixes: 71e2f5c5c224 ("phy: ti: Add a new SERDES driver for TI's AM654x SoC") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220301025853.1911-1-linmq006@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit cf6f119f8244504934df4f482bf70e9cbc81a45b Author: Miaoqian Lin Date: Tue Mar 1 02:46:11 2022 +0000 phy: mapphone-mdm6600: Fix PM error handling in phy_mdm6600_probe [ Upstream commit d644e0d79829b1b9a14beedbdb0dc1256fc3677d ] The pm_runtime_enable will increase power disable depth. If the probe fails, we should use pm_runtime_disable() to balance pm_runtime_enable(). And use pm_runtime_dont_use_autosuspend() to undo pm_runtime_use_autosuspend() In the PM Runtime docs: Drivers in ->remove() callback should undo the runtime PM changes done in ->probe(). Usually this means calling pm_runtime_disable(), pm_runtime_dont_use_autosuspend() etc. We should do this in error handling. Fixes: f7f50b2a7b05 ("phy: mapphone-mdm6600: Add runtime PM support for n_gsm on USB suspend") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220301024615.31899-1-linmq006@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 49c7d87f19d4402565bc7030ea73688cba296400 Author: Claudiu Beznea Date: Thu Mar 31 17:13:23 2022 +0300 ARM: dts: at91: fix pinctrl phandles [ Upstream commit 0c640d9544d0109da3889d71ae77301e556db977 ] Commit bf781869e5cf ("ARM: dts: at91: add pinctrl-{names, 0} for all gpios") introduces pinctrl phandles for pins used by individual controllers to avoid failures due to commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges"). For SPI controllers available on SAMA5D4 and SAMA5D3 some of the pins are defined in SoC specific dtsi on behalf of pinctrl-0. Adding extra pinctrl phandles on board specific dts also on behalf of pinctrl-0 overwrite the pinctrl-0 phandle specified in SoC specific dtsi. Thus add the board specific pinctrl to pinctrl-1. Fixes: bf781869e5cf ("ARM: dts: at91: add pinctrl-{names, 0} for all gpios") Depends-on: 5c8b49852910 ("ARM: dts: at91: sama5d4_xplained: fix pinctrl phandle name") Reported-by: Ajay Kathat Co-developed-by: Ajay Kathat Signed-off-by: Ajay Kathat Tested-by: Ajay Kathat Signed-off-by: Claudiu Beznea Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20220331141323.194355-2-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit 7ecb2639eb8ab15093e23fae98ec694d15301038 Author: Claudiu Beznea Date: Thu Mar 31 17:13:22 2022 +0300 ARM: dts: at91: sama5d4_xplained: fix pinctrl phandle name [ Upstream commit 5c8b49852910caffeebb1ce541fdd264ffc691b8 ] Pinctrl phandle is for spi1 so rename it to reflect this. Signed-off-by: Claudiu Beznea Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20220331141323.194355-1-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit 1e68040245ad46a3b3049ab1a1da65b1c90a37cb Author: Mark Brown Date: Mon Apr 4 11:28:05 2022 +0100 ARM: dts: at91: Map MCLK for wm8731 on at91sam9g20ek [ Upstream commit 0e486fe341fabd8e583f3d601a874cd394979c45 ] The MCLK of the WM8731 on the AT91SAM9G20-EK board is connected to the PCK0 output of the SoC and is expected to be set to 12MHz. Previously this was mapped using pre-common clock API calls in the audio machine driver but the conversion to the common clock framework broke that so describe things in the DT instead. Fixes: ff78a189b0ae55f ("ARM: at91: remove old at91-specific clock driver") Signed-off-by: Mark Brown Reviewed-by: Claudiu Beznea Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20220404102806.581374-2-broonie@kernel.org Signed-off-by: Sasha Levin commit 555bcbb7d0ffd30bea57c2244c059f37799a640a Author: Miaoqian Lin Date: Fri Mar 18 10:57:46 2022 +0000 phy: ti: omap-usb2: Fix error handling in omap_usb2_enable_clocks [ Upstream commit 3588060befff75ff39fab7122b94c6fb3148fcda ] The corresponding API for clk_prepare_enable is clk_disable_unprepare. Make sure that the clock is unprepared on exit by changing clk_disable to clk_disable_unprepare. Fixes: ed31ee7cf1fe ("phy: ti: usb2: Fix logic on -EPROBE_DEFER") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220318105748.19532-1-linmq006@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d60abf246aa51722bc4d8ffd87564146bf962542 Author: Tony Lindgren Date: Tue Apr 12 12:26:51 2022 +0300 ARM: dts: dra7: Fix suspend warning for vpe powerdomain [ Upstream commit 8d2453d9a307c2eafd21242dd73f35f05fb7ce74 ] We currently are getting the following warning after a system suspend: Powerdomain (vpe_pwrdm) didn't enter target state 0 Looks like this is because the STANDBYMODE bit for SMART_IDLE should not be used. The TRM "Table 12-348. VPE_SYSCONFIG" says that the value for SMART_IDLE is "0x2: Same behavior as bit-field value of 0x1". But if the SMART_IDLE value is used, PM_VPE_PWRSTST LASTPOWERSTATEENTERED bits always show value of 3. Let's fix the issue by dropping SMART_IDLE for vpe. And let's also add the missing the powerdomain for vpe. Fixes: 1a2095160594 ("ARM: dts: dra7: Add ti-sysc node for VPE") Cc: Benoit Parrot Reported-by: Kevin Hilman Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 127295f86f701783253626d580d9d62ad7b1d35f Author: Tony Lindgren Date: Tue Apr 12 12:26:51 2022 +0300 bus: ti-sysc: Make omap3 gpt12 quirk handling SoC specific [ Upstream commit a12315d6d27093392b6c634e1d35a59f1d1f7a59 ] On beagleboard revisions A to B4 we need to use gpt12 as the system timer. However, the quirk handling added for gpt12 caused a regression for system suspend for am335x as the PM coprocessor needs the timers idled for suspend. Let's make the gpt12 quirk specific to omap34xx, other SoCs don't need it. Beagleboard revisions C and later no longer need to use the gpt12 related quirk. Then at some point, if we decide to drop support for the old beagleboard revisions A to B4, we can also drop the gpt12 related quirks completely. Fixes: 3ff340e24c9d ("bus: ti-sysc: Fix gpt12 system timer issue with reserved status") Reported-by: Kevin Hilman Suggested-by: Kevin Hilman Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 033cac39d0b7623b564350216b9163fd1086bf92 Author: Miaoqian Lin Date: Wed Mar 9 10:43:01 2022 +0000 ARM: OMAP2+: Fix refcount leak in omap_gic_of_init [ Upstream commit 0f83e6b4161617014017a694888dd8743f46f071 ] The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount. Fixes: fd1c07861491 ("ARM: OMAP4: Fix the init code to have OMAP4460 errata available in DT build") Signed-off-by: Miaoqian Lin Message-Id: <20220309104302.18398-1-linmq006@gmail.com> Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit a933ee691dbdb369bf1e613afea52fb43bfb71b3 Author: Krzysztof Kozlowski Date: Thu Apr 7 11:18:57 2022 +0200 phy: samsung: exynos5250-sata: fix missing device put in probe error paths [ Upstream commit 5c8402c4db45dd55c2c93c8d730f5dfa7c78a702 ] The actions of of_find_i2c_device_by_node() in probe function should be reversed in error paths by putting the reference to obtained device. Fixes: bcff4cba41bc ("PHY: Exynos: Add Exynos5250 SATA PHY driver") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Alim Akhtar Link: https://lore.kernel.org/r/20220407091857.230386-2-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3c8a02347f84985385199eddd89beba9fe132a9b Author: Miaoqian Lin Date: Thu Apr 7 11:18:56 2022 +0200 phy: samsung: Fix missing of_node_put() in exynos_sata_phy_probe [ Upstream commit 388ec8f079f2f20d5cd183c3bc6f33cbc3ffd3ef ] The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: bcff4cba41bc ("PHY: Exynos: Add Exynos5250 SATA PHY driver") Signed-off-by: Miaoqian Lin Reviewed-by: Krzysztof Kozlowski Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220407091857.230386-1-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bb0f3522cf42eff3b6cb0577dcdaea3b227e28ec Author: Guillaume Giraudon Date: Mon Apr 11 10:44:28 2022 -0400 arm64: dts: meson-sm1-bananapi-m5: fix wrong GPIO pin labeling for CON1 [ Upstream commit 962dd65e575dde950ef0844568edc37cfb39f302 ] The labels for lines 61 through 84 on the periphs-banks were offset by 2. 2 lines are missing in the BOOT GPIO lines (contains 14, should be 16) Added 2 empty entries in BOOT to realigned the rest of GPIO labels to match the Banana Pi M5 schematics. (Thanks to Neil Armstrong for the heads up on the position of the missing pins) Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts") Signed-off-by: Guillaume Giraudon Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220411144427.874-1-ggiraudon@prism19.com Signed-off-by: Sasha Levin commit 0f8e303faf88a300b0d7176cd2416f355ebcbf1e Author: Marek Vasut Date: Mon Apr 4 01:42:05 2022 +0200 arm64: dts: imx8mn: Fix SAI nodes [ Upstream commit 574518b7ccbaef74cb89eb1a1a0da88afa1e0113 ] The most specific compatible string element should be "fsl,imx8mn-sai" on i.MX8M Nano, fix it from current "fsl,imx8mm-sai" (two Ms, likely due to copy-paste error from i.MX8M Mini). Fixes: 9e9860069725f ("arm64: dts: imx8mn: Add SAI nodes") Signed-off-by: Marek Vasut Cc: Adam Ford Cc: Fabio Estevam Cc: Peng Fan Cc: Shawn Guo Cc: NXP Linux Team To: linux-arm-kernel@lists.infradead.org Reviewed-by: Adam Ford Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit f1266c4eba8a5d852259d1c415c39dfa475b05d2 Author: Fabio Estevam Date: Sat Mar 26 12:14:55 2022 -0300 ARM: dts: imx6qdl-apalis: Fix sgtl5000 detection issue [ Upstream commit fa51e1dc4b91375bc18349663a52395ad585bd3c ] On a custom carrier board with a i.MX6Q Apalis SoM, the sgtl5000 codec on the SoM is often not detected and the following error message is seen when the sgtl5000 driver tries to read the ID register: sgtl5000 1-000a: Error reading chip id -6 The reason for the error is that the MCLK clock is not provided early enough. Fix the problem by describing the MCLK pinctrl inside the codec node instead of placing it inside the audmux pinctrl group. With this change applied the sgtl5000 is always detected on every boot. Fixes: 693e3ffaae5a ("ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM") Signed-off-by: Fabio Estevam Reviewed-by: Tim Harvey Acked-by: Max Krummenacher Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 7596c4576a0ee9d0777d5fb21f0aa2baa89354da Author: Weitao Wang Date: Fri Apr 8 16:48:21 2022 +0300 USB: Fix xhci event ring dequeue pointer ERDP update issue [ Upstream commit e91ac20889d1a26d077cc511365cd7ff4346a6f3 ] In some situations software handles TRB events slower than adding TRBs. If the number of TRB events to be processed in a given interrupt is exactly the same as the event ring size 256, then the local variable "event_ring_deq" that holds the initial dequeue position is equal to software_dequeue after handling all 256 interrupts. It will cause driver to not update ERDP to hardware, Software dequeue pointer is out of sync with ERDP on interrupt exit. On the next interrupt, the event ring may full but driver will not update ERDP as software_dequeue is equal to ERDP. [ 536.377115] xhci_hcd 0000:00:12.0: ERROR unknown event type 37 [ 566.933173] sd 8:0:0:0: [sdb] tag#27 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT [ 566.933181] sd 8:0:0:0: [sdb] tag#27 CDB: Write(10) 2a 00 17 71 e6 78 00 00 08 00 [ 572.041186] xhci_hcd On some situataions,the0000:00:12.0: xHCI host not responding to stop endpoint command. [ 572.057193] xhci_hcd 0000:00:12.0: Host halt failed, -110 [ 572.057196] xhci_hcd 0000:00:12.0: xHCI host controller not responding, assume dead [ 572.057236] sd 8:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD [ 572.057240] sd 8:0:0:0: [sdb] tag#26 CDB: Write(10) 2a 00 38 eb cc d8 00 00 08 00 [ 572.057244] sd 8:0:0:0: [sdb] tag#25 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD Hardware ERDP is updated mid event handling if there are more than 128 events in an interrupt (half of ring size). Fix this by updating the software local variable at the same time as hardware ERDP. [commit message rewording -Mathias] Fixes: dc0ffbea5729 ("usb: host: xhci: update event ring dequeue pointer on purpose") Reviewed-by: Peter Chen Signed-off-by: Weitao Wang Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20220408134823.2527272-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 11baa5edf37dec6cc76c063bfa5db4d61126e892 Author: Liu Ying Date: Fri Mar 4 16:04:43 2022 +0800 arm64: dts: imx8qm: Correct SCU clock controller's compatible property [ Upstream commit dd2737fab4a6ce9ba4eb84842bedbd87d55241a6 ] The fsl,scu.txt dt-binding documentation explicitly mentions that the compatible string should be either "fsl,imx8qm-clock" or "fsl,imx8qxp-clock", followed by "fsl,scu-clk". Also, i.MX8qm SCU clocks and i.MX8qxp SCU clocks are really not the same, so we have to set the compatible property according to SoC name. Let's correct the i.MX8qm clock controller's compatible property from "fsl,imx8qxp-clk", "fsl,scu-clk" to "fsl,imx8qm-clk", "fsl,scu-clk" . Fixes: f2180be18a63 ("arm64: dts: imx: add imx8qm common dts file") Cc: Rob Herring Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Signed-off-by: Liu Ying Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit d84f8327af13b975d3ccd5eeb4f4c6e58dc7674d Author: Maciej Fijalkowski Date: Wed Apr 6 17:58:04 2022 +0200 xsk: Fix l2fwd for copy mode + busy poll combo [ Upstream commit 8de8b71b787f38983d414d2dba169a3bfefa668a ] While checking AF_XDP copy mode combined with busy poll, strange results were observed. rxdrop and txonly scenarios worked fine, but l2fwd broke immediately. After a deeper look, it turned out that for l2fwd, Tx side was exiting early due to xsk_no_wakeup() returning true and in the end xsk_generic_xmit() was never called. Note that AF_XDP Tx in copy mode is syscall steered, so the current behavior is broken. Txonly scenario only worked due to the fact that sk_mark_napi_id_once_xdp() was never called - since Rx side is not in the picture for this case and mentioned function is called in xsk_rcv_check(), sk::sk_napi_id was never set, which in turn meant that xsk_no_wakeup() was returning false (see the sk->sk_napi_id >= MIN_NAPI_ID check in there). To fix this, prefer busy poll in xsk_sendmsg() only when zero copy is enabled on a given AF_XDP socket. By doing so, busy poll in copy mode would not exit early on Tx side and eventually xsk_generic_xmit() will be called. Fixes: a0731952d9cd ("xsk: Add busy-poll support for {recv,send}msg()") Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220406155804.434493-1-maciej.fijalkowski@intel.com Signed-off-by: Sasha Levin commit 3ec920d755ae69c201b358e8d8e96c32f51145d8 Author: Chuanhong Guo Date: Sun Apr 3 00:03:13 2022 +0800 mtd: rawnand: fix ecc parameters for mt7622 [ Upstream commit 9fe4e0d3cbfe90152137963cc024ecb63db6e8e6 ] According to the datasheet, mt7622 only has 5 ECC capabilities instead of 7, and the decoding error register is arranged as follows: +------+---------+---------+---------+---------+ | Bits | 19:15 | 14:10 | 9:5 | 4:0 | +------+---------+---------+---------+---------+ | Name | ERRNUM3 | ERRNUM2 | ERRNUM1 | ERRNUM0 | +------+---------+---------+---------+---------+ This means err_mask should be 0x1f instead of 0x3f and the number of bits shifted in mtk_ecc_get_stats should be 5 instead of 8. This commit introduces err_shift for the difference in this register and fix other existing parameters. Public MT7622 reference manual can be found on [0] and the info this commit is based on is from page 656 and page 660. [0]: https://wiki.banana-pi.org/Banana_Pi_BPI-R64#Documents Fixes: 98dea8d71931 ("mtd: nand: mtk: Support MT7622 NAND flash controller.") Signed-off-by: Chuanhong Guo Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220402160315.919094-1-gch981213@gmail.com Signed-off-by: Sasha Levin commit 9e4dedb8ec72cfabf8e5ae8ff823855a839a792e Author: Tong Zhang Date: Sun Mar 27 08:40:05 2022 -0700 iio:imu:bmi160: disable regulator in error path [ Upstream commit d926054d5565d3cfa2c7c3f7a48e79bcc10453ed ] Regulator should be disabled in error path as mentioned in _regulator_put(). Also disable accel if gyro cannot be enabled. [ 16.233604] WARNING: CPU: 0 PID: 2177 at drivers/regulator/core.c:2257 _regulator_put [ 16.240453] Call Trace: [ 16.240572] [ 16.240676] regulator_put+0x26/0x40 [ 16.240853] regulator_bulk_free+0x26/0x50 [ 16.241050] release_nodes+0x3f/0x70 [ 16.241225] devres_release_group+0x147/0x1c0 [ 16.241441] ? bmi160_core_probe+0x175/0x3a0 [bmi160_core] Fixes: 5dea3fb066f0 ("iio: imu: bmi160: added regulator support") Reviewed-by: Andy Shevchenko Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20220327154005.806049-1-ztong0001@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit d583cd6afc3b8303e68321aec959b7a717c992a3 Author: Christian Hewitt Date: Thu Feb 10 10:06:38 2022 +0000 arm64: dts: meson: remove CPU opps below 1GHz for SM1 boards [ Upstream commit fd86d85401c2049f652293877c0f7e6e5afc3bbc ] Amlogic SM1 devices experience CPU stalls and random board wedges when the system idles and CPU cores clock down to lower opp points. Recent vendor kernels include a change to remove 100-250MHz and other distro sources also remove the 500/667MHz points. Unless all 100-667Mhz opps are removed or the CPU governor forced to performance stalls are still observed, so let's remove them to improve stability and uptime. Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS") Signed-off-by: Christian Hewitt Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220210100638.19130-3-christianshewitt@gmail.com Signed-off-by: Sasha Levin commit 9f878775fceb7bcfa6a6cd900ac1c8f8e4e18c83 Author: Christian Hewitt Date: Thu Feb 10 10:06:37 2022 +0000 arm64: dts: meson: remove CPU opps below 1GHz for G12B boards [ Upstream commit 6c4d636bc00dc17c63ffb2a73a0da850240e26e3 ] Amlogic G12B devices experience CPU stalls and random board wedges when the system idles and CPU cores clock down to lower opp points. Recent vendor kernels include a change to remove 100-250MHz and other distro sources also remove the 500/667MHz points. Unless all 100-667Mhz opps are removed or the CPU governor forced to performance stalls are still observed, so let's remove them to improve stability and uptime. Fixes: b96d4e92709b ("arm64: dts: meson-g12b: support a311d and s922x cpu operating points") Signed-off-by: Christian Hewitt Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220210100638.19130-2-christianshewitt@gmail.com Signed-off-by: Sasha Levin commit 4df1584738f1dc6f0dd854d258bba48591f1ed0e Author: Pavel Skripkin Date: Tue Mar 22 23:04:38 2022 +0300 video: fbdev: udlfb: properly check endpoint type [ Upstream commit aaf7dbe07385e0b8deb7237eca2a79926bbc7091 ] syzbot reported warning in usb_submit_urb, which is caused by wrong endpoint type. This driver uses out bulk endpoint for communication, so let's check if this endpoint is present and bail out early if not. Fail log: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 4822 at drivers/usb/core/urb.c:493 usb_submit_urb+0xd27/0x1540 drivers/usb/core/urb.c:493 Modules linked in: CPU: 0 PID: 4822 Comm: kworker/0:3 Tainted: G W 5.13.0-syzkaller #0 ... Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xd27/0x1540 drivers/usb/core/urb.c:493 ... Call Trace: dlfb_submit_urb+0x89/0x160 drivers/video/fbdev/udlfb.c:1969 dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315 dlfb_ops_set_par+0x2a3/0x840 drivers/video/fbdev/udlfb.c:1110 dlfb_usb_probe.cold+0x113e/0x1f4a drivers/video/fbdev/udlfb.c:1732 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 Fixes: 88e58b1a42f8 ("Staging: add udlfb driver") Reported-and-tested-by: syzbot+53ce4a4246d0fe0fee34@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 1ad0832e8712cdf82ad34f1af54561dd9c15d13d Author: Vladimir Zapolskiy Date: Fri Apr 1 10:14:24 2022 +0300 cpufreq: qcom-cpufreq-hw: Fix throttle frequency value on EPSS platforms [ Upstream commit f84ccad5f5660f86a642a3d7e2bfdc4e7a8a2d49 ] On QCOM platforms with EPSS flavour of cpufreq IP a throttled frequency is obtained from another register REG_DOMAIN_STATE, thus the helper function qcom_lmh_get_throttle_freq() should be modified accordingly, as for now it returns gibberish since .reg_current_vote is unset for EPSS hardware. To exclude a hardcoded magic number 19200 it is replaced by "xo" clock rate in KHz. Fixes: 275157b367f4 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Reviewed-by: Bjorn Andersson Signed-off-by: Vladimir Zapolskiy Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 38ac9ca932529e6540a5b02891d145c8edfb2677 Author: Dmitry Baryshkov Date: Sat Mar 26 18:51:51 2022 +0300 cpufreq: qcom-hw: fix the race between LMH worker and cpuhp [ Upstream commit 5e4f009da6be563984ba4db4ef4f32529e9aeb90 ] The driver would disable the worker when cpu is being put offline, but it happens closer to the end of cpufreq_offline(). The function qcom_lmh_dcvs_poll() can be running in parallel with this, when policy->cpus already has been updated. Read policy->related_cpus instead. [ 37.122433] ------------[ cut here ]------------ [ 37.127225] WARNING: CPU: 0 PID: 187 at drivers/base/arch_topology.c:180 topology_update_thermal_pressure+0xec/0x100 [ 37.138098] Modules linked in: [ 37.141279] CPU: 0 PID: 187 Comm: kworker/0:3 Tainted: G S 5.17.0-rc6-00389-g37c83d0b8710-dirty #713 [ 37.158306] Workqueue: events qcom_lmh_dcvs_poll [ 37.163095] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 37.170278] pc : topology_update_thermal_pressure+0xec/0x100 [ 37.176131] lr : topology_update_thermal_pressure+0x20/0x100 [ 37.181977] sp : ffff800009b6bce0 [ 37.185402] x29: ffff800009b6bce0 x28: ffffd87abe92b000 x27: ffff04bd7292e205 [ 37.192792] x26: ffffd87abe930af8 x25: ffffd87abe94e4c8 x24: 0000000000000000 [ 37.200180] x23: ffff04bb01177018 x22: ffff04bb011770c0 x21: ffff04bb01177000 [ 37.207567] x20: ffff04bb0a419000 x19: 00000000000c4e00 x18: 0000000000000000 [ 37.214954] x17: 000000040044ffff x16: 004000b2b5503510 x15: 0000006aaa1326d2 [ 37.222333] x14: 0000000000000232 x13: 0000000000000001 x12: 0000000000000040 [ 37.229718] x11: ffff04bb00400000 x10: 968f57bd39f701c8 x9 : ffff04bb0acc8674 [ 37.237095] x8 : fefefefefefefeff x7 : 0000000000000018 x6 : ffffd87abd90092c [ 37.244478] x5 : 0000000000000016 x4 : 0000000000000000 x3 : 0000000000000100 [ 37.251852] x2 : ffff04bb0a419020 x1 : 0000000000000100 x0 : 0000000000000100 [ 37.259235] Call trace: [ 37.261771] topology_update_thermal_pressure+0xec/0x100 [ 37.267266] qcom_lmh_dcvs_poll+0xbc/0x154 [ 37.271505] process_one_work+0x288/0x69c [ 37.275654] worker_thread+0x74/0x470 [ 37.279450] kthread+0xfc/0x100 [ 37.282712] ret_from_fork+0x10/0x20 [ 37.286417] irq event stamp: 74 [ 37.289664] hardirqs last enabled at (73): [] _raw_spin_unlock_irq+0x44/0x80 [ 37.298632] hardirqs last disabled at (74): [] __schedule+0x710/0xa10 [ 37.306885] softirqs last enabled at (58): [] _stext+0x410/0x588 [ 37.314778] softirqs last disabled at (51): [] __irq_exit_rcu+0x158/0x174 [ 37.323386] ---[ end trace 0000000000000000 ]--- Fixes: 275157b367f4 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Signed-off-by: Dmitry Baryshkov Reviewed-by: Bjorn Andersson Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 08b036bac8651406af7fb2e623738d62c9b306d3 Author: Nikolay Aleksandrov Date: Mon Apr 25 13:37:03 2022 +0300 virtio_net: fix wrong buf address calculation when using xdp commit acb16b395c3f3d7502443e0c799c2b42df645642 upstream. We received a report[1] of kernel crashes when Cilium is used in XDP mode with virtio_net after updating to newer kernels. After investigating the reason it turned out that when using mergeable bufs with an XDP program which adjusts xdp.data or xdp.data_meta page_to_buf() calculates the build_skb address wrong because the offset can become less than the headroom so it gets the address of the previous page (-X bytes depending on how lower offset is): page_to_skb: page addr ffff9eb2923e2000 buf ffff9eb2923e1ffc offset 252 headroom 256 This is a pr_err() I added in the beginning of page_to_skb which clearly shows offset that is less than headroom by adding 4 bytes of metadata via an xdp prog. The calculations done are: receive_mergeable(): headroom = VIRTIO_XDP_HEADROOM; // VIRTIO_XDP_HEADROOM == 256 bytes offset = xdp.data - page_address(xdp_page) - vi->hdr_len - metasize; page_to_skb(): p = page_address(page) + offset; ... buf = p - headroom; Now buf goes -4 bytes from the page's starting address as can be seen above which is set as skb->head and skb->data by build_skb later. Depending on what's done with the skb (when it's freed most often) we get all kinds of corruptions and BUG_ON() triggers in mm[2]. We have to recalculate the new headroom after the xdp program has run, similar to how offset and len are recalculated. Headroom is directly related to data_hard_start, data and data_meta, so we use them to get the new size. The result is correct (similar pr_err() in page_to_skb, one case of xdp_page and one case of virtnet buf): a) Case with 4 bytes of metadata [ 115.949641] page_to_skb: page addr ffff8b4dcfad2000 offset 252 headroom 252 [ 121.084105] page_to_skb: page addr ffff8b4dcf018000 offset 20732 headroom 252 b) Case of pushing data +32 bytes [ 153.181401] page_to_skb: page addr ffff8b4dd0c4d000 offset 288 headroom 288 [ 158.480421] page_to_skb: page addr ffff8b4dd00b0000 offset 24864 headroom 288 c) Case of pushing data -33 bytes [ 835.906830] page_to_skb: page addr ffff8b4dd3270000 offset 223 headroom 223 [ 840.839910] page_to_skb: page addr ffff8b4dcdd68000 offset 12511 headroom 223 Offset and headroom are equal because offset points to the start of reserved bytes for the virtio_net header which are at buf start + headroom, while data points at buf start + vnet hdr size + headroom so when data or data_meta are adjusted by the xdp prog both the headroom size and the offset change equally. We can use data_hard_start to compute the new headroom after the xdp prog (linearized / page start case, the virtnet buf case is similar just with bigger base offset): xdp.data_hard_start = page_address + vnet_hdr xdp.data = page_address + vnet_hdr + headroom new headroom after xdp prog = xdp.data - xdp.data_hard_start - metasize An example reproducer xdp prog[3] is below. [1] https://github.com/cilium/cilium/issues/19453 [2] Two of the many traces: [ 40.437400] BUG: Bad page state in process swapper/0 pfn:14940 [ 40.916726] BUG: Bad page state in process systemd-resolve pfn:053b7 [ 41.300891] kernel BUG at include/linux/mm.h:720! [ 41.301801] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 41.302784] CPU: 1 PID: 1181 Comm: kubelet Kdump: loaded Tainted: G B W 5.18.0-rc1+ #37 [ 41.304458] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014 [ 41.306018] RIP: 0010:page_frag_free+0x79/0xe0 [ 41.306836] Code: 00 00 75 ea 48 8b 07 a9 00 00 01 00 74 e0 48 8b 47 48 48 8d 50 ff a8 01 48 0f 45 fa eb d0 48 c7 c6 18 b8 30 a6 e8 d7 f8 fc ff <0f> 0b 48 8d 78 ff eb bc 48 8b 07 a9 00 00 01 00 74 3a 66 90 0f b6 [ 41.310235] RSP: 0018:ffffac05c2a6bc78 EFLAGS: 00010292 [ 41.311201] RAX: 000000000000003e RBX: 0000000000000000 RCX: 0000000000000000 [ 41.312502] RDX: 0000000000000001 RSI: ffffffffa6423004 RDI: 00000000ffffffff [ 41.313794] RBP: ffff993c98823600 R08: 0000000000000000 R09: 00000000ffffdfff [ 41.315089] R10: ffffac05c2a6ba68 R11: ffffffffa698ca28 R12: ffff993c98823600 [ 41.316398] R13: ffff993c86311ebc R14: 0000000000000000 R15: 000000000000005c [ 41.317700] FS: 00007fe13fc56740(0000) GS:ffff993cdd900000(0000) knlGS:0000000000000000 [ 41.319150] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.320152] CR2: 000000c00008a000 CR3: 0000000014908000 CR4: 0000000000350ee0 [ 41.321387] Call Trace: [ 41.321819] [ 41.322193] skb_release_data+0x13f/0x1c0 [ 41.322902] __kfree_skb+0x20/0x30 [ 41.343870] tcp_recvmsg_locked+0x671/0x880 [ 41.363764] tcp_recvmsg+0x5e/0x1c0 [ 41.384102] inet_recvmsg+0x42/0x100 [ 41.406783] ? sock_recvmsg+0x1d/0x70 [ 41.428201] sock_read_iter+0x84/0xd0 [ 41.445592] ? 0xffffffffa3000000 [ 41.462442] new_sync_read+0x148/0x160 [ 41.479314] ? 0xffffffffa3000000 [ 41.496937] vfs_read+0x138/0x190 [ 41.517198] ksys_read+0x87/0xc0 [ 41.535336] do_syscall_64+0x3b/0x90 [ 41.551637] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 41.568050] RIP: 0033:0x48765b [ 41.583955] Code: e8 4a 35 fe ff eb 88 cc cc cc cc cc cc cc cc e8 fb 7a fe ff 48 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [ 41.632818] RSP: 002b:000000c000a2f5b8 EFLAGS: 00000212 ORIG_RAX: 0000000000000000 [ 41.664588] RAX: ffffffffffffffda RBX: 000000c000062000 RCX: 000000000048765b [ 41.681205] RDX: 0000000000005e54 RSI: 000000c000e66000 RDI: 0000000000000016 [ 41.697164] RBP: 000000c000a2f608 R08: 0000000000000001 R09: 00000000000001b4 [ 41.713034] R10: 00000000000000b6 R11: 0000000000000212 R12: 00000000000000e9 [ 41.728755] R13: 0000000000000001 R14: 000000c000a92000 R15: ffffffffffffffff [ 41.744254] [ 41.758585] Modules linked in: br_netfilter bridge veth netconsole virtio_net and [ 33.524802] BUG: Bad page state in process systemd-network pfn:11e60 [ 33.528617] page ffffe05dc0147b00 ffffe05dc04e7a00 ffff8ae9851ec000 (1) len 82 offset 252 metasize 4 hroom 0 hdr_len 12 data ffff8ae9851ec10c data_meta ffff8ae9851ec108 data_end ffff8ae9851ec14e [ 33.529764] page:000000003792b5ba refcount:0 mapcount:-512 mapping:0000000000000000 index:0x0 pfn:0x11e60 [ 33.532463] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 33.532468] raw: 000fffffc0000000 0000000000000000 dead000000000122 0000000000000000 [ 33.532470] raw: 0000000000000000 0000000000000000 00000000fffffdff 0000000000000000 [ 33.532471] page dumped because: nonzero mapcount [ 33.532472] Modules linked in: br_netfilter bridge veth netconsole virtio_net [ 33.532479] CPU: 0 PID: 791 Comm: systemd-network Kdump: loaded Not tainted 5.18.0-rc1+ #37 [ 33.532482] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014 [ 33.532484] Call Trace: [ 33.532496] [ 33.532500] dump_stack_lvl+0x45/0x5a [ 33.532506] bad_page.cold+0x63/0x94 [ 33.532510] free_pcp_prepare+0x290/0x420 [ 33.532515] free_unref_page+0x1b/0x100 [ 33.532518] skb_release_data+0x13f/0x1c0 [ 33.532524] kfree_skb_reason+0x3e/0xc0 [ 33.532527] ip6_mc_input+0x23c/0x2b0 [ 33.532531] ip6_sublist_rcv_finish+0x83/0x90 [ 33.532534] ip6_sublist_rcv+0x22b/0x2b0 [3] XDP program to reproduce(xdp_pass.c): #include #include SEC("xdp_pass") int xdp_pkt_pass(struct xdp_md *ctx) { bpf_xdp_adjust_head(ctx, -(int)32); return XDP_PASS; } char _license[] SEC("license") = "GPL"; compile: clang -O2 -g -Wall -target bpf -c xdp_pass.c -o xdp_pass.o load on virtio_net: ip link set enp1s0 xdpdrv obj xdp_pass.o sec xdp_pass CC: stable@vger.kernel.org CC: Jason Wang CC: Xuan Zhuo CC: Daniel Borkmann CC: "Michael S. Tsirkin" CC: virtualization@lists.linux-foundation.org Fixes: 8fb7da9e9907 ("virtio_net: get build_skb() buf by data ptr") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Xuan Zhuo Acked-by: Daniel Borkmann Acked-by: Michael S. Tsirkin Acked-by: Jason Wang Link: https://lore.kernel.org/r/20220425103703.3067292-1-razor@blackwall.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 10f24144ca488beed086ffc483e4ae5601b262f0 Author: Tejun Heo Date: Tue Apr 26 19:01:01 2022 -1000 iocost: don't reset the inuse weight of under-weighted debtors commit 8c936f9ea11ec4e35e288810a7503b5c841a355f upstream. When an iocg is in debt, its inuse weight is owned by debt handling and should stay at 1. This invariant was broken when determining the amount of surpluses at the beginning of donation calculation - when an iocg's hierarchical weight is too low, the iocg is excluded from donation calculation and its inuse is reset to its active regardless of its indebtedness, triggering warnings like the following: WARNING: CPU: 5 PID: 0 at block/blk-iocost.c:1416 iocg_kick_waitq+0x392/0x3a0 ... RIP: 0010:iocg_kick_waitq+0x392/0x3a0 Code: 00 00 be ff ff ff ff 48 89 4d a8 e8 98 b2 70 00 48 8b 4d a8 85 c0 0f 85 4a fe ff ff 0f 0b e9 43 fe ff ff 0f 0b e9 4d fe ff ff <0f> 0b e9 50 fe ff ff e8 a2 ae 70 00 66 90 0f 1f 44 00 00 55 48 89 RSP: 0018:ffffc90000200d08 EFLAGS: 00010016 ... ioc_timer_fn+0x2e0/0x1470 call_timer_fn+0xa1/0x2c0 ... As this happens only when an iocg's hierarchical weight is negligible, its impact likely is limited to triggering the warnings. Fix it by skipping resetting inuse of under-weighted debtors. Signed-off-by: Tejun Heo Reported-by: Rik van Riel Fixes: c421a3eb2e27 ("blk-iocost: revamp debt handling") Cc: stable@vger.kernel.org # v5.10+ Link: https://lore.kernel.org/r/YmjODd4aif9BzFuO@slm.duckdns.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 559d4f45958b0ad20020f69a9a9e2a18c73b95c2 Author: Thomas Gleixner Date: Thu Apr 28 15:50:54 2022 +0200 x86/pci/xen: Disable PCI/MSI[-X] masking for XEN_HVM guests commit 7e0815b3e09986d2fe651199363e135b9358132a upstream. When a XEN_HVM guest uses the XEN PIRQ/Eventchannel mechanism, then PCI/MSI[-X] masking is solely controlled by the hypervisor, but contrary to XEN_PV guests this does not disable PCI/MSI[-X] masking in the PCI/MSI layer. This can lead to a situation where the PCI/MSI layer masks an MSI[-X] interrupt and the hypervisor grants the write despite the fact that it already requested the interrupt. As a consequence interrupt delivery on the affected device is not happening ever. Set pci_msi_ignore_mask to prevent that like it's done for XEN_PV guests already. Fixes: 809f9267bbab ("xen: map MSIs into pirqs") Reported-by: Jeremi Piotrowski Reported-by: Dusty Mabe Reported-by: Salvatore Bonaccorso Signed-off-by: Thomas Gleixner Tested-by: Noah Meyerhans Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87tuaduxj5.ffs@tglx Signed-off-by: Greg Kroah-Hartman commit 95ad6bef5bf15f3f916b32033dc8c4e138168f08 Author: Guo Ren Date: Wed Apr 6 22:16:49 2022 +0800 riscv: patch_text: Fixup last cpu should be master commit 8ec1442953c66a1d8462cccd8c20b7ba561f5915 upstream. These patch_text implementations are using stop_machine_cpuslocked infrastructure with atomic cpu_count. The original idea: When the master CPU patch_text, the others should wait for it. But current implementation is using the first CPU as master, which couldn't guarantee the remaining CPUs are waiting. This patch changes the last CPU as the master to solve the potential risk. Signed-off-by: Guo Ren Signed-off-by: Guo Ren Acked-by: Palmer Dabbelt Reviewed-by: Masami Hiramatsu Fixes: 043cb41a85de ("riscv: introduce interfaces to patch kernel code") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 3437091fcc2ffb4ab861b5c6bc89c6f3e634b400 Author: Mikulas Patocka Date: Wed Apr 27 11:26:40 2022 -0400 hex2bin: fix access beyond string end commit e4d8a29997731b3bb14059024b24df9f784288d0 upstream. If we pass too short string to "hex2bin" (and the string size without the terminating NUL character is even), "hex2bin" reads one byte after the terminating NUL character. This patch fixes it. Note that hex_to_bin returns -1 on error and hex2bin return -EINVAL on error - so we can't just return the variable "hi" or "lo" on error. This inconsistency may be fixed in the next merge window, but for the purpose of fixing this bug, we just preserve the existing behavior and return -1 and -EINVAL. Signed-off-by: Mikulas Patocka Reviewed-by: Andy Shevchenko Fixes: b78049831ffe ("lib: add error checking to hex2bin") Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4541645b5881a5027343ddd26c34f3bf902744ef Author: Mikulas Patocka Date: Mon Apr 25 08:07:48 2022 -0400 hex2bin: make the function hex_to_bin constant-time commit e5be15767e7e284351853cbaba80cde8620341fb upstream. The function hex2bin is used to load cryptographic keys into device mapper targets dm-crypt and dm-integrity. It should take constant time independent on the processed data, so that concurrently running unprivileged code can't infer any information about the keys via microarchitectural convert channels. This patch changes the function hex_to_bin so that it contains no branches and no memory accesses. Note that this shouldn't cause performance degradation because the size of the new function is the same as the size of the old function (on x86-64) - and the new function causes no branch misprediction penalties. I compile-tested this function with gcc on aarch64 alpha arm hppa hppa64 i386 ia64 m68k mips32 mips64 powerpc powerpc64 riscv sh4 s390x sparc32 sparc64 x86_64 and with clang on aarch64 arm hexagon i386 mips32 mips64 powerpc powerpc64 s390x sparc32 sparc64 x86_64 to verify that there are no branches in the generated code. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 41dee18326170fa82ba0d9f815e30660ddee36b6 Author: Krzysztof Kozlowski Date: Wed Apr 20 16:14:07 2022 +0200 pinctrl: samsung: fix missing GPIOLIB on ARM64 Exynos config commit ac875df4d854ab13d9c4af682a1837a1214fecec upstream. The Samsung pinctrl drivers depend on OF_GPIO, which is part of GPIOLIB. ARMv7 Exynos platform selects GPIOLIB and Samsung pinctrl drivers. ARMv8 Exynos selects only the latter leading to possible wrong configuration on ARMv8 build: WARNING: unmet direct dependencies detected for PINCTRL_EXYNOS Depends on [n]: PINCTRL [=y] && OF_GPIO [=n] && (ARCH_EXYNOS [=y] || ARCH_S5PV210 || COMPILE_TEST [=y]) Selected by [y]: - ARCH_EXYNOS [=y] Always select the GPIOLIB from the Samsung pinctrl drivers to fix the issue. This requires removing of OF_GPIO dependency (to avoid recursive dependency), so add dependency on OF for COMPILE_TEST cases. Reported-by: Necip Fazil Yildiran Fixes: eed6b3eb20b9 ("arm64: Split out platform options to separate Kconfig") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20220420141407.470955-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit 8f2dac58b39e993ed0b359efe6bddbd7ad39253b Author: Johan Hovold Date: Mon Feb 28 11:16:17 2022 +0100 arm64: dts: imx8mm-venice: fix spi2 pin configuration commit dc900431337f5f861e3cc47ec5be5a69db40ee34 upstream. Due to what looks like a copy-paste error, the ECSPI2_MISO pad is not muxed for SPI mode and causes reads from a slave-device connected to the SPI header to always return zero. Configure the ECSPI2_MISO pad for SPI mode on the gw71xx, gw72xx and gw73xx families of boards that got this wrong. Fixes: 6f30b27c5ef5 ("arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits") Cc: stable@vger.kernel.org # 5.12 Cc: Tim Harvey Signed-off-by: Johan Hovold Acked-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 34b5d2aa355a8d57ec2fc5e83496c46b381eb8ed Author: Manivannan Sadhasivam Date: Fri Apr 8 20:30:39 2022 +0530 bus: mhi: host: pci_generic: Flush recovery worker during freeze commit c38f83bae4037023827c85e045841d0421f85034 upstream. It is possible that the recovery work might be running while the freeze gets executed (during hibernation etc.,). Currently, we don't powerdown the stack if it is not up but if the recovery work completes after freeze, then the device will be up afterwards. This will not be a sane situation. So let's flush the recovery worker before trying to powerdown the device. Cc: stable@vger.kernel.org Fixes: 5f0c2ee1fe8d ("bus: mhi: pci-generic: Fix hibernation") Reported-by: Bhaumik Vasav Bhatt Reviewed-by: Bhaumik Vasav Bhatt Link: https://lore.kernel.org/r/20220408150039.17297-1-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit b3d21deabcbeaf16e539ae5611655e45e4212ee0 Author: Manivannan Sadhasivam Date: Tue Apr 5 18:29:07 2022 +0530 bus: mhi: host: pci_generic: Add missing poweroff() PM callback commit e64d5fa5044f225ac87d96a7e4be11389999c4c6 upstream. During hibernation process, once thaw() stage completes, the MHI endpoint devices will be in M0 state post recovery. After that, the devices will be powered down so that the system can enter the target sleep state. During this stage, the PCI core will put the devices in D3hot. But this transition is allowed by the MHI spec. The devices can only enter D3hot when it is in M3 state. So for fixing this issue, let's add the poweroff() callback that will get executed before putting the system in target sleep state during hibernation. This callback will power down the device properly so that it could be restored during restore() or thaw() stage. Cc: stable@vger.kernel.org Fixes: 5f0c2ee1fe8d ("bus: mhi: pci-generic: Fix hibernation") Reported-by: Hemant Kumar Suggested-by: Hemant Kumar Link: https://lore.kernel.org/r/20220405125907.5644-1-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit 732f861dd4806111adf08818d20a6e1e5467e94d Author: Xiubo Li Date: Thu Apr 14 09:07:21 2022 +0800 ceph: fix possible NULL pointer dereference for req->r_session commit 7acae6183cf37c48b8da48bbbdb78820fb3913f3 upstream. The request will be inserted into the ci->i_unsafe_dirops before assigning the req->r_session, so it's possible that we will hit NULL pointer dereference bug here. Cc: stable@vger.kernel.org URL: https://tracker.ceph.com/issues/55327 Signed-off-by: Xiubo Li Reviewed-by: Jeff Layton Tested-by: Aaron Tomlin Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 2b008197a06b203208d9cd31ccabc3d24260b713 Author: Wang Qing Date: Sun Apr 10 19:36:19 2022 -0700 arch_topology: Do not set llc_sibling if llc_id is invalid commit 1dc9f1a66e1718479e1c4f95514e1750602a3cb9 upstream. When ACPI is not enabled, cpuid_topo->llc_id = cpu_topo->llc_id = -1, which will set llc_sibling 0xff(...), this is misleading. Don't set llc_sibling(default 0) if we don't know the cache topology. Reviewed-by: Sudeep Holla Signed-off-by: Wang Qing Fixes: 37c3ec2d810f ("arm64: topology: divorce MC scheduling domain from core_siblings") Cc: stable Link: https://lore.kernel.org/r/1649644580-54626-1-git-send-email-wangqing@vivo.com Signed-off-by: Greg Kroah-Hartman commit 03cab849da1ae2d386492e445f8b8104c9dec004 Author: Maciej W. Rozycki Date: Mon Apr 18 16:27:16 2022 +0100 serial: 8250: Correct the clock for EndRun PTP/1588 PCIe device commit 637674fa40059cddcc3ad2212728965072f62ea3 upstream. The EndRun PTP/1588 dual serial port device is based on the Oxford Semiconductor OXPCIe952 UART device with the PCI vendor:device ID set for EndRun Technologies and is therefore driven by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock. The clock rate is divided by the oversampling rate of 16 as it is supplied to the baud rate generator, yielding the baud base of 3906250. Replace the incorrect baud base of 4000000 with the right value of 3906250 then, complementing commit 6cbe45d8ac93 ("serial: 8250: Correct the clock for OxSemi PCIe devices"). Signed-off-by: Maciej W. Rozycki Cc: stable Fixes: 1bc8cde46a159 ("8250_pci: Added driver for Endrun Technologies PTP PCIe card.") Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181515270.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 9445505273a585928af56ff6f2e9b626e38aa3e3 Author: Maciej W. Rozycki Date: Mon Apr 18 16:27:10 2022 +0100 serial: 8250: Also set sticky MCR bits in console restoration commit 6e6eebdf5e2455f089ccd000754a0deaeb79af82 upstream. Sticky MCR bits are lost in console restoration if console suspending has been disabled. This currently affects the AFE bit, which works in combination with RTS which we set, so we want to make sure the UART retains control of its FIFO where previously requested. Also specific drivers may need other bits in the future. Signed-off-by: Maciej W. Rozycki Fixes: 4516d50aabed ("serial: 8250: Use canary to restart console after suspend") Cc: stable@vger.kernel.org # v4.0+ Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181518490.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit ac55cac5dcd4ab329e9b86d28d93b6a9a7a9d24a Author: Lino Sanfilippo Date: Sat Apr 9 01:35:02 2022 +0200 serial: amba-pl011: do not time out prematurely when draining tx fifo commit 0e4deb56b0c625efdb70c94f150429e2f2a16fa1 upstream. The current timeout for draining the tx fifo in RS485 mode is calculated by multiplying the time it takes to transmit one character (with the given baud rate) with the maximal number of characters in the tx queue. This timeout is too short for two reasons: First when calculating the time to transmit one character integer division is used which may round down the result in case of a remainder of the division. Fix this by rounding up the division result. Second the hardware may need additional time (e.g for first putting the characters from the fifo into the shift register) before the characters are actually put onto the wire. To be on the safe side double the current maximum number of iterations that are used to wait for the queue draining. Fixes: 8d479237727c ("serial: amba-pl011: add RS485 support") Cc: stable@vger.kernel.org Signed-off-by: Lino Sanfilippo Link: https://lore.kernel.org/r/20220408233503.7251-1-LinoSanfilippo@gmx.de Signed-off-by: Greg Kroah-Hartman commit 858d93280e83561997cc06f5318ac22464d2bae0 Author: Johan Hovold Date: Mon Apr 11 10:19:57 2022 +0200 serial: imx: fix overrun interrupts in DMA mode commit 3ee82c6e41f3d2212647ce0bc5a05a0f69097824 upstream. Commit 76821e222c18 ("serial: imx: ensure that RX irqs are off if RX is off") accidentally enabled overrun interrupts unconditionally when deferring DMA enable until after the receiver has been enabled during startup. Fix this by using the DMA-initialised instead of DMA-enabled flag to determine whether overrun interrupts should be enabled. Note that overrun interrupts are already accounted for in imx_uart_clear_rx_errors() when using DMA since commit 41d98b5da92f ("serial: imx-serial - update RX error counters when DMA is used"). Fixes: 76821e222c18 ("serial: imx: ensure that RX irqs are off if RX is off") Cc: stable@vger.kernel.org # 4.17 Cc: Uwe Kleine-König Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20220411081957.7846-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit c0ea202fbc855d60bc4a0603ca52a9e80654b327 Author: Sean Anderson Date: Mon Apr 25 13:14:09 2022 -0400 usb: phy: generic: Get the vbus supply commit 03e607cbb2931374db1825f371e9c7f28526d3f4 upstream. While support for working with a vbus was added, the regulator was never actually gotten (despite what was documented). Fix this by actually getting the supply from the device tree. Fixes: 7acc9973e3c4 ("usb: phy: generic: add vbus support") Cc: stable Signed-off-by: Sean Anderson Link: https://lore.kernel.org/r/20220425171412.1188485-3-sean.anderson@seco.com Signed-off-by: Greg Kroah-Hartman commit dd2af3ad968f6b7091f75613fbd4073b2c40231e Author: Pawel Laszczak Date: Tue Mar 29 10:46:05 2022 +0200 usb: cdns3: Fix issue for clear halt endpoint commit b3fa25de31fb7e9afebe9599b8ff32eda13d7c94 upstream. Path fixes bug which occurs during resetting endpoint in __cdns3_gadget_ep_clear_halt function. During resetting endpoint controller will change HW/DMA owned TRB. It set Abort flag in trb->control and will change trb->length field. If driver want to use the aborted trb it must update the changed field in TRB. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") cc: Acked-by: Peter Chen Signed-off-by: Pawel Laszczak Link: https://lore.kernel.org/r/20220329084605.4022-1-pawell@cadence.com Signed-off-by: Greg Kroah-Hartman commit 455285db8717f44864c057ed2d47a2e65eb420bf Author: Heikki Krogerus Date: Mon Apr 25 13:35:18 2022 +0300 usb: dwc3: pci: add support for the Intel Meteor Lake-P commit 973e0f7a847ef13ade840d4c30729ce329a66895 upstream. This patch adds the necessary PCI IDs for Intel Meteor Lake-P devices. Signed-off-by: Heikki Krogerus Cc: stable Link: https://lore.kernel.org/r/20220425103518.44028-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 0d1c407b1a7497104c57034f540bd549c234b004 Author: Thinh Nguyen Date: Fri Apr 22 17:36:28 2022 -0700 usb: dwc3: gadget: Return proper request status commit c7428dbddcf4ea1919e1c8e15f715b94ca359268 upstream. If the user sets the usb_request's no_interrupt, then there will be no completion event for the request. Currently the driver incorrectly uses the event status of a different request to report the status for a request with no_interrupt. The dwc3 driver needs to check the TRB status associated with the request when reporting its status. Note: this is only applicable to missed_isoc TRB completion status, but the other status are also listed for completeness/documentation. Fixes: 6d8a019614f3 ("usb: dwc3: gadget: check for Missed Isoc from event status") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/db2c80108286cfd108adb05bad52138b78d7c3a7.1650673655.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 7d14c96bff097ed67687a73fe4b5614a73910ac2 Author: Thinh Nguyen Date: Thu Apr 21 19:33:56 2022 -0700 usb: dwc3: core: Only handle soft-reset in DCTL commit f4fd84ae0765a80494b28c43b756a95100351a94 upstream. Make sure not to set run_stop bit or link state change request while initiating soft-reset. Register read-modify-write operation may unintentionally start the controller before the initialization completes with its previous DCTL value, which can cause initialization failure. Fixes: f59dcab17629 ("usb: dwc3: core: improve reset sequence") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/6aecbd78328f102003d40ccf18ceeebd411d3703.1650594792.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 5d8299ead7c56053ffceecb350f119a27973bf51 Author: Thinh Nguyen Date: Mon Apr 11 18:33:47 2022 -0700 usb: dwc3: core: Fix tx/rx threshold settings commit f28ad9069363dec7deb88032b70612755eed9ee6 upstream. The current driver logic checks against 0 to determine whether the periodic tx/rx threshold settings are set, but we may get bogus values from uninitialized variables if no device property is set. Properly default these variables to 0. Fixes: 938a5ad1d305 ("usb: dwc3: Check for ESS TX/RX threshold config") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/cccfce990b11b730b0dae42f9d217dc6fb988c90.1649727139.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit b81be940eacaae355ea9ee03400ae3033062502e Author: Sven Peter Date: Mon Apr 11 17:53:00 2022 +0200 usb: dwc3: Try usb-role-switch first in dwc3_drd_init commit ab7aa2866d295438dc60522f85c5421c6b4f1507 upstream. If the PHY controller node has a "port" dwc3 tries to find an extcon device even when "usb-role-switch" is present. This happens because dwc3_get_extcon() sees that "port" node and then calls extcon_find_edev_by_node() which will always return EPROBE_DEFER in that case. On the other hand, even if an extcon was present and dwc3_get_extcon() was successful it would still be ignored in favor of "usb-role-switch". Let's just first check if "usb-role-switch" is configured in the device tree and directly use it instead and only try to look for an extcon device otherwise. Fixes: 8a0a13799744 ("usb: dwc3: Registering a role switch in the DRD code.") Cc: stable Signed-off-by: Sven Peter Link: https://lore.kernel.org/r/20220411155300.9766-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman commit 9f051e510cd2a8192c91743d4a2f57227ee86246 Author: Vijayavardhan Vennapusa Date: Wed Apr 13 16:10:38 2022 -0500 usb: gadget: configfs: clear deactivation flag in configfs_composite_unbind() commit bf95c4d4630c7a2c16e7b424fdea5177d9ce0864 upstream. If any function like UVC is deactivating gadget as part of composition switch which results in not calling pullup enablement, it is not getting enabled after switch to new composition due to this deactivation flag not cleared. This results in USB enumeration not happening after switch to new USB composition. Hence clear deactivation flag inside gadget structure in configfs_composite_unbind() before switch to new USB composition. Signed-off-by: Vijayavardhan Vennapusa Signed-off-by: Dan Vacura Cc: stable Link: https://lore.kernel.org/r/20220413211038.72797-1-w36195@motorola.com Signed-off-by: Greg Kroah-Hartman commit f9b2660d9c10ddab94ff84aea1000a737bacd19f Author: Dan Vacura Date: Thu Mar 31 13:40:23 2022 -0500 usb: gadget: uvc: Fix crash when encoding data for usb request commit 71d471e3faf90c9674cadc7605ac719e82cb7fac upstream. During the uvcg_video_pump() process, if an error occurs and uvcg_queue_cancel() is called, the buffer queue will be cleared out, but the current marker (queue->buf_used) of the active buffer (no longer active) is not reset. On the next iteration of uvcg_video_pump() the stale buf_used count will be used and the logic of min((unsigned int)len, buf->bytesused - queue->buf_used) may incorrectly calculate a nbytes size, causing an invalid memory access. [80802.185460][ T315] configfs-gadget gadget: uvc: VS request completed with status -18. [80802.185519][ T315] configfs-gadget gadget: uvc: VS request completed with status -18. ... uvcg_queue_cancel() is called and the queue is cleared out, but the marker queue->buf_used is not reset. ... [80802.262328][ T8682] Unable to handle kernel paging request at virtual address ffffffc03af9f000 ... ... [80802.263138][ T8682] Call trace: [80802.263146][ T8682] __memcpy+0x12c/0x180 [80802.263155][ T8682] uvcg_video_pump+0xcc/0x1e0 [80802.263165][ T8682] process_one_work+0x2cc/0x568 [80802.263173][ T8682] worker_thread+0x28c/0x518 [80802.263181][ T8682] kthread+0x160/0x170 [80802.263188][ T8682] ret_from_fork+0x10/0x18 [80802.263198][ T8682] Code: a8c12829 a88130cb a8c130 Fixes: d692522577c0 ("usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework") Cc: Signed-off-by: Dan Vacura Link: https://lore.kernel.org/r/20220331184024.23918-1-w36195@motorola.com Signed-off-by: Greg Kroah-Hartman commit e5e7d6c4b305392324a56a491412ce25ca9a4229 Author: Heikki Krogerus Date: Tue Apr 5 16:48:24 2022 +0300 usb: typec: ucsi: Fix role swapping commit eb5d7ff3cf0d55093c619b5ad107cd5c05ce8134 upstream. All attempts to swap the roles timed out because the completion was done without releasing the port lock. Fixing that by releasing the lock before starting to wait for the completion. Link: https://lore.kernel.org/linux-usb/037de7ac-e210-bdf5-ec7a-8c0c88a0be20@gmail.com/ Fixes: ad74b8649bea ("usb: typec: ucsi: Preliminary support for alternate modes") Cc: stable@vger.kernel.org Reported-and-tested-by: Jia-Ju Bai Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20220405134824.68067-3-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 3e5dd4cf30fef724766d9d50019c78c8ad742a70 Author: Heikki Krogerus Date: Tue Apr 5 16:48:23 2022 +0300 usb: typec: ucsi: Fix reuse of completion structure commit e25adcca917d7e4cdc1dc6444d0692ffda7594bf upstream. The role swapping completion variable is reused, so it needs to be reinitialised every time. Otherwise it will be marked as done after the first time it's used and completing immediately. Link: https://lore.kernel.org/linux-usb/20220325203959.GA19752@jackp-linux.qualcomm.com/ Fixes: 6df475f804e6 ("usb: typec: ucsi: Start using struct typec_operations") Cc: stable@vger.kernel.org Reported-and-suggested-by: Jack Pham Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20220405134824.68067-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 6bf55f6b0ebf0bf5d36634e14d5b1099e039bd36 Author: Tasos Sahanidis Date: Fri Apr 1 00:47:00 2022 +0300 usb: core: Don't hold the device lock while sleeping in do_proc_control() commit 0543e4e8852ef5ff1809ae62f1ea963e2ab23b66 upstream. Since commit ae8709b296d8 ("USB: core: Make do_proc_control() and do_proc_bulk() killable") if a device has the USB_QUIRK_DELAY_CTRL_MSG quirk set, it will temporarily block all other URBs (e.g. interrupts) while sleeping due to a control. This results in noticeable delays when, for example, a userspace usbfs application is sending URB interrupts at a high rate to a keyboard and simultaneously updates the lock indicators using controls. Interrupts with direction set to IN are also affected by this, meaning that delivery of HID reports (containing scancodes) to the usbfs application is delayed as well. This patch fixes the regression by calling msleep() while the device mutex is unlocked, as was the case originally with usb_control_msg(). Fixes: ae8709b296d8 ("USB: core: Make do_proc_control() and do_proc_bulk() killable") Cc: stable Acked-by: Alan Stern Signed-off-by: Tasos Sahanidis Link: https://lore.kernel.org/r/3e299e2a-13b9-ddff-7fee-6845e868bc06@tasossah.com Signed-off-by: Greg Kroah-Hartman commit 949d422949eeea528357b7b264f08770a2730a8f Author: Hangyu Hua Date: Thu Apr 7 10:40:01 2022 +0800 usb: misc: fix improper handling of refcount in uss720_probe() commit 0a96fa640dc928da9eaa46a22c46521b037b78ad upstream. usb_put_dev shouldn't be called when uss720_probe succeeds because of priv->usbdev. At the same time, priv->usbdev shouldn't be set to NULL before destroy_priv in uss720_disconnect because usb_put_dev is in destroy_priv. Fix this by moving priv->usbdev = NULL after usb_put_dev. Fixes: dcb4b8ad6a44 ("misc/uss720: fix memory leak in uss720_probe") Cc: stable Reviewed-by: Dongliang Mu Signed-off-by: Hangyu Hua Link: https://lore.kernel.org/r/20220407024001.11761-1-hbh25y@gmail.com Signed-off-by: Greg Kroah-Hartman commit a590353a95060c2f32501a23e295db059640e032 Author: Fawzi Khaber Date: Mon Apr 11 13:15:33 2022 +0200 iio: imu: inv_icm42600: Fix I2C init possible nack commit b5d6ba09b10d2ccb865ed9bc45941db0a41c6756 upstream. This register write to REG_INTF_CONFIG6 enables a spike filter that is impacting the line and can prevent the I2C ACK to be seen by the controller. So we don't test the return value. Fixes: 7297ef1e261672b8 ("iio: imu: inv_icm42600: add I2C driver") Signed-off-by: Fawzi Khaber Signed-off-by: Jean-Baptiste Maneyrol Link: https://lore.kernel.org/r/20220411111533.5826-1-jmaneyrol@invensense.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7619f3c498a2f89a524d58b8af2e313adbca5f47 Author: Zheyu Ma Date: Sat Apr 9 11:48:49 2022 +0800 iio: magnetometer: ak8975: Fix the error handling in ak8975_power_on() commit 3a26787dacf04257a68b16315c984eb2c340bc5e upstream. When the driver fails to enable the regulator 'vid', we will get the following splat: [ 79.955610] WARNING: CPU: 5 PID: 441 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0 [ 79.959641] RIP: 0010:_regulator_put+0x3ec/0x4e0 [ 79.967570] Call Trace: [ 79.967773] [ 79.967951] regulator_put+0x1f/0x30 [ 79.968254] devres_release_group+0x319/0x3d0 [ 79.968608] i2c_device_probe+0x766/0x940 Fix this by disabling the 'vdd' regulator when failing to enable 'vid' regulator. Signed-off-by: Zheyu Ma Link: https://lore.kernel.org/r/20220409034849.3717231-2-zheyuma97@gmail.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 28e1f974e3e751beffbcc2a2f8b299b48d953e48 Author: Michael Hennerich Date: Wed Apr 6 12:56:20 2022 +0200 iio: dac: ad5446: Fix read_raw not returning set value commit 89a01cd688d3c0ac983ef0b0e5f40018ab768317 upstream. read_raw should return the un-scaled value. Fixes: 5e06bdfb46e8b ("staging:iio:dac:ad5446: Return cached value for 'raw' attribute") Signed-off-by: Michael Hennerich Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20220406105620.1171340-1-michael.hennerich@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cd266c38aaa4d81a42de7cc3370a9a1c7ebdd0d2 Author: Zizhuang Deng Date: Thu Mar 10 20:54:50 2022 +0800 iio: dac: ad5592r: Fix the missing return value. commit b55b38f7cc12da3b9ef36e7a3b7f8f96737df4d5 upstream. The third call to `fwnode_property_read_u32` did not record the return value, resulting in `channel_offstate` possibly being assigned the wrong value. Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs") Signed-off-by: Zizhuang Deng Link: https://lore.kernel.org/r/20220310125450.4164164-1-sunsetdzz@gmail.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 48bc03979f3044658c36e176812ade5b5eb29d85 Author: Mathias Nyman Date: Fri Apr 8 16:48:23 2022 +0300 xhci: increase usb U3 -> U0 link resume timeout from 100ms to 500ms commit 33597f0c48be0836854d43c577e35c8f8a765a7d upstream. The first U3 wake signal by the host may be lost if the USB 3 connection is tunneled over USB4, with a runtime suspended USB4 host, and firmware implemented connection manager. Specs state the host must wait 100ms (tU3WakeupRetryDelay) before resending a U3 wake signal if device doesn't respond, leading to U3 -> U0 link transition times around 270ms in the tunneled case. Fixes: 0200b9f790b0 ("xhci: Wait until link state trainsits to U0 after setting USB_SS_PORT_LS_U0") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20220408134823.2527272-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9faa311f65b05b9236cd444335c9186d15a3b25c Author: Henry Lin Date: Fri Apr 8 16:48:22 2022 +0300 xhci: stop polling roothubs after shutdown commit dc92944a014cd6a6f6c94299aaa36164dd2c238a upstream. While rebooting, XHCI controller and its bus device will be shut down in order by .shutdown callback. Stopping roothubs polling in xhci_shutdown() can prevent XHCI driver from accessing port status after its bus device shutdown. Take PCIe XHCI controller as example, if XHCI driver doesn't stop roothubs polling, XHCI driver may access PCIe BAR register for port status after parent PCIe root port driver is shutdown and cause PCIe bus error. [check shared hcd exist before stopping its roothub polling -Mathias] Cc: stable@vger.kernel.org Signed-off-by: Henry Lin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20220408134823.2527272-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 10e0d30f99f4e1506ca4910a78422c2958887cd5 Author: Evan Green Date: Fri Apr 8 11:42:50 2022 -0700 xhci: Enable runtime PM on second Alderlake controller commit d8bfe5091d6cc4b8b8395e4666979ae72a6069ca upstream. Alderlake has two XHCI controllers with PCI IDs 0x461e and 0x51ed. We had previously added the quirk to default enable runtime PM for 0x461e, now add it for 0x51ed as well. Signed-off-by: Evan Green Cc: stable Link: https://lore.kernel.org/r/20220408114225.1.Ibcff6b86ed4eacfe4c4bc89c90e18416f3900a3e@changeid Signed-off-by: Greg Kroah-Hartman commit 576b40690e91dca50ec753c515a8a7fbb1a58849 Author: zhangqilong Date: Sat Mar 19 10:38:22 2022 +0800 usb: xhci: tegra:Fix PM usage reference leak of tegra_xusb_unpowergate_partitions commit 8771039482d965bdc8cefd972bcabac2b76944a8 upstream. pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 41a7426d25fa ("usb: xhci: tegra: Unlink power domain devices") Cc: stable Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20220319023822.145641-1-zhangqilong3@huawei.com Signed-off-by: Greg Kroah-Hartman commit 4ebf2982db15f3756dab6f5962995015ff082e5e Author: Daniele Palmas Date: Wed Apr 6 16:14:08 2022 +0200 USB: serial: option: add Telit 0x1057, 0x1058, 0x1075 compositions commit f32c5a0423400e01f4d7c607949fa3a1f006e8fa upstream. Add support for the following Telit FN980 and FN990 compositions: 0x1057: tty, adb, rmnet, tty, tty, tty, tty, tty 0x1058: tty, adb, tty, tty, tty, tty, tty 0x1075: adb, tty Signed-off-by: Daniele Palmas Link: https://lore.kernel.org/r/20220406141408.580669-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit be94d697baab648c8734f61fa10b28fad0beaed6 Author: Slark Xiao Date: Thu Apr 14 15:44:34 2022 +0800 USB: serial: option: add support for Cinterion MV32-WA/MV32-WB commit b4a64ed6e7b857317070fcb9d87ff5d4a73be3e8 upstream. Add support for Cinterion device MV32-WA/MV32-WB. MV32-WA PID is 0x00F1, and MV32-WB PID is 0x00F2. Test evidence as below: T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=1e2d ProdID=00f1 Rev=05.04 S: Manufacturer=Cinterion S: Product=Cinterion PID 0x00F1 USB Mobile Broadband S: SerialNumber=78ada8c4 C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option I: If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=1e2d ProdID=00f2 Rev=05.04 S: Manufacturer=Cinterion S: Product=Cinterion PID 0x00F2 USB Mobile Broadband S: SerialNumber=cdd06a78 C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option I: If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option Interface 0&1: MBIM, 2:Modem, 3: GNSS, 4: NMEA, 5: Diag GNSS port don't use serial driver. Signed-off-by: Slark Xiao Link: https://lore.kernel.org/r/20220414074434.5699-1-slark_xiao@163.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit bb73ae98f086b74a1b765de7fbc7b36855e3a11c Author: Bruno Thomsen Date: Thu Apr 14 10:12:02 2022 +0200 USB: serial: cp210x: add PIDs for Kamstrup USB Meter Reader commit 35a923a0b329c343e9e81d79518e2937eba06fcd upstream. Wireless reading of water and heat meters using 868 MHz wM-Bus mode C1. The two different product IDs allow detection of dongle antenna solution: - Internal antenna - External antenna using SMA connector https://www.kamstrup.com/en-en/water-solutions/water-meter-reading/usb-meter-reader Signed-off-by: Bruno Thomsen Link: https://lore.kernel.org/r/20220414081202.5591-1-bruno.thomsen@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f183708e8ecc323413a57303154b17ec4a24eb30 Author: Kees Cook Date: Wed Apr 20 17:12:34 2022 -0700 USB: serial: whiteheat: fix heap overflow in WHITEHEAT_GET_DTR_RTS commit e23e50e7acc8d8f16498e9c129db33e6a00e80eb upstream. The sizeof(struct whitehat_dr_info) can be 4 bytes under CONFIG_AEABI=n due to "-mabi=apcs-gnu", even though it has a single u8: whiteheat_private { __u8 mcr; /* 0 1 */ /* size: 4, cachelines: 1, members: 1 */ /* padding: 3 */ /* last cacheline: 4 bytes */ }; The result is technically harmless, as both the source and the destinations are currently the same allocation size (4 bytes) and don't use their padding, but if anything were to ever be added after the "mcr" member in "struct whiteheat_private", it would be overwritten. The structs both have a single u8 "mcr" member, but are 4 bytes in padded size. The memcpy() destination was explicitly targeting the u8 member (size 1) with the length of the whole structure (size 4), triggering the memcpy buffer overflow warning: In file included from include/linux/string.h:253, from include/linux/bitmap.h:11, from include/linux/cpumask.h:12, from include/linux/smp.h:13, from include/linux/lockdep.h:14, from include/linux/spinlock.h:62, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/slab.h:15, from drivers/usb/serial/whiteheat.c:17: In function 'fortify_memcpy_chk', inlined from 'firm_send_command' at drivers/usb/serial/whiteheat.c:587:4: include/linux/fortify-string.h:328:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] 328 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Instead, just assign the one byte directly. Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/202204142318.vDqjjSFn-lkp@intel.com Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220421001234.2421107-1-keescook@chromium.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 7f8fc606893c04aafd3e496d6b964a89f6122e2e Author: Oliver Neukum Date: Thu Apr 14 14:31:52 2022 +0200 USB: quirks: add STRING quirk for VCOM device commit ec547af8a9ea6441864bad34172676b5652ceb96 upstream. This has been reported to stall if queried Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20220414123152.1700-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 96a5999e1f620377f874dc0b2b7146720b65fec8 Author: Oliver Neukum Date: Thu Apr 14 13:02:09 2022 +0200 USB: quirks: add a Realtek card reader commit 2a7ccf6bb6f147f64c025ad68f4255d8e1e0ce6d upstream. This device is reported to stall when enummerated. Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20220414110209.30924-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 0da0ac8941293dcb3fbdef12a5fd7fd0ab416ca6 Author: Macpaul Lin Date: Tue Apr 19 16:12:45 2022 +0800 usb: mtu3: fix USB 3.0 dual-role-switch from device to host commit 456244aeecd54249096362a173dfe06b82a5cafa upstream. Issue description: When an OTG port has been switched to device role and then switch back to host role again, the USB 3.0 Host (XHCI) will not be able to detect "plug in event of a connected USB 2.0/1.0 ((Highspeed and Fullspeed) devices until system reboot. Root cause and Solution: There is a condition checking flag "ssusb->otg_switch.is_u3_drd" in toggle_opstate(). At the end of role switch procedure, toggle_opstate() will be called to set DC_SESSION and SOFT_CONN bit. If "is_u3_drd" was set and switched the role to USB host 3.0, bit DC_SESSION and SOFT_CONN will be skipped hence caused the port cannot detect connected USB 2.0 (Highspeed and Fullspeed) devices. Simply remove the condition check to solve this issue. Fixes: d0ed062a8b75 ("usb: mtu3: dual-role mode support") Cc: stable@vger.kernel.org Tested-by: Fabien Parent Reviewed-by: Chunfeng Yun Signed-off-by: Macpaul Lin Signed-off-by: Tainping Fang Link: https://lore.kernel.org/r/20220419081245.21015-1-macpaul.lin@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 4bf7f350c1638def0caa1835ad92948c15853916 Author: Greg Kroah-Hartman Date: Sun May 1 17:22:35 2022 +0200 Linux 5.15.37 Link: https://lore.kernel.org/r/20220429104052.345760505@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Ron Economos Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit f59e6886cafbd83ead79745f66ce6b7b3d47b2bc Author: Kumar Kartikeya Dwivedi Date: Sun Feb 20 08:01:38 2022 +0530 selftests/bpf: Add test for reg2btf_ids out of bounds access commit 13c6a37d409db9abc9c0bfc6d0a2f07bf0fff60e upstream. This test tries to pass a PTR_TO_BTF_ID_OR_NULL to the release function, which would trigger a out of bounds access without the fix in commit 45ce4b4f9009 ("bpf: Fix crash due to out of bounds access into reg2btf_ids.") but after the fix, it should only index using base_type(reg->type), which should be less than __BPF_REG_TYPE_MAX, and also not permit any type flags to be set for the reg->type. Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20220220023138.2224652-1-memxor@gmail.com Signed-off-by: Greg Kroah-Hartman commit dcecd95a135704b56b1b6b8a0e62136a99db712c Author: Linus Torvalds Date: Fri Apr 15 06:28:56 2022 +0800 mm: gup: make fault_in_safe_writeable() use fixup_user_fault() commit fe673d3f5bf1fc50cdc4b754831db91a2ec10126 upstream Instead of using GUP, make fault_in_safe_writeable() actually force a 'handle_mm_fault()' using the same fixup_user_fault() machinery that futexes already use. Using the GUP machinery meant that fault_in_safe_writeable() did not do everything that a real fault would do, ranging from not auto-expanding the stack segment, to not updating accessed or dirty flags in the page tables (GUP sets those flags on the pages themselves). The latter causes problems on architectures (like s390) that do accessed bit handling in software, which meant that fault_in_safe_writeable() didn't actually do all the fault handling it needed to, and trying to access the user address afterwards would still cause faults. Reported-and-tested-by: Andreas Gruenbacher Fixes: cdd591fc86e3 ("iov_iter: Introduce fault_in_iov_iter_writeable") Link: https://lore.kernel.org/all/CAHc6FU5nP+nziNGG0JAF1FUx-GV7kKFvM7aZuU_XD2_1v4vnvg@mail.gmail.com/ Acked-by: David Hildenbrand Signed-off-by: Linus Torvalds Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 4a0123bdb064e1ed58ab5e7df3cdbff840b2194a Author: Filipe Manana Date: Fri Apr 15 06:28:55 2022 +0800 btrfs: fallback to blocking mode when doing async dio over multiple extents commit ca93e44bfb5fd7996b76f0f544999171f647f93b upstream Some users recently reported that MariaDB was getting a read corruption when using io_uring on top of btrfs. This started to happen in 5.16, after commit 51bd9563b6783d ("btrfs: fix deadlock due to page faults during direct IO reads and writes"). That changed btrfs to use the new iomap flag IOMAP_DIO_PARTIAL and to disable page faults before calling iomap_dio_rw(). This was necessary to fix deadlocks when the iovector corresponds to a memory mapped file region. That type of scenario is exercised by test case generic/647 from fstests. For this MariaDB scenario, we attempt to read 16K from file offset X using IOCB_NOWAIT and io_uring. In that range we have 4 extents, each with a size of 4K, and what happens is the following: 1) btrfs_direct_read() disables page faults and calls iomap_dio_rw(); 2) iomap creates a struct iomap_dio object, its reference count is initialized to 1 and its ->size field is initialized to 0; 3) iomap calls btrfs_dio_iomap_begin() with file offset X, which finds the first 4K extent, and setups an iomap for this extent consisting of a single page; 4) At iomap_dio_bio_iter(), we are able to access the first page of the buffer (struct iov_iter) with bio_iov_iter_get_pages() without triggering a page fault; 5) iomap submits a bio for this 4K extent (iomap_dio_submit_bio() -> btrfs_submit_direct()) and increments the refcount on the struct iomap_dio object to 2; The ->size field of the struct iomap_dio object is incremented to 4K; 6) iomap calls btrfs_iomap_begin() again, this time with a file offset of X + 4K. There we setup an iomap for the next extent that also has a size of 4K; 7) Then at iomap_dio_bio_iter() we call bio_iov_iter_get_pages(), which tries to access the next page (2nd page) of the buffer. This triggers a page fault and returns -EFAULT; 8) At __iomap_dio_rw() we see the -EFAULT, but we reset the error to 0 because we passed the flag IOMAP_DIO_PARTIAL to iomap and the struct iomap_dio object has a ->size value of 4K (we submitted a bio for an extent already). The 'wait_for_completion' variable is not set to true, because our iocb has IOCB_NOWAIT set; 9) At the bottom of __iomap_dio_rw(), we decrement the reference count of the struct iomap_dio object from 2 to 1. Because we were not the only ones holding a reference on it and 'wait_for_completion' is set to false, -EIOCBQUEUED is returned to btrfs_direct_read(), which just returns it up the callchain, up to io_uring; 10) The bio submitted for the first extent (step 5) completes and its bio endio function, iomap_dio_bio_end_io(), decrements the last reference on the struct iomap_dio object, resulting in calling iomap_dio_complete_work() -> iomap_dio_complete(). 11) At iomap_dio_complete() we adjust the iocb->ki_pos from X to X + 4K and return 4K (the amount of io done) to iomap_dio_complete_work(); 12) iomap_dio_complete_work() calls the iocb completion callback, iocb->ki_complete() with a second argument value of 4K (total io done) and the iocb with the adjust ki_pos of X + 4K. This results in completing the read request for io_uring, leaving it with a result of 4K bytes read, and only the first page of the buffer filled in, while the remaining 3 pages, corresponding to the other 3 extents, were not filled; 13) For the application, the result is unexpected because if we ask to read N bytes, it expects to get N bytes read as long as those N bytes don't cross the EOF (i_size). MariaDB reports this as an error, as it's not expecting a short read, since it knows it's asking for read operations fully within the i_size boundary. This is typical in many applications, but it may also be questionable if they should react to such short reads by issuing more read calls to get the remaining data. Nevertheless, the short read happened due to a change in btrfs regarding how it deals with page faults while in the middle of a read operation, and there's no reason why btrfs can't have the previous behaviour of returning the whole data that was requested by the application. The problem can also be triggered with the following simple program: /* Get O_DIRECT */ #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif #include #include #include #include #include #include #include int main(int argc, char *argv[]) { char *foo_path; struct io_uring ring; struct io_uring_sqe *sqe; struct io_uring_cqe *cqe; struct iovec iovec; int fd; long pagesize; void *write_buf; void *read_buf; ssize_t ret; int i; if (argc != 2) { fprintf(stderr, "Use: %s \n", argv[0]); return 1; } foo_path = malloc(strlen(argv[1]) + 5); if (!foo_path) { fprintf(stderr, "Failed to allocate memory for file path\n"); return 1; } strcpy(foo_path, argv[1]); strcat(foo_path, "/foo"); /* * Create file foo with 2 extents, each with a size matching * the page size. Then allocate a buffer to read both extents * with io_uring, using O_DIRECT and IOCB_NOWAIT. Before doing * the read with io_uring, access the first page of the buffer * to fault it in, so that during the read we only trigger a * page fault when accessing the second page of the buffer. */ fd = open(foo_path, O_CREAT | O_TRUNC | O_WRONLY | O_DIRECT, 0666); if (fd == -1) { fprintf(stderr, "Failed to create file 'foo': %s (errno %d)", strerror(errno), errno); return 1; } pagesize = sysconf(_SC_PAGE_SIZE); ret = posix_memalign(&write_buf, pagesize, 2 * pagesize); if (ret) { fprintf(stderr, "Failed to allocate write buffer\n"); return 1; } memset(write_buf, 0xab, pagesize); memset(write_buf + pagesize, 0xcd, pagesize); /* Create 2 extents, each with a size matching page size. */ for (i = 0; i < 2; i++) { ret = pwrite(fd, write_buf + i * pagesize, pagesize, i * pagesize); if (ret != pagesize) { fprintf(stderr, "Failed to write to file, ret = %ld errno %d (%s)\n", ret, errno, strerror(errno)); return 1; } ret = fsync(fd); if (ret != 0) { fprintf(stderr, "Failed to fsync file\n"); return 1; } } close(fd); fd = open(foo_path, O_RDONLY | O_DIRECT); if (fd == -1) { fprintf(stderr, "Failed to open file 'foo': %s (errno %d)", strerror(errno), errno); return 1; } ret = posix_memalign(&read_buf, pagesize, 2 * pagesize); if (ret) { fprintf(stderr, "Failed to allocate read buffer\n"); return 1; } /* * Fault in only the first page of the read buffer. * We want to trigger a page fault for the 2nd page of the * read buffer during the read operation with io_uring * (O_DIRECT and IOCB_NOWAIT). */ memset(read_buf, 0, 1); ret = io_uring_queue_init(1, &ring, 0); if (ret != 0) { fprintf(stderr, "Failed to create io_uring queue\n"); return 1; } sqe = io_uring_get_sqe(&ring); if (!sqe) { fprintf(stderr, "Failed to get io_uring sqe\n"); return 1; } iovec.iov_base = read_buf; iovec.iov_len = 2 * pagesize; io_uring_prep_readv(sqe, fd, &iovec, 1, 0); ret = io_uring_submit_and_wait(&ring, 1); if (ret != 1) { fprintf(stderr, "Failed at io_uring_submit_and_wait()\n"); return 1; } ret = io_uring_wait_cqe(&ring, &cqe); if (ret < 0) { fprintf(stderr, "Failed at io_uring_wait_cqe()\n"); return 1; } printf("io_uring read result for file foo:\n\n"); printf(" cqe->res == %d (expected %d)\n", cqe->res, 2 * pagesize); printf(" memcmp(read_buf, write_buf) == %d (expected 0)\n", memcmp(read_buf, write_buf, 2 * pagesize)); io_uring_cqe_seen(&ring, cqe); io_uring_queue_exit(&ring); return 0; } When running it on an unpatched kernel: $ gcc io_uring_test.c -luring $ mkfs.btrfs -f /dev/sda $ mount /dev/sda /mnt/sda $ ./a.out /mnt/sda io_uring read result for file foo: cqe->res == 4096 (expected 8192) memcmp(read_buf, write_buf) == -205 (expected 0) After this patch, the read always returns 8192 bytes, with the buffer filled with the correct data. Although that reproducer always triggers the bug in my test vms, it's possible that it will not be so reliable on other environments, as that can happen if the bio for the first extent completes and decrements the reference on the struct iomap_dio object before we do the atomic_dec_and_test() on the reference at __iomap_dio_rw(). Fix this in btrfs by having btrfs_dio_iomap_begin() return -EAGAIN whenever we try to satisfy a non blocking IO request (IOMAP_NOWAIT flag set) over a range that spans multiple extents (or a mix of extents and holes). This avoids returning success to the caller when we only did partial IO, which is not optimal for writes and for reads it's actually incorrect, as the caller doesn't expect to get less bytes read than it has requested (unless EOF is crossed), as previously mentioned. This is also the type of behaviour that xfs follows (xfs_direct_write_iomap_begin()), even though it doesn't use IOMAP_DIO_PARTIAL. A test case for fstests will follow soon. Link: https://lore.kernel.org/linux-btrfs/CABVffEM0eEWho+206m470rtM0d9J8ue85TtR-A_oVTuGLWFicA@mail.gmail.com/ Link: https://lore.kernel.org/linux-btrfs/CAHF2GV6U32gmqSjLe=XKgfcZAmLCiH26cJ2OnHGp5x=VAH4OHQ@mail.gmail.com/ CC: stable@vger.kernel.org # 5.16+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit c81c4f566660ba66714e0c939dd0c397c7519109 Author: Filipe Manana Date: Fri Apr 15 06:28:54 2022 +0800 btrfs: fix deadlock due to page faults during direct IO reads and writes commit 51bd9563b6783de8315f38f7baed949e77c42311 upstream If we do a direct IO read or write when the buffer given by the user is memory mapped to the file range we are going to do IO, we end up ending in a deadlock. This is triggered by the new test case generic/647 from fstests. For a direct IO read we get a trace like this: [967.872718] INFO: task mmap-rw-fault:12176 blocked for more than 120 seconds. [967.874161] Not tainted 5.14.0-rc7-btrfs-next-95 #1 [967.874909] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [967.875983] task:mmap-rw-fault state:D stack: 0 pid:12176 ppid: 11884 flags:0x00000000 [967.875992] Call Trace: [967.875999] __schedule+0x3ca/0xe10 [967.876015] schedule+0x43/0xe0 [967.876020] wait_extent_bit.constprop.0+0x1eb/0x260 [btrfs] [967.876109] ? do_wait_intr_irq+0xb0/0xb0 [967.876118] lock_extent_bits+0x37/0x90 [btrfs] [967.876150] btrfs_lock_and_flush_ordered_range+0xa9/0x120 [btrfs] [967.876184] ? extent_readahead+0xa7/0x530 [btrfs] [967.876214] extent_readahead+0x32d/0x530 [btrfs] [967.876253] ? lru_cache_add+0x104/0x220 [967.876255] ? kvm_sched_clock_read+0x14/0x40 [967.876258] ? sched_clock_cpu+0xd/0x110 [967.876263] ? lock_release+0x155/0x4a0 [967.876271] read_pages+0x86/0x270 [967.876274] ? lru_cache_add+0x125/0x220 [967.876281] page_cache_ra_unbounded+0x1a3/0x220 [967.876291] filemap_fault+0x626/0xa20 [967.876303] __do_fault+0x36/0xf0 [967.876308] __handle_mm_fault+0x83f/0x15f0 [967.876322] handle_mm_fault+0x9e/0x260 [967.876327] __get_user_pages+0x204/0x620 [967.876332] ? get_user_pages_unlocked+0x69/0x340 [967.876340] get_user_pages_unlocked+0xd3/0x340 [967.876349] internal_get_user_pages_fast+0xbca/0xdc0 [967.876366] iov_iter_get_pages+0x8d/0x3a0 [967.876374] bio_iov_iter_get_pages+0x82/0x4a0 [967.876379] ? lock_release+0x155/0x4a0 [967.876387] iomap_dio_bio_actor+0x232/0x410 [967.876396] iomap_apply+0x12a/0x4a0 [967.876398] ? iomap_dio_rw+0x30/0x30 [967.876414] __iomap_dio_rw+0x29f/0x5e0 [967.876415] ? iomap_dio_rw+0x30/0x30 [967.876420] ? lock_acquired+0xf3/0x420 [967.876429] iomap_dio_rw+0xa/0x30 [967.876431] btrfs_file_read_iter+0x10b/0x140 [btrfs] [967.876460] new_sync_read+0x118/0x1a0 [967.876472] vfs_read+0x128/0x1b0 [967.876477] __x64_sys_pread64+0x90/0xc0 [967.876483] do_syscall_64+0x3b/0xc0 [967.876487] entry_SYSCALL_64_after_hwframe+0x44/0xae [967.876490] RIP: 0033:0x7fb6f2c038d6 [967.876493] RSP: 002b:00007fffddf586b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000011 [967.876496] RAX: ffffffffffffffda RBX: 0000000000001000 RCX: 00007fb6f2c038d6 [967.876498] RDX: 0000000000001000 RSI: 00007fb6f2c17000 RDI: 0000000000000003 [967.876499] RBP: 0000000000001000 R08: 0000000000000003 R09: 0000000000000000 [967.876501] R10: 0000000000001000 R11: 0000000000000246 R12: 0000000000000003 [967.876502] R13: 0000000000000000 R14: 00007fb6f2c17000 R15: 0000000000000000 This happens because at btrfs_dio_iomap_begin() we lock the extent range and return with it locked - we only unlock in the endio callback, at end_bio_extent_readpage() -> endio_readpage_release_extent(). Then after iomap called the btrfs_dio_iomap_begin() callback, it triggers the page faults that resulting in reading the pages, through the readahead callback btrfs_readahead(), and through there we end to attempt to lock again the same extent range (or a subrange of what we locked before), resulting in the deadlock. For a direct IO write, the scenario is a bit different, and it results in trace like this: [1132.442520] run fstests generic/647 at 2021-08-31 18:53:35 [1330.349355] INFO: task mmap-rw-fault:184017 blocked for more than 120 seconds. [1330.350540] Not tainted 5.14.0-rc7-btrfs-next-95 #1 [1330.351158] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [1330.351900] task:mmap-rw-fault state:D stack: 0 pid:184017 ppid:183725 flags:0x00000000 [1330.351906] Call Trace: [1330.351913] __schedule+0x3ca/0xe10 [1330.351930] schedule+0x43/0xe0 [1330.351935] btrfs_start_ordered_extent+0x108/0x1c0 [btrfs] [1330.352020] ? do_wait_intr_irq+0xb0/0xb0 [1330.352028] btrfs_lock_and_flush_ordered_range+0x8c/0x120 [btrfs] [1330.352064] ? extent_readahead+0xa7/0x530 [btrfs] [1330.352094] extent_readahead+0x32d/0x530 [btrfs] [1330.352133] ? lru_cache_add+0x104/0x220 [1330.352135] ? kvm_sched_clock_read+0x14/0x40 [1330.352138] ? sched_clock_cpu+0xd/0x110 [1330.352143] ? lock_release+0x155/0x4a0 [1330.352151] read_pages+0x86/0x270 [1330.352155] ? lru_cache_add+0x125/0x220 [1330.352162] page_cache_ra_unbounded+0x1a3/0x220 [1330.352172] filemap_fault+0x626/0xa20 [1330.352176] ? filemap_map_pages+0x18b/0x660 [1330.352184] __do_fault+0x36/0xf0 [1330.352189] __handle_mm_fault+0x1253/0x15f0 [1330.352203] handle_mm_fault+0x9e/0x260 [1330.352208] __get_user_pages+0x204/0x620 [1330.352212] ? get_user_pages_unlocked+0x69/0x340 [1330.352220] get_user_pages_unlocked+0xd3/0x340 [1330.352229] internal_get_user_pages_fast+0xbca/0xdc0 [1330.352246] iov_iter_get_pages+0x8d/0x3a0 [1330.352254] bio_iov_iter_get_pages+0x82/0x4a0 [1330.352259] ? lock_release+0x155/0x4a0 [1330.352266] iomap_dio_bio_actor+0x232/0x410 [1330.352275] iomap_apply+0x12a/0x4a0 [1330.352278] ? iomap_dio_rw+0x30/0x30 [1330.352292] __iomap_dio_rw+0x29f/0x5e0 [1330.352294] ? iomap_dio_rw+0x30/0x30 [1330.352306] btrfs_file_write_iter+0x238/0x480 [btrfs] [1330.352339] new_sync_write+0x11f/0x1b0 [1330.352344] ? NF_HOOK_LIST.constprop.0.cold+0x31/0x3e [1330.352354] vfs_write+0x292/0x3c0 [1330.352359] __x64_sys_pwrite64+0x90/0xc0 [1330.352365] do_syscall_64+0x3b/0xc0 [1330.352369] entry_SYSCALL_64_after_hwframe+0x44/0xae [1330.352372] RIP: 0033:0x7f4b0a580986 [1330.352379] RSP: 002b:00007ffd34d75418 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 [1330.352382] RAX: ffffffffffffffda RBX: 0000000000001000 RCX: 00007f4b0a580986 [1330.352383] RDX: 0000000000001000 RSI: 00007f4b0a3a4000 RDI: 0000000000000003 [1330.352385] RBP: 00007f4b0a3a4000 R08: 0000000000000003 R09: 0000000000000000 [1330.352386] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003 [1330.352387] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Unlike for reads, at btrfs_dio_iomap_begin() we return with the extent range unlocked, but later when the page faults are triggered and we try to read the extents, we end up btrfs_lock_and_flush_ordered_range() where we find the ordered extent for our write, created by the iomap callback btrfs_dio_iomap_begin(), and we wait for it to complete, which makes us deadlock since we can't complete the ordered extent without reading the pages (the iomap code only submits the bio after the pages are faulted in). Fix this by setting the nofault attribute of the given iov_iter and retry the direct IO read/write if we get an -EFAULT error returned from iomap. For reads, also disable page faults completely, this is because when we read from a hole or a prealloc extent, we can still trigger page faults due to the call to iov_iter_zero() done by iomap - at the moment, it is oblivious to the value of the ->nofault attribute of an iov_iter. We also need to keep track of the number of bytes written or read, and pass it to iomap_dio_rw(), as well as use the new flag IOMAP_DIO_PARTIAL. This depends on the iov_iter and iomap changes introduced in commit c03098d4b9ad ("Merge tag 'gfs2-v5.15-rc5-mmap-fault' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2"). Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 640a6be8e8618ba1dd3ec6bc9beb92a0409ef9da Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:53 2022 +0800 gfs2: Fix mmap + page fault deadlocks for direct I/O commit b01b2d72da25c000aeb124bc78daf3fb998be2b6 upstream Also disable page faults during direct I/O requests and implement a similar kind of retry logic as in the buffered I/O case. The retry logic in the direct I/O case differs from the buffered I/O case in the following way: direct I/O doesn't provide the kinds of consistency guarantees between concurrent reads and writes that buffered I/O provides, so once we lose the inode glock while faulting in user pages, we always resume the operation. We never need to return a partial read or write. This locking problem was originally reported by Jan Kara. Linus came up with the idea of disabling page faults. Many thanks to Al Viro and Matthew Wilcox for their feedback. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit f86f8d27840a97afc09077528048d39aab3e7df3 Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:52 2022 +0800 iov_iter: Introduce nofault flag to disable page faults commit 3337ab08d08b1a375f88471d9c8b1cac968cb054 upstream Introduce a new nofault flag to indicate to iov_iter_get_pages not to fault in user pages. This is implemented by passing the FOLL_NOFAULT flag to get_user_pages, which causes get_user_pages to fail when it would otherwise fault in a page. We'll use the ->nofault flag to prevent iomap_dio_rw from faulting in pages when page faults are not allowed. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 6e213bc61446d5aefcedb00251c275e30ce82ab5 Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:51 2022 +0800 gup: Introduce FOLL_NOFAULT flag to disable page faults commit 55b8fe703bc51200d4698596c90813453b35ae63 upstream Introduce a new FOLL_NOFAULT flag that causes get_user_pages to return -EFAULT when it would otherwise trigger a page fault. This is roughly similar to FOLL_FAST_ONLY but available on all architectures, and less fragile. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit d3b744791bf06bc9720bfa36bc1757f25802d68b Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:50 2022 +0800 iomap: Add done_before argument to iomap_dio_rw commit 4fdccaa0d184c202f98d73b24e3ec8eeee88ab8d upstream Add a done_before argument to iomap_dio_rw that indicates how much of the request has already been transferred. When the request succeeds, we report that done_before additional bytes were tranferred. This is useful for finishing a request asynchronously when part of the request has already been completed synchronously. We'll use that to allow iomap_dio_rw to be used with page faults disabled: when a page fault occurs while submitting a request, we synchronously complete the part of the request that has already been submitted. The caller can then take care of the page fault and call iomap_dio_rw again for the rest of the request, passing in the number of bytes already tranferred. Signed-off-by: Andreas Gruenbacher Reviewed-by: Darrick J. Wong Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit ea7a57858875256e233d29b9c01b9f558f3bd12a Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:49 2022 +0800 iomap: Support partial direct I/O on user copy failures commit 97308f8b0d867e9ef59528cd97f0db55ffdf5651 upstream In iomap_dio_rw, when iomap_apply returns an -EFAULT error and the IOMAP_DIO_PARTIAL flag is set, complete the request synchronously and return a partial result. This allows the caller to deal with the page fault and retry the remainder of the request. Signed-off-by: Andreas Gruenbacher Reviewed-by: Darrick J. Wong Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit a00cc46f97b9b9544c5edabc81d6cbfadd0ffdab Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:48 2022 +0800 iomap: Fix iomap_dio_rw return value for user copies commit 42c498c18a94eed79896c50871889af52fa0822e upstream When a user copy fails in one of the helpers of iomap_dio_rw, fail with -EFAULT instead of returning 0. This matches what iomap_dio_bio_actor returns when it gets an -EFAULT from bio_iov_iter_get_pages. With these changes, iomap_dio_actor now consistently fails with -EFAULT when a user page cannot be faulted in. Signed-off-by: Andreas Gruenbacher Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 81a7fc397a62c3f7a3003489177c80cd74ed562f Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:47 2022 +0800 gfs2: Fix mmap + page fault deadlocks for buffered I/O commit 00bfe02f479688a67a29019d1228f1470e26f014 upstream In the .read_iter and .write_iter file operations, we're accessing user-space memory while holding the inode glock. There is a possibility that the memory is mapped to the same file, in which case we'd recurse on the same glock. We could detect and work around this simple case of recursive locking, but more complex scenarios exist that involve multiple glocks, processes, and cluster nodes, and working around all of those cases isn't practical or even possible. Avoid these kinds of problems by disabling page faults while holding the inode glock. If a page fault would occur, we either end up with a partial read or write or with -EFAULT if nothing could be read or written. In either case, we know that we're not done with the operation, so we indicate that we're willing to give up the inode glock and then we fault in the missing pages. If that made us lose the inode glock, we return a partial read or write. Otherwise, we resume the operation. This locking problem was originally reported by Jan Kara. Linus came up with the idea of disabling page faults. Many thanks to Al Viro and Matthew Wilcox for their feedback. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 38b58498819acc561f39a6e3eff1b22a1f192af0 Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:46 2022 +0800 gfs2: Eliminate ip->i_gh commit 1b223f7065bc7d89c4677c27381817cc95b117a8 upstream Now that gfs2_file_buffered_write is the only remaining user of ip->i_gh, we can move the glock holder to the stack (or rather, use the one we already have on the stack); there is no need for keeping the holder in the inode anymore. This is slightly complicated by the fact that we're using ip->i_gh for the statfs inode in gfs2_file_buffered_write as well. Writing to the statfs inode isn't very common, so allocate the statfs holder dynamically when needed. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 8d363d817353e22dc2158a087b9df1fede5f149a Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:45 2022 +0800 gfs2: Move the inode glock locking to gfs2_file_buffered_write commit b924bdab7445946e2ed364a0e6e249d36f1f1158 upstream So far, for buffered writes, we were taking the inode glock in gfs2_iomap_begin and dropping it in gfs2_iomap_end with the intention of not holding the inode glock while iomap_write_actor faults in user pages. It turns out that iomap_write_actor is called inside iomap_begin ... iomap_end, so the user pages were still faulted in while holding the inode glock and the locking code in iomap_begin / iomap_end was completely pointless. Move the locking into gfs2_file_buffered_write instead. We'll take care of the potential deadlocks due to faulting in user pages while holding a glock in a subsequent patch. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 416a705304e5b150bbe9c580ba25758fd1e0aab0 Author: Bob Peterson Date: Fri Apr 15 06:28:44 2022 +0800 gfs2: Introduce flag for glock holder auto-demotion commit dc732906c2450939c319fec6e258aa89ecb5a632 upstream This patch introduces a new HIF_MAY_DEMOTE flag and infrastructure that will allow glocks to be demoted automatically on locking conflicts. When a locking request comes in that isn't compatible with the locking state of an active holder and that holder has the HIF_MAY_DEMOTE flag set, the holder will be demoted before the incoming locking request is granted. Note that this mechanism demotes active holders (with the HIF_HOLDER flag set), while before we were only demoting glocks without any active holders. This allows processes to keep hold of locks that may form a cyclic locking dependency; the core glock logic will then break those dependencies in case a conflicting locking request occurs. We'll use this to avoid giving up the inode glock proactively before faulting in pages. Processes that allow a glock holder to be taken away indicate this by calling gfs2_holder_allow_demote(), which sets the HIF_MAY_DEMOTE flag. Later, they call gfs2_holder_disallow_demote() to clear the flag again, and then they check if their holder is still queued: if it is, they are still holding the glock; if it isn't, they can re-acquire the glock (or abort). Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit b25cfbc0e7deab4180694883dd7851ec62d645cf Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:43 2022 +0800 gfs2: Clean up function may_grant commit 6144464937fe1e6135b13a30502a339d549bf093 upstream Pass the first current glock holder into function may_grant and deobfuscate the logic there. While at it, switch from BUG_ON to GLOCK_BUG_ON in may_grant. To make that build cleanly, de-constify the may_grant arguments. We're now using function find_first_holder in do_promote, so move the function's definition above do_promote. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit b88b998579eeb0df9471d6906f591d4747068dd4 Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:42 2022 +0800 gfs2: Add wrapper for iomap_file_buffered_write commit 2eb7509a05443048fb4df60b782de3f03c6c298b upstream Add a wrapper around iomap_file_buffered_write. We'll add code for when the operation needs to be retried here later. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 1d91c912e7d14e147183757f48e709f8154f9de3 Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:41 2022 +0800 iov_iter: Introduce fault_in_iov_iter_writeable commit cdd591fc86e38ad3899196066219fbbd845f3162 upstream Introduce a new fault_in_iov_iter_writeable helper for safely faulting in an iterator for writing. Uses get_user_pages() to fault in the pages without actually writing to them, which would be destructive. We'll use fault_in_iov_iter_writeable in gfs2 once we've determined that the iterator passed to .read_iter isn't in memory. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 30e66b1dfcbbe409c76500a77ecd20b3cf5b8fa5 Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:40 2022 +0800 iov_iter: Turn iov_iter_fault_in_readable into fault_in_iov_iter_readable commit a6294593e8a1290091d0b078d5d33da5e0cd3dfe upstream Turn iov_iter_fault_in_readable into a function that returns the number of bytes not faulted in, similar to copy_to_user, instead of returning a non-zero value when any of the requested pages couldn't be faulted in. This supports the existing users that require all pages to be faulted in as well as new users that are happy if any pages can be faulted in. Rename iov_iter_fault_in_readable to fault_in_iov_iter_readable to make sure this change doesn't silently break things. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 923f05a660e60ef22952e09acdd6e37e17ddf084 Author: Andreas Gruenbacher Date: Fri Apr 15 06:28:39 2022 +0800 gup: Turn fault_in_pages_{readable,writeable} into fault_in_{readable,writeable} commit bb523b406c849eef8f265a07cd7f320f1f177743 upstream Turn fault_in_pages_{readable,writeable} into versions that return the number of bytes not faulted in, similar to copy_to_user, instead of returning a non-zero value when any of the requested pages couldn't be faulted in. This supports the existing users that require all pages to be faulted in as well as new users that are happy if any pages can be faulted in. Rename the functions to fault_in_{readable,writeable} to make sure this change doesn't silently break things. Neither of these functions is entirely trivial and it doesn't seem useful to inline them, so move them to mm/gup.c. Signed-off-by: Andreas Gruenbacher Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 19cbd78fb26a2622714183d400b9af2659fa5221 Author: Muchun Song Date: Fri Apr 1 11:28:36 2022 -0700 mm: kfence: fix objcgs vector allocation commit 8f0b36497303487d5a32c75789c77859cc2ee895 upstream. If the kfence object is allocated to be used for objects vector, then this slot of the pool eventually being occupied permanently since the vector is never freed. The solutions could be (1) freeing vector when the kfence object is freed or (2) allocating all vectors statically. Since the memory consumption of object vectors is low, it is better to chose (2) to fix the issue and it is also can reduce overhead of vectors allocating in the future. Link: https://lkml.kernel.org/r/20220328132843.16624-1-songmuchun@bytedance.com Fixes: d3fb45f370d9 ("mm, kfence: insert KFENCE hooks for SLAB") Signed-off-by: Muchun Song Reviewed-by: Marco Elver Reviewed-by: Roman Gushchin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Xiongchun Duan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 10033fa72d41cc1c2d9d18e97700715376b8088b Author: Dinh Nguyen Date: Mon Nov 22 09:10:03 2021 -0600 ARM: dts: socfpga: change qspi to "intel,socfpga-qspi" commit 36de991e93908f7ad5c2a0eac9c4ecf8b723fa4a upstream. Because of commit 9cb2ff111712 ("spi: cadence-quadspi: Disable Auto-HW polling"), which does a write to the CQSPI_REG_WR_COMPLETION_CTRL register regardless of any condition. Well, the Cadence QuadSPI controller on Intel's SoCFPGA platforms does not implement the CQSPI_REG_WR_COMPLETION_CTRL register, thus a write to this register results in a crash! So starting with v5.16, I introduced the patch 98d948eb833 ("spi: cadence-quadspi: fix write completion support"), which adds the dts compatible "intel,socfpga-qspi" that is specific for versions that doesn't have the CQSPI_REG_WR_COMPLETION_CTRL register implemented. Signed-off-by: Dinh Nguyen [IA: submitted for linux-5.15.y] Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit e8749d608847be133f5621f07e6e023c8fc33406 Author: Dinh Nguyen Date: Mon Nov 8 14:08:54 2021 -0600 spi: cadence-quadspi: fix write completion support commit 98d948eb833104a094517401ed8be26ba3ce9935 upstream. Some versions of the Cadence QSPI controller does not have the write completion register implemented(CQSPI_REG_WR_COMPLETION_CTRL). On the Intel SoCFPGA platform the CQSPI_REG_WR_COMPLETION_CTRL register is not configured. Add a quirk to not write to the CQSPI_REG_WR_COMPLETION_CTRL register. Fixes: 9cb2ff111712 ("spi: cadence-quadspi: Disable Auto-HW polling) Signed-off-by: Dinh Nguyen Reviewed-by: Pratyush Yadav Link: https://lore.kernel.org/r/20211108200854.3616121-1-dinguyen@kernel.org Signed-off-by: Mark Brown [IA: backported for linux=5.15.y] Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 8c39925e98d498b9531343066ef82ae39e41adae Author: Kumar Kartikeya Dwivedi Date: Thu Apr 28 16:57:51 2022 -0700 bpf: Fix crash due to out of bounds access into reg2btf_ids. commit 45ce4b4f9009102cd9f581196d480a59208690c1 upstream When commit e6ac2450d6de ("bpf: Support bpf program calling kernel function") added kfunc support, it defined reg2btf_ids as a cheap way to translate the verifier reg type to the appropriate btf_vmlinux BTF ID, however commit c25b2ae13603 ("bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL") moved the __BPF_REG_TYPE_MAX from the last member of bpf_reg_type enum to after the base register types, and defined other variants using type flag composition. However, now, the direct usage of reg->type to index into reg2btf_ids may no longer fall into __BPF_REG_TYPE_MAX range, and hence lead to out of bounds access and kernel crash on dereference of bad pointer. [backport note: commit 3363bd0cfbb80 ("bpf: Extend kfunc with PTR_TO_CTX, PTR_TO_MEM argument support") was introduced after 5.15 and contains an out of bound reg2btf_ids access. Since that commit hasn't been backported, this patch doesn't include fix to that access. If we backport that commit in future, we need to fix its faulting access as well.] Fixes: c25b2ae13603 ("bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL") Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20220216201943.624869-1-memxor@gmail.com Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Greg Kroah-Hartman commit 379382b347dbd2058eb0bf7f269aed01985f8cf6 Author: Hao Luo Date: Thu Apr 28 16:57:50 2022 -0700 bpf/selftests: Test PTR_TO_RDONLY_MEM commit 9497c458c10b049438ef6e6ddda898edbc3ec6a8 upstream. This test verifies that a ksym of non-struct can not be directly updated. Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20211217003152.48334-10-haoluo@google.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Greg Kroah-Hartman commit 2a77c58726aba893129a369ed3d2be004dda41cd Author: Hao Luo Date: Thu Apr 28 16:57:49 2022 -0700 bpf: Add MEM_RDONLY for helper args that are pointers to rdonly mem. commit 216e3cd2f28dbbf1fe86848e0e29e6693b9f0a20 upstream. Some helper functions may modify its arguments, for example, bpf_d_path, bpf_get_stack etc. Previously, their argument types were marked as ARG_PTR_TO_MEM, which is compatible with read-only mem types, such as PTR_TO_RDONLY_BUF. Therefore it's legitimate, but technically incorrect, to modify a read-only memory by passing it into one of such helper functions. This patch tags the bpf_args compatible with immutable memory with MEM_RDONLY flag. The arguments that don't have this flag will be only compatible with mutable memory types, preventing the helper from modifying a read-only memory. The bpf_args that have MEM_RDONLY are compatible with both mutable memory and immutable memory. Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211217003152.48334-9-haoluo@google.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Greg Kroah-Hartman commit 15166bb3000fc8b5faa8fa606eb25d300e6892ef Author: Hao Luo Date: Thu Apr 28 16:57:48 2022 -0700 bpf: Make per_cpu_ptr return rdonly PTR_TO_MEM. commit 34d3a78c681e8e7844b43d1a2f4671a04249c821 upstream. Tag the return type of {per, this}_cpu_ptr with RDONLY_MEM. The returned value of this pair of helpers is kernel object, which can not be updated by bpf programs. Previously these two helpers return PTR_OT_MEM for kernel objects of scalar type, which allows one to directly modify the memory. Now with RDONLY_MEM tagging, the verifier will reject programs that write into RDONLY_MEM. Fixes: 63d9b80dcf2c ("bpf: Introducte bpf_this_cpu_ptr()") Fixes: eaa6bcb71ef6 ("bpf: Introduce bpf_per_cpu_ptr()") Fixes: 4976b718c355 ("bpf: Introduce pseudo_btf_id") Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211217003152.48334-8-haoluo@google.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Greg Kroah-Hartman commit b710f73704d61069b2f05358309290551e5a8732 Author: Hao Luo Date: Thu Apr 28 16:57:47 2022 -0700 bpf: Convert PTR_TO_MEM_OR_NULL to composable types. commit cf9f2f8d62eca810afbd1ee6cc0800202b000e57 upstream. Remove PTR_TO_MEM_OR_NULL and replace it with PTR_TO_MEM combined with flag PTR_MAYBE_NULL. Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211217003152.48334-7-haoluo@google.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Greg Kroah-Hartman commit b453361384c2db1c703dacb806d5fd36aec4ceca Author: Hao Luo Date: Thu Apr 28 16:57:46 2022 -0700 bpf: Introduce MEM_RDONLY flag commit 20b2aff4bc15bda809f994761d5719827d66c0b4 upstream. This patch introduce a flag MEM_RDONLY to tag a reg value pointing to read-only memory. It makes the following changes: 1. PTR_TO_RDWR_BUF -> PTR_TO_BUF 2. PTR_TO_RDONLY_BUF -> PTR_TO_BUF | MEM_RDONLY Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211217003152.48334-6-haoluo@google.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Greg Kroah-Hartman commit 8d38cde47a7e17b646401fa92d916503caa5375e Author: Hao Luo Date: Thu Apr 28 16:57:45 2022 -0700 bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL commit c25b2ae136039ffa820c26138ed4a5e5f3ab3841 upstream. We have introduced a new type to make bpf_reg composable, by allocating bits in the type to represent flags. One of the flags is PTR_MAYBE_NULL which indicates a pointer may be NULL. This patch switches the qualified reg_types to use this flag. The reg_types changed in this patch include: 1. PTR_TO_MAP_VALUE_OR_NULL 2. PTR_TO_SOCKET_OR_NULL 3. PTR_TO_SOCK_COMMON_OR_NULL 4. PTR_TO_TCP_SOCK_OR_NULL 5. PTR_TO_BTF_ID_OR_NULL 6. PTR_TO_MEM_OR_NULL 7. PTR_TO_RDONLY_BUF_OR_NULL 8. PTR_TO_RDWR_BUF_OR_NULL [haoluo: backport notes There was a reg_type_may_be_null() in adjust_ptr_min_max_vals() in 5.15.x, but didn't exist in the upstream commit. This backport converted that reg_type_may_be_null() to type_may_be_null() as well.] Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/r/20211217003152.48334-5-haoluo@google.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Greg Kroah-Hartman commit 3c141c82b95807473d77079936769e04a84e4ca3 Author: Hao Luo Date: Thu Apr 28 16:57:44 2022 -0700 bpf: Replace RET_XXX_OR_NULL with RET_XXX | PTR_MAYBE_NULL commit 3c4807322660d4290ac9062c034aed6b87243861 upstream. We have introduced a new type to make bpf_ret composable, by reserving high bits to represent flags. One of the flag is PTR_MAYBE_NULL, which indicates a pointer may be NULL. When applying this flag to ret_types, it means the returned value could be a NULL pointer. This patch switches the qualified arg_types to use this flag. The ret_types changed in this patch include: 1. RET_PTR_TO_MAP_VALUE_OR_NULL 2. RET_PTR_TO_SOCKET_OR_NULL 3. RET_PTR_TO_TCP_SOCK_OR_NULL 4. RET_PTR_TO_SOCK_COMMON_OR_NULL 5. RET_PTR_TO_ALLOC_MEM_OR_NULL 6. RET_PTR_TO_MEM_OR_BTF_ID_OR_NULL 7. RET_PTR_TO_BTF_ID_OR_NULL This patch doesn't eliminate the use of these names, instead it makes them aliases to 'RET_PTR_TO_XXX | PTR_MAYBE_NULL'. Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211217003152.48334-4-haoluo@google.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Greg Kroah-Hartman commit d58a396fa6c98bde64772c1db715dfca32610597 Author: Hao Luo Date: Thu Apr 28 16:57:43 2022 -0700 bpf: Replace ARG_XXX_OR_NULL with ARG_XXX | PTR_MAYBE_NULL commit 48946bd6a5d695c50b34546864b79c1f910a33c1 upstream. We have introduced a new type to make bpf_arg composable, by reserving high bits of bpf_arg to represent flags of a type. One of the flags is PTR_MAYBE_NULL which indicates a pointer may be NULL. When applying this flag to an arg_type, it means the arg can take NULL pointer. This patch switches the qualified arg_types to use this flag. The arg_types changed in this patch include: 1. ARG_PTR_TO_MAP_VALUE_OR_NULL 2. ARG_PTR_TO_MEM_OR_NULL 3. ARG_PTR_TO_CTX_OR_NULL 4. ARG_PTR_TO_SOCKET_OR_NULL 5. ARG_PTR_TO_ALLOC_MEM_OR_NULL 6. ARG_PTR_TO_STACK_OR_NULL This patch does not eliminate the use of these arg_types, instead it makes them an alias to the 'ARG_XXX | PTR_MAYBE_NULL'. Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211217003152.48334-3-haoluo@google.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Greg Kroah-Hartman commit a76020980b9fa13b40e23711fcf79c018b1fd7fa Author: Hao Luo Date: Thu Apr 28 16:57:42 2022 -0700 bpf: Introduce composable reg, ret and arg types. commit d639b9d13a39cf15639cbe6e8b2c43eb60148a73 upstream. There are some common properties shared between bpf reg, ret and arg values. For instance, a value may be a NULL pointer, or a pointer to a read-only memory. Previously, to express these properties, enumeration was used. For example, in order to test whether a reg value can be NULL, reg_type_may_be_null() simply enumerates all types that are possibly NULL. The problem of this approach is that it's not scalable and causes a lot of duplication. These properties can be combined, for example, a type could be either MAYBE_NULL or RDONLY, or both. This patch series rewrites the layout of reg_type, arg_type and ret_type, so that common properties can be extracted and represented as composable flag. For example, one can write ARG_PTR_TO_MEM | PTR_MAYBE_NULL which is equivalent to the previous ARG_PTR_TO_MEM_OR_NULL The type ARG_PTR_TO_MEM are called "base type" in this patch. Base types can be extended with flags. A flag occupies the higher bits while base types sits in the lower bits. This patch in particular sets up a set of macro for this purpose. The following patches will rewrite arg_types, ret_types and reg_types respectively. Signed-off-by: Hao Luo Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211217003152.48334-2-haoluo@google.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Greg Kroah-Hartman commit e52da8e4632f9c8fe78bf1c5881ce6871c7e08f3 Author: Willy Tarreau Date: Tue Apr 26 23:41:05 2022 +0300 floppy: disable FDRAWCMD by default commit 233087ca063686964a53c829d547c7571e3f67bf upstream. Minh Yuan reported a concurrency use-after-free issue in the floppy code between raw_cmd_ioctl and seek_interrupt. [ It turns out this has been around, and that others have reported the KASAN splats over the years, but Minh Yuan had a reproducer for it and so gets primary credit for reporting it for this fix - Linus ] The problem is, this driver tends to break very easily and nowadays, nobody is expected to use FDRAWCMD anyway since it was used to manipulate non-standard formats. The risk of breaking the driver is higher than the risk presented by this race, and accessing the device requires privileges anyway. Let's just add a config option to completely disable this ioctl and leave it disabled by default. Distros shouldn't use it, and only those running on antique hardware might need to enable it. Link: https://lore.kernel.org/all/000000000000b71cdd05d703f6bf@google.com/ Link: https://lore.kernel.org/lkml/CAKcFiNC=MfYVW-Jt9A3=FPJpTwCD2PL_ULNCpsCVE5s8ZeBQgQ@mail.gmail.com Link: https://lore.kernel.org/all/CAEAjamu1FRhz6StCe_55XY5s389ZP_xmCF69k987En+1z53=eg@mail.gmail.com Reported-by: Minh Yuan Reported-by: syzbot+8e8958586909d62b6840@syzkaller.appspotmail.com Reported-by: cruise k Reported-by: Kyungtae Kim Suggested-by: Linus Torvalds Tested-by: Denis Efremov Signed-off-by: Willy Tarreau Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 21e652563604d2eea9a4ffd5326b81eaf9e9853c Author: Alexandre Frade Date: Wed Apr 27 18:08:11 2022 +0000 Linux 5.15.36-xanmod1 Signed-off-by: Alexandre Frade