commit 9f13e7dde0440a4a82307b9825f9361f24ca1fc4 Author: Alexandre Frade Date: Sun Aug 8 18:51:54 2021 +0000 Linux 5.10.56-rt48-xanmod1 Signed-off-by: Alexandre Frade commit 4542308064e24ed47f547e8710f20dface6556e0 Author: build Date: Sun Aug 1 16:01:04 2021 +0800 netfilter: Add full cone NAT support Signed-off-by: Alexandre Frade commit 3bd0e1129edcb34a220083dd55fb94b4a8731ab7 Merge: cd7b1c6eb297 0c75ad69fa34 Author: Alexandre Frade Date: Sun Aug 8 18:46:35 2021 +0000 Merge tag 'v5.10.56-rt48' into 5.10-rt Linux 5.10.56-rt48 commit 0c75ad69fa347cc1b4f2cbb6b455626bb5d6d1a1 Author: Steven Rostedt (VMware) Date: Fri Aug 6 17:05:56 2021 -0400 Linux 5.10.56-rt48 commit 0878114fbde886f13b616d21e622aa848d90da78 Merge: dad77cf5645e 9746c25334cb Author: Steven Rostedt (VMware) Date: Fri Aug 6 14:27:20 2021 -0400 Merge tag 'v5.10.56' into v5.10-rt This is the 5.10.56 stable release commit 9746c25334cb364ab6651ee6dfd4cab3218d0c06 Author: Greg Kroah-Hartman Date: Wed Aug 4 12:46:45 2021 +0200 Linux 5.10.56 Link: https://lore.kernel.org/r/20210802134339.023067817@linuxfoundation.org Tested-by: Fox Chen Tested-by: Pavel Machek (CIP) Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Rudi Heitbaum Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 55dd22c5d029423f513fd849e633adf0e9c10d0c Author: Oleksij Rempel Date: Wed Jul 14 13:16:02 2021 +0200 can: j1939: j1939_session_deactivate(): clarify lifetime of session object commit 0c71437dd50dd687c15d8ca80b3b68f10bb21d63 upstream. The j1939_session_deactivate() is decrementing the session ref-count and potentially can free() the session. This would cause use-after-free situation. However, the code calling j1939_session_deactivate() does always hold another reference to the session, so that it would not be free()ed in this code path. This patch adds a comment to make this clear and a WARN_ON, to ensure that future changes will not violate this requirement. Further this patch avoids dereferencing the session pointer as a precaution to avoid use-after-free if the session is actually free()ed. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/r/20210714111602.24021-1-o.rempel@pengutronix.de Reported-by: Xiaochen Zou Signed-off-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 75ebe1d355b5b179568009ef35042d3c7be7ee00 Author: Lukasz Cieplicki Date: Mon May 31 16:55:49 2021 +0000 i40e: Add additional info to PHY type error commit dc614c46178b0b89bde86ac54fc687a28580d2b7 upstream. In case of PHY type error occurs, the message was too generic. Add additional info to PHY type error indicating that it can be wrong cable connected. Fixes: 124ed15bf126 ("i40e: Add dual speed module support") Signed-off-by: Lukasz Cieplicki Signed-off-by: Michal Maloszewski Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 2ca5ec188b2097f5b93299638e0b74e2126031a8 Author: Arnaldo Carvalho de Melo Date: Fri Jul 30 18:26:22 2021 -0300 Revert "perf map: Fix dso->nsinfo refcounting" commit 9bac1bd6e6d36459087a728a968e79e37ebcea1a upstream. This makes 'perf top' abort in some cases, and the right fix will involve surgery that is too much to do at this stage, so revert for now and fix it in the next merge window. This reverts commit 2d6b74baa7147251c30a46c4996e8cc224aa2dc5. Cc: Riccardo Mancini Cc: Ian Rogers Cc: Jiri Olsa Cc: Krister Johansen Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit c14cee5bc466dd09918e2b749bcf2ba9babfb7d5 Author: Srikar Dronamraju Date: Thu Jul 29 11:34:49 2021 +0530 powerpc/pseries: Fix regression while building external modules commit 333cf507465fbebb3727f5b53e77538467df312a upstream. With commit c9f3401313a5 ("powerpc: Always enable queued spinlocks for 64s, disable for others") CONFIG_PPC_QUEUED_SPINLOCKS is always enabled on ppc64le, external modules that use spinlock APIs are failing. ERROR: modpost: GPL-incompatible module XXX.ko uses GPL-only symbol 'shared_processor' Before the above commit, modules were able to build without any issues. Also this problem is not seen on other architectures. This problem can be workaround if CONFIG_UNINLINE_SPIN_UNLOCK is enabled in the config. However CONFIG_UNINLINE_SPIN_UNLOCK is not enabled by default and only enabled in certain conditions like CONFIG_DEBUG_SPINLOCKS is set in the kernel config. #include spinlock_t spLock; static int __init spinlock_test_init(void) { spin_lock_init(&spLock); spin_lock(&spLock); spin_unlock(&spLock); return 0; } static void __exit spinlock_test_exit(void) { printk("spinlock_test unloaded\n"); } module_init(spinlock_test_init); module_exit(spinlock_test_exit); MODULE_DESCRIPTION ("spinlock_test"); MODULE_LICENSE ("non-GPL"); MODULE_AUTHOR ("Srikar Dronamraju"); Given that spin locks are one of the basic facilities for module code, this effectively makes it impossible to build/load almost any non GPL modules on ppc64le. This was first reported at https://github.com/openzfs/zfs/issues/11172 Currently shared_processor is exported as GPL only symbol. Fix this for parity with other architectures by exposing shared_processor to non-GPL modules too. Fixes: 14c73bd344da ("powerpc/vcpu: Assume dedicated processors as non-preempt") Cc: stable@vger.kernel.org # v5.5+ Reported-by: marc.c.dionne@gmail.com Signed-off-by: Srikar Dronamraju Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210729060449.292780-1-srikar@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman commit bfc8e67c60b911ee5605c1234fcb58239e5c20de Author: Steve French Date: Fri Jul 23 18:35:15 2021 -0500 SMB3: fix readpage for large swap cache commit f2a26a3cff27dfa456fef386fe5df56dcb4b47b6 upstream. readpage was calculating the offset of the page incorrectly for the case of large swapcaches. loff_t offset = (loff_t)page->index << PAGE_SHIFT; As pointed out by Matthew Wilcox, this needs to use page_file_offset() to calculate the offset instead. Pages coming from the swap cache have page->index set to their index within the swapcache, not within the backing file. For a sufficiently large swapcache, we could have overlapping values of page->index within the same backing file. Suggested by: Matthew Wilcox (Oracle) Cc: # v5.7+ Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit be561c0154dca82c3e399648bfe1b21b717af144 Author: Daniel Borkmann Date: Fri Jul 16 09:18:21 2021 +0000 bpf: Fix pointer arithmetic mask tightening under state pruning commit e042aa532c84d18ff13291d00620502ce7a38dda upstream. In 7fedb63a8307 ("bpf: Tighten speculative pointer arithmetic mask") we narrowed the offset mask for unprivileged pointer arithmetic in order to mitigate a corner case where in the speculative domain it is possible to advance, for example, the map value pointer by up to value_size-1 out-of- bounds in order to leak kernel memory via side-channel to user space. The verifier's state pruning for scalars leaves one corner case open where in the first verification path R_x holds an unknown scalar with an aux->alu_limit of e.g. 7, and in a second verification path that same register R_x, here denoted as R_x', holds an unknown scalar which has tighter bounds and would thus satisfy range_within(R_x, R_x') as well as tnum_in(R_x, R_x') for state pruning, yielding an aux->alu_limit of 3: Given the second path fits the register constraints for pruning, the final generated mask from aux->alu_limit will remain at 7. While technically not wrong for the non-speculative domain, it would however be possible to craft similar cases where the mask would be too wide as in 7fedb63a8307. One way to fix it is to detect the presence of unknown scalar map pointer arithmetic and force a deeper search on unknown scalars to ensure that we do not run into a masking mismatch. Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit ffb9d5c48b4bba47cf926530de45187ecdfd31b5 Author: Lorenz Bauer Date: Thu Apr 29 14:46:56 2021 +0100 bpf: verifier: Allocate idmap scratch in verifier env commit c9e73e3d2b1eb1ea7ff068e05007eec3bd8ef1c9 upstream. func_states_equal makes a very short lived allocation for idmap, probably because it's too large to fit on the stack. However the function is called quite often, leading to a lot of alloc / free churn. Replace the temporary allocation with dedicated scratch space in struct bpf_verifier_env. Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Acked-by: Edward Cree Link: https://lore.kernel.org/bpf/20210429134656.122225-4-lmb@cloudflare.com Signed-off-by: Greg Kroah-Hartman commit a11ca29c65c147c9d52896304e9761e2c4ed70dc Author: Daniel Borkmann Date: Tue Jun 29 09:39:15 2021 +0000 bpf: Remove superfluous aux sanitation on subprog rejection commit 59089a189e3adde4cf85f2ce479738d1ae4c514d upstream. Follow-up to fe9a5ca7e370 ("bpf: Do not mark insn as seen under speculative path verification"). The sanitize_insn_aux_data() helper does not serve a particular purpose in today's code. The original intention for the helper was that if function-by-function verification fails, a given program would be cleared from temporary insn_aux_data[], and then its verification would be re-attempted in the context of the main program a second time. However, a failure in do_check_subprogs() will skip do_check_main() and propagate the error to the user instead, thus such situation can never occur. Given its interaction is not compatible to the Spectre v1 mitigation (due to comparing aux->seen with env->pass_cnt), just remove sanitize_insn_aux_data() to avoid future bugs in this area. Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 0e9280654aa482088ee6ef3deadef331f5ac5fb0 Author: Daniel Borkmann Date: Tue Jul 13 08:18:31 2021 +0000 bpf: Fix leakage due to insufficient speculative store bypass mitigation [ Upstream commit 2039f26f3aca5b0e419b98f65dd36481337b86ee ] Spectre v4 gadgets make use of memory disambiguation, which is a set of techniques that execute memory access instructions, that is, loads and stores, out of program order; Intel's optimization manual, section 2.4.4.5: A load instruction micro-op may depend on a preceding store. Many microarchitectures block loads until all preceding store addresses are known. The memory disambiguator predicts which loads will not depend on any previous stores. When the disambiguator predicts that a load does not have such a dependency, the load takes its data from the L1 data cache. Eventually, the prediction is verified. If an actual conflict is detected, the load and all succeeding instructions are re-executed. af86ca4e3088 ("bpf: Prevent memory disambiguation attack") tried to mitigate this attack by sanitizing the memory locations through preemptive "fast" (low latency) stores of zero prior to the actual "slow" (high latency) store of a pointer value such that upon dependency misprediction the CPU then speculatively executes the load of the pointer value and retrieves the zero value instead of the attacker controlled scalar value previously stored at that location, meaning, subsequent access in the speculative domain is then redirected to the "zero page". The sanitized preemptive store of zero prior to the actual "slow" store is done through a simple ST instruction based on r10 (frame pointer) with relative offset to the stack location that the verifier has been tracking on the original used register for STX, which does not have to be r10. Thus, there are no memory dependencies for this store, since it's only using r10 and immediate constant of zero; hence af86ca4e3088 /assumed/ a low latency operation. However, a recent attack demonstrated that this mitigation is not sufficient since the preemptive store of zero could also be turned into a "slow" store and is thus bypassed as well: [...] // r2 = oob address (e.g. scalar) // r7 = pointer to map value 31: (7b) *(u64 *)(r10 -16) = r2 // r9 will remain "fast" register, r10 will become "slow" register below 32: (bf) r9 = r10 // JIT maps BPF reg to x86 reg: // r9 -> r15 (callee saved) // r10 -> rbp // train store forward prediction to break dependency link between both r9 // and r10 by evicting them from the predictor's LRU table. 33: (61) r0 = *(u32 *)(r7 +24576) 34: (63) *(u32 *)(r7 +29696) = r0 35: (61) r0 = *(u32 *)(r7 +24580) 36: (63) *(u32 *)(r7 +29700) = r0 37: (61) r0 = *(u32 *)(r7 +24584) 38: (63) *(u32 *)(r7 +29704) = r0 39: (61) r0 = *(u32 *)(r7 +24588) 40: (63) *(u32 *)(r7 +29708) = r0 [...] 543: (61) r0 = *(u32 *)(r7 +25596) 544: (63) *(u32 *)(r7 +30716) = r0 // prepare call to bpf_ringbuf_output() helper. the latter will cause rbp // to spill to stack memory while r13/r14/r15 (all callee saved regs) remain // in hardware registers. rbp becomes slow due to push/pop latency. below is // disasm of bpf_ringbuf_output() helper for better visual context: // // ffffffff8117ee20: 41 54 push r12 // ffffffff8117ee22: 55 push rbp // ffffffff8117ee23: 53 push rbx // ffffffff8117ee24: 48 f7 c1 fc ff ff ff test rcx,0xfffffffffffffffc // ffffffff8117ee2b: 0f 85 af 00 00 00 jne ffffffff8117eee0 <-- jump taken // [...] // ffffffff8117eee0: 49 c7 c4 ea ff ff ff mov r12,0xffffffffffffffea // ffffffff8117eee7: 5b pop rbx // ffffffff8117eee8: 5d pop rbp // ffffffff8117eee9: 4c 89 e0 mov rax,r12 // ffffffff8117eeec: 41 5c pop r12 // ffffffff8117eeee: c3 ret 545: (18) r1 = map[id:4] 547: (bf) r2 = r7 548: (b7) r3 = 0 549: (b7) r4 = 4 550: (85) call bpf_ringbuf_output#194288 // instruction 551 inserted by verifier \ 551: (7a) *(u64 *)(r10 -16) = 0 | /both/ are now slow stores here // storing map value pointer r7 at fp-16 | since value of r10 is "slow". 552: (7b) *(u64 *)(r10 -16) = r7 / // following "fast" read to the same memory location, but due to dependency // misprediction it will speculatively execute before insn 551/552 completes. 553: (79) r2 = *(u64 *)(r9 -16) // in speculative domain contains attacker controlled r2. in non-speculative // domain this contains r7, and thus accesses r7 +0 below. 554: (71) r3 = *(u8 *)(r2 +0) // leak r3 As can be seen, the current speculative store bypass mitigation which the verifier inserts at line 551 is insufficient since /both/, the write of the zero sanitation as well as the map value pointer are a high latency instruction due to prior memory access via push/pop of r10 (rbp) in contrast to the low latency read in line 553 as r9 (r15) which stays in hardware registers. Thus, architecturally, fp-16 is r7, however, microarchitecturally, fp-16 can still be r2. Initial thoughts to address this issue was to track spilled pointer loads from stack and enforce their load via LDX through r10 as well so that /both/ the preemptive store of zero /as well as/ the load use the /same/ register such that a dependency is created between the store and load. However, this option is not sufficient either since it can be bypassed as well under speculation. An updated attack with pointer spill/fills now _all_ based on r10 would look as follows: [...] // r2 = oob address (e.g. scalar) // r7 = pointer to map value [...] // longer store forward prediction training sequence than before. 2062: (61) r0 = *(u32 *)(r7 +25588) 2063: (63) *(u32 *)(r7 +30708) = r0 2064: (61) r0 = *(u32 *)(r7 +25592) 2065: (63) *(u32 *)(r7 +30712) = r0 2066: (61) r0 = *(u32 *)(r7 +25596) 2067: (63) *(u32 *)(r7 +30716) = r0 // store the speculative load address (scalar) this time after the store // forward prediction training. 2068: (7b) *(u64 *)(r10 -16) = r2 // preoccupy the CPU store port by running sequence of dummy stores. 2069: (63) *(u32 *)(r7 +29696) = r0 2070: (63) *(u32 *)(r7 +29700) = r0 2071: (63) *(u32 *)(r7 +29704) = r0 2072: (63) *(u32 *)(r7 +29708) = r0 2073: (63) *(u32 *)(r7 +29712) = r0 2074: (63) *(u32 *)(r7 +29716) = r0 2075: (63) *(u32 *)(r7 +29720) = r0 2076: (63) *(u32 *)(r7 +29724) = r0 2077: (63) *(u32 *)(r7 +29728) = r0 2078: (63) *(u32 *)(r7 +29732) = r0 2079: (63) *(u32 *)(r7 +29736) = r0 2080: (63) *(u32 *)(r7 +29740) = r0 2081: (63) *(u32 *)(r7 +29744) = r0 2082: (63) *(u32 *)(r7 +29748) = r0 2083: (63) *(u32 *)(r7 +29752) = r0 2084: (63) *(u32 *)(r7 +29756) = r0 2085: (63) *(u32 *)(r7 +29760) = r0 2086: (63) *(u32 *)(r7 +29764) = r0 2087: (63) *(u32 *)(r7 +29768) = r0 2088: (63) *(u32 *)(r7 +29772) = r0 2089: (63) *(u32 *)(r7 +29776) = r0 2090: (63) *(u32 *)(r7 +29780) = r0 2091: (63) *(u32 *)(r7 +29784) = r0 2092: (63) *(u32 *)(r7 +29788) = r0 2093: (63) *(u32 *)(r7 +29792) = r0 2094: (63) *(u32 *)(r7 +29796) = r0 2095: (63) *(u32 *)(r7 +29800) = r0 2096: (63) *(u32 *)(r7 +29804) = r0 2097: (63) *(u32 *)(r7 +29808) = r0 2098: (63) *(u32 *)(r7 +29812) = r0 // overwrite scalar with dummy pointer; same as before, also including the // sanitation store with 0 from the current mitigation by the verifier. 2099: (7a) *(u64 *)(r10 -16) = 0 | /both/ are now slow stores here 2100: (7b) *(u64 *)(r10 -16) = r7 | since store unit is still busy. // load from stack intended to bypass stores. 2101: (79) r2 = *(u64 *)(r10 -16) 2102: (71) r3 = *(u8 *)(r2 +0) // leak r3 [...] Looking at the CPU microarchitecture, the scheduler might issue loads (such as seen in line 2101) before stores (line 2099,2100) because the load execution units become available while the store execution unit is still busy with the sequence of dummy stores (line 2069-2098). And so the load may use the prior stored scalar from r2 at address r10 -16 for speculation. The updated attack may work less reliable on CPU microarchitectures where loads and stores share execution resources. This concludes that the sanitizing with zero stores from af86ca4e3088 ("bpf: Prevent memory disambiguation attack") is insufficient. Moreover, the detection of stack reuse from af86ca4e3088 where previously data (STACK_MISC) has been written to a given stack slot where a pointer value is now to be stored does not have sufficient coverage as precondition for the mitigation either; for several reasons outlined as follows: 1) Stack content from prior program runs could still be preserved and is therefore not "random", best example is to split a speculative store bypass attack between tail calls, program A would prepare and store the oob address at a given stack slot and then tail call into program B which does the "slow" store of a pointer to the stack with subsequent "fast" read. From program B PoV such stack slot type is STACK_INVALID, and therefore also must be subject to mitigation. 2) The STACK_SPILL must not be coupled to register_is_const(&stack->spilled_ptr) condition, for example, the previous content of that memory location could also be a pointer to map or map value. Without the fix, a speculative store bypass is not mitigated in such precondition and can then lead to a type confusion in the speculative domain leaking kernel memory near these pointer types. While brainstorming on various alternative mitigation possibilities, we also stumbled upon a retrospective from Chrome developers [0]: [...] For variant 4, we implemented a mitigation to zero the unused memory of the heap prior to allocation, which cost about 1% when done concurrently and 4% for scavenging. Variant 4 defeats everything we could think of. We explored more mitigations for variant 4 but the threat proved to be more pervasive and dangerous than we anticipated. For example, stack slots used by the register allocator in the optimizing compiler could be subject to type confusion, leading to pointer crafting. Mitigating type confusion for stack slots alone would have required a complete redesign of the backend of the optimizing compiler, perhaps man years of work, without a guarantee of completeness. [...] From BPF side, the problem space is reduced, however, options are rather limited. One idea that has been explored was to xor-obfuscate pointer spills to the BPF stack: [...] // preoccupy the CPU store port by running sequence of dummy stores. [...] 2106: (63) *(u32 *)(r7 +29796) = r0 2107: (63) *(u32 *)(r7 +29800) = r0 2108: (63) *(u32 *)(r7 +29804) = r0 2109: (63) *(u32 *)(r7 +29808) = r0 2110: (63) *(u32 *)(r7 +29812) = r0 // overwrite scalar with dummy pointer; xored with random 'secret' value // of 943576462 before store ... 2111: (b4) w11 = 943576462 2112: (af) r11 ^= r7 2113: (7b) *(u64 *)(r10 -16) = r11 2114: (79) r11 = *(u64 *)(r10 -16) 2115: (b4) w2 = 943576462 2116: (af) r2 ^= r11 // ... and restored with the same 'secret' value with the help of AX reg. 2117: (71) r3 = *(u8 *)(r2 +0) [...] While the above would not prevent speculation, it would make data leakage infeasible by directing it to random locations. In order to be effective and prevent type confusion under speculation, such random secret would have to be regenerated for each store. The additional complexity involved for a tracking mechanism that prevents jumps such that restoring spilled pointers would not get corrupted is not worth the gain for unprivileged. Hence, the fix in here eventually opted for emitting a non-public BPF_ST | BPF_NOSPEC instruction which the x86 JIT translates into a lfence opcode. Inserting the latter in between the store and load instruction is one of the mitigations options [1]. The x86 instruction manual notes: [...] An LFENCE that follows an instruction that stores to memory might complete before the data being stored have become globally visible. [...] The latter meaning that the preceding store instruction finished execution and the store is at minimum guaranteed to be in the CPU's store queue, but it's not guaranteed to be in that CPU's L1 cache at that point (globally visible). The latter would only be guaranteed via sfence. So the load which is guaranteed to execute after the lfence for that local CPU would have to rely on store-to-load forwarding. [2], in section 2.3 on store buffers says: [...] For every store operation that is added to the ROB, an entry is allocated in the store buffer. This entry requires both the virtual and physical address of the target. Only if there is no free entry in the store buffer, the frontend stalls until there is an empty slot available in the store buffer again. Otherwise, the CPU can immediately continue adding subsequent instructions to the ROB and execute them out of order. On Intel CPUs, the store buffer has up to 56 entries. [...] One small upside on the fix is that it lifts constraints from af86ca4e3088 where the sanitize_stack_off relative to r10 must be the same when coming from different paths. The BPF_ST | BPF_NOSPEC gets emitted after a BPF_STX or BPF_ST instruction. This happens either when we store a pointer or data value to the BPF stack for the first time, or upon later pointer spills. The former needs to be enforced since otherwise stale stack data could be leaked under speculation as outlined earlier. For non-x86 JITs the BPF_ST | BPF_NOSPEC mapping is currently optimized away, but others could emit a speculation barrier as well if necessary. For real-world unprivileged programs e.g. generated by LLVM, pointer spill/fill is only generated upon register pressure and LLVM only tries to do that for pointers which are not used often. The program main impact will be the initial BPF_ST | BPF_NOSPEC sanitation for the STACK_INVALID case when the first write to a stack slot occurs e.g. upon map lookup. In future we might refine ways to mitigate the latter cost. [0] https://arxiv.org/pdf/1902.05178.pdf [1] https://msrc-blog.microsoft.com/2018/05/21/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/ [2] https://arxiv.org/pdf/1905.05725.pdf Fixes: af86ca4e3088 ("bpf: Prevent memory disambiguation attack") Fixes: f7cf25b2026d ("bpf: track spill/fill of constants") Co-developed-by: Piotr Krysiuk Co-developed-by: Benedict Schlueter Signed-off-by: Daniel Borkmann Signed-off-by: Piotr Krysiuk Signed-off-by: Benedict Schlueter Acked-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bea9e2fd180892eba2574711b05b794f1d0e7b73 Author: Daniel Borkmann Date: Tue Jul 13 08:18:31 2021 +0000 bpf: Introduce BPF nospec instruction for mitigating Spectre v4 [ Upstream commit f5e81d1117501546b7be050c5fbafa6efd2c722c ] In case of JITs, each of the JIT backends compiles the BPF nospec instruction /either/ to a machine instruction which emits a speculation barrier /or/ to /no/ machine instruction in case the underlying architecture is not affected by Speculative Store Bypass or has different mitigations in place already. This covers both x86 and (implicitly) arm64: In case of x86, we use 'lfence' instruction for mitigation. In case of arm64, we rely on the firmware mitigation as controlled via the ssbd kernel parameter. Whenever the mitigation is enabled, it works for all of the kernel code with no need to provide any additional instructions here (hence only comment in arm64 JIT). Other archs can follow as needed. The BPF nospec instruction is specifically targeting Spectre v4 since i) we don't use a serialization barrier for the Spectre v1 case, and ii) mitigation instructions for v1 and v4 might be different on some archs. The BPF nospec is required for a future commit, where the BPF verifier does annotate intermediate BPF programs with speculation barriers. Co-developed-by: Piotr Krysiuk Co-developed-by: Benedict Schlueter Signed-off-by: Daniel Borkmann Signed-off-by: Piotr Krysiuk Signed-off-by: Benedict Schlueter Acked-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit cd61e665a16615a00257d2974ba3db14bea33446 Author: Dan Carpenter Date: Thu Jul 29 17:12:46 2021 +0300 can: hi311x: fix a signedness bug in hi3110_cmd() [ Upstream commit f6b3c7848e66e9046c8a79a5b88fd03461cc252b ] The hi3110_cmd() is supposed to return zero on success and negative error codes on failure, but it was accidentally declared as a u8 when it needs to be an int type. Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver") Link: https://lore.kernel.org/r/20210729141246.GA1267@kili Signed-off-by: Dan Carpenter Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 65dfa6cb22337d21cc8a441e4e324c86eb886c72 Author: Wang Hai Date: Wed Jul 28 20:11:07 2021 +0800 sis900: Fix missing pci_disable_device() in probe and remove [ Upstream commit 89fb62fde3b226f99b7015280cf132e2a7438edf ] Replace pci_enable_device() with pcim_enable_device(), pci_disable_device() and pci_release_regions() will be called in release automatically. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 93e5bf4b2925cfec5299791913a118adb3f62846 Author: Wang Hai Date: Wed Jul 28 15:43:13 2021 +0800 tulip: windbond-840: Fix missing pci_disable_device() in probe and remove [ Upstream commit 76a16be07b209a3f507c72abe823bd3af1c8661a ] Replace pci_enable_device() with pcim_enable_device(), pci_disable_device() and pci_release_regions() will be called in release automatically. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 58b8c812c7641d9d9bfd1663f42dac2dbba3a560 Author: Marcelo Ricardo Leitner Date: Tue Jul 27 23:40:54 2021 -0300 sctp: fix return value check in __sctp_rcv_asconf_lookup [ Upstream commit 557fb5862c9272ad9b21407afe1da8acfd9b53eb ] As Ben Hutchings noticed, this check should have been inverted: the call returns true in case of success. Reported-by: Ben Hutchings Fixes: 0c5dc070ff3d ("sctp: validate from_addr_param return") Signed-off-by: Marcelo Ricardo Leitner Reviewed-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 362e9d23cf70896c65a436667449cb2d277b930f Author: Dima Chumak Date: Mon Apr 26 15:16:26 2021 +0300 net/mlx5e: Fix nullptr in mlx5e_hairpin_get_mdev() [ Upstream commit b1c2f6312c5005c928a72e668bf305a589d828d4 ] The result of __dev_get_by_index() is not checked for NULL and then gets dereferenced immediately. Also, __dev_get_by_index() must be called while holding either RTNL lock or @dev_base_lock, which isn't satisfied by mlx5e_hairpin_get_mdev() or its callers. This makes the underlying hlist_for_each_entry() loop not safe, and can have adverse effects in itself. Fix by using dev_get_by_index() and handling nullptr return value when ifindex device is not found. Update mlx5e_hairpin_get_mdev() callers to check for possible PTR_ERR() result. Fixes: 77ab67b7f0f9 ("net/mlx5e: Basic setup of hairpin object") Addresses-Coverity: ("Dereference null return value") Signed-off-by: Dima Chumak Reviewed-by: Vlad Buslov Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit bd744f2a275573f29811ebf4f0716b120c0036fd Author: Maor Gottlieb Date: Mon Jul 26 09:20:14 2021 +0300 net/mlx5: Fix flow table chaining [ Upstream commit 8b54874ef1617185048029a3083d510569e93751 ] Fix a bug when flow table is created in priority that already has other flow tables as shown in the below diagram. If the new flow table (FT-B) has the lowest level in the priority, we need to connect the flow tables from the previous priority (p0) to this new table. In addition when this flow table is destroyed (FT-B), we need to connect the flow tables from the previous priority (p0) to the next level flow table (FT-C) in the same priority of the destroyed table (if exists). --------- |root_ns| --------- | -------------------------------- | | | ---------- ---------- --------- |p(prio)-x| | p-y | | p-n | ---------- ---------- --------- | | ---------------- ------------------ |ns(e.g bypass)| |ns(e.g. kernel) | ---------------- ------------------ | | | ------- ------ ---- | p0 | | p1 | |p2| ------- ------ ---- | | \ -------- ------- ------ | FT-A | |FT-B | |FT-C| -------- ------- ------ Fixes: f90edfd279f3 ("net/mlx5_core: Connect flow tables") Signed-off-by: Maor Gottlieb Reviewed-by: Mark Bloch Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 1b148bd72e507543c4cac5689a204053bf877337 Author: Cong Wang Date: Wed Jan 27 14:15:01 2021 -0800 skmsg: Make sk_psock_destroy() static [ Upstream commit 8063e184e49011f6f3f34f6c358dc8a83890bb5b ] sk_psock_destroy() is a RCU callback, I can't see any reason why it could be used outside. Signed-off-by: Cong Wang Signed-off-by: Daniel Borkmann Cc: John Fastabend Cc: Jakub Sitnicki Cc: Lorenz Bauer Link: https://lore.kernel.org/bpf/20210127221501.46866-1-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin commit 645a1d3bef5f149f853a5815c437b16b290583e0 Author: Bjorn Andersson Date: Wed Jul 21 19:44:34 2021 -0700 drm/msm/dp: Initialize the INTF_CONFIG register [ Upstream commit f9a39932fa54b6421e751ada7a285da809146421 ] Some bootloaders set the widebus enable bit in the INTF_CONFIG register, but configuration of widebus isn't yet supported ensure that the register has a known value, with widebus disabled. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Bjorn Andersson Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20210722024434.3313167-1-bjorn.andersson@linaro.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 4a6841921cc818ebaa10a74b799867d149de2d1e Author: Robert Foss Date: Mon Jun 28 10:50:33 2021 +0200 drm/msm/dpu: Fix sm8250_mdp register length [ Upstream commit b910a0206b59eb90ea8ff76d146f4c3156da61e9 ] The downstream dts lists this value as 0x494, and not 0x45c. Fixes: af776a3e1c30 ("drm/msm/dpu: add SM8250 to hw catalog") Signed-off-by: Robert Foss Reviewed-by: Dmitry Baryshkov Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20210628085033.9905-1-robert.foss@linaro.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit e6097071a4ff4b9543adb1c041a3708d5606c35c Author: Pavel Skripkin Date: Sun Jul 25 00:11:59 2021 +0300 net: llc: fix skb_over_panic [ Upstream commit c7c9d2102c9c098916ab9e0ab248006107d00d6c ] Syzbot reported skb_over_panic() in llc_pdu_init_as_xid_cmd(). The problem was in wrong LCC header manipulations. Syzbot's reproducer tries to send XID packet. llc_ui_sendmsg() is doing following steps: 1. skb allocation with size = len + header size len is passed from userpace and header size is 3 since addr->sllc_xid is set. 2. skb_reserve() for header_len = 3 3. filling all other space with memcpy_from_msg() Ok, at this moment we have fully loaded skb, only headers needs to be filled. Then code comes to llc_sap_action_send_xid_c(). This function pushes 3 bytes for LLC PDU header and initializes it. Then comes llc_pdu_init_as_xid_cmd(). It initalizes next 3 bytes *AFTER* LLC PDU header and call skb_push(skb, 3). This looks wrong for 2 reasons: 1. Bytes rigth after LLC header are user data, so this function was overwriting payload. 2. skb_push(skb, 3) call can cause skb_over_panic() since all free space was filled in llc_ui_sendmsg(). (This can happen is user passed 686 len: 686 + 14 (eth header) + 3 (LLC header) = 703. SKB_DATA_ALIGN(703) = 704) So, in this patch I added 2 new private constansts: LLC_PDU_TYPE_U_XID and LLC_PDU_LEN_U_XID. LLC_PDU_LEN_U_XID is used to correctly reserve header size to handle LLC + XID case. LLC_PDU_TYPE_U_XID is used by llc_pdu_header_init() function to push 6 bytes instead of 3. And finally I removed skb_push() call from llc_pdu_init_as_xid_cmd(). This changes should not affect other parts of LLC, since after all steps we just transmit buffer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: syzbot+5e5a981ad7cc54c4b2b4@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 01f3581d4400f6586403409c5c3a3128fbb3e336 Author: Vitaly Kuznetsov Date: Thu Jul 22 14:30:18 2021 +0200 KVM: x86: Check the right feature bit for MSR_KVM_ASYNC_PF_ACK access [ Upstream commit 0a31df6823232516f61f174907e444f710941dfe ] MSR_KVM_ASYNC_PF_ACK MSR is part of interrupt based asynchronous page fault interface and not the original (deprecated) KVM_FEATURE_ASYNC_PF. This is stated in Documentation/virt/kvm/msr.rst. Fixes: 66570e966dd9 ("kvm: x86: only provide PV features if enabled in guest's CPUID") Signed-off-by: Vitaly Kuznetsov Reviewed-by: Maxim Levitsky Reviewed-by: Oliver Upton Message-Id: <20210722123018.260035-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit f5f78ae5f1bed58742cfe07b10c8233ec163f2ce Author: Jiapeng Chong Date: Fri Jul 23 18:36:09 2021 +0800 mlx4: Fix missing error code in mlx4_load_one() [ Upstream commit 7e4960b3d66d7248b23de3251118147812b42da2 ] The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'err'. Eliminate the follow smatch warning: drivers/net/ethernet/mellanox/mlx4/main.c:3538 mlx4_load_one() warn: missing error code 'err'. Reported-by: Abaci Robot Fixes: 7ae0e400cd93 ("net/mlx4_core: Flexible (asymmetric) allocation of EQs and MSI-X vectors for PF/VFs") Signed-off-by: Jiapeng Chong Reviewed-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 51b751fc06b8dd4fd787586eed373a563e3bd991 Author: Geetha sowjanya Date: Sun Jul 25 13:29:03 2021 +0530 octeontx2-pf: Fix interface down flag on error [ Upstream commit 69f0aeb13bb548e2d5710a350116e03f0273302e ] In the existing code while changing the number of TX/RX queues using ethtool the PF/VF interface resources are freed and reallocated (otx2_stop and otx2_open is called) if the device is in running state. If any resource allocation fails in otx2_open, driver free already allocated resources and return. But again, when the number of queues changes as the device state still running oxt2_stop is called. In which we try to free already freed resources leading to driver crash. This patch fixes the issue by setting the INTF_DOWN flag on error and free the resources in otx2_stop only if the flag is not set. Fixes: 50fe6c02e5ad ("octeontx2-pf: Register and handle link notifications") Signed-off-by: Geetha sowjanya Signed-off-by: Sunil Kovvuri Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4951ffa3fac8892949a09b630191ff12f35f4b72 Author: Xin Long Date: Fri Jul 23 18:46:01 2021 -0400 tipc: do not write skb_shinfo frags when doing decrytion [ Upstream commit 3cf4375a090473d240281a0d2b04a3a5aaeac34b ] One skb's skb_shinfo frags are not writable, and they can be shared with other skbs' like by pskb_copy(). To write the frags may cause other skb's data crash. So before doing en/decryption, skb_cow_data() should always be called for a cloned or nonlinear skb if req dst is using the same sg as req src. While at it, the likely branch can be removed, as it will be covered by skb_cow_data(). Note that esp_input() has the same issue, and I will fix it in another patch. tipc_aead_encrypt() doesn't have this issue, as it only processes linear data in the unlikely branch. Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Reported-by: Shuang Li Signed-off-by: Xin Long Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7eefa0b74f3e55dec85edfe5f5270c6f8b598155 Author: Shannon Nelson Date: Fri Jul 23 11:02:49 2021 -0700 ionic: count csum_none when offload enabled [ Upstream commit f07f9815b7046e25cc32bf8542c9c0bbc5eb6e0e ] Be sure to count the csum_none cases when csum offload is enabled. Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 60decbe01d7d711d4626a855213350ea02bfd41c Author: Shannon Nelson Date: Fri Jul 23 11:02:48 2021 -0700 ionic: fix up dim accounting for tx and rx [ Upstream commit 76ed8a4a00b484dcccef819ef2618bcf8e46f560 ] We need to count the correct Tx and/or Rx packets for dynamic interrupt moderation, depending on which we're processing on the queue interrupt. Fixes: 04a834592bf5 ("ionic: dynamic interrupt moderation") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a7c85a516cd0e7dc73912311f8b1ab40b6b53cad Author: Shannon Nelson Date: Fri Jul 23 11:02:47 2021 -0700 ionic: remove intr coalesce update from napi [ Upstream commit a6ff85e0a2d9d074a4b4c291ba9ec1e5b0aba22b ] Move the interrupt coalesce value update out of the napi thread and into the dim_work thread and set it only when it has actually changed. Fixes: 04a834592bf5 ("ionic: dynamic interrupt moderation") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6961323eed46d6aee7b87ec758580d334579438c Author: Pavel Skripkin Date: Fri Jul 23 18:31:32 2021 +0300 net: qrtr: fix memory leaks [ Upstream commit 52f3456a96c06760b9bfae460e39596fec7af22e ] Syzbot reported memory leak in qrtr. The problem was in unputted struct sock. qrtr_local_enqueue() function calls qrtr_port_lookup() which takes sock reference if port was found. Then there is the following check: if (!ipc || &ipc->sk == skb->sk) { ... return -ENODEV; } Since we should drop the reference before returning from this function and ipc can be non-NULL inside this if, we should add qrtr_port_put() inside this if. The similar corner case is in qrtr_endpoint_post() as Manivannan reported. In case of sock_queue_rcv_skb() failure we need to put port reference to avoid leaking struct sock pointer. Fixes: e04df98adf7d ("net: qrtr: Remove receive worker") Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Reported-and-tested-by: syzbot+35a511c72ea7356cdcf3@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Reviewed-by: Manivannan Sadhasivam Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 91350564ea8c0d72b9d60d1bace5adb090c97193 Author: Gilad Naaman Date: Thu Jul 22 20:01:28 2021 +0300 net: Set true network header for ECN decapsulation [ Upstream commit 227adfb2b1dfbc53dfc53b9dd7a93a6298ff7c56 ] In cases where the header straight after the tunnel header was another ethernet header (TEB), instead of the network header, the ECN decapsulation code would treat the ethernet header as if it was an IP header, resulting in mishandling and possible wrong drops or corruption of the IP header. In this case, ECT(1) is sent, so IP_ECN_decapsulate tries to copy it to the inner IPv4 header, and correct its checksum. The offset of the ECT bits in an IPv4 header corresponds to the lower 2 bits of the second octet of the destination MAC address in the ethernet header. The IPv4 checksum corresponds to end of the source address. In order to reproduce: $ ip netns add A $ ip netns add B $ ip -n A link add _v0 type veth peer name _v1 netns B $ ip -n A link set _v0 up $ ip -n A addr add dev _v0 10.254.3.1/24 $ ip -n A route add default dev _v0 scope global $ ip -n B link set _v1 up $ ip -n B addr add dev _v1 10.254.1.6/24 $ ip -n B route add default dev _v1 scope global $ ip -n B link add gre1 type gretap local 10.254.1.6 remote 10.254.3.1 key 0x49000000 $ ip -n B link set gre1 up # Now send an IPv4/GRE/Eth/IPv4 frame where the outer header has ECT(1), # and the inner header has no ECT bits set: $ cat send_pkt.py #!/usr/bin/env python3 from scapy.all import * pkt = IP(b'E\x01\x00\xa7\x00\x00\x00\x00@/`%\n\xfe\x03\x01\n\xfe\x01\x06 \x00eXI\x00' b'\x00\x00\x18\xbe\x92\xa0\xee&\x18\xb0\x92\xa0l&\x08\x00E\x00\x00}\x8b\x85' b'@\x00\x01\x01\xe4\xf2\x82\x82\x82\x01\x82\x82\x82\x02\x08\x00d\x11\xa6\xeb' b'3\x1e\x1e\\xf3\\xf7`\x00\x00\x00\x00ZN\x00\x00\x00\x00\x00\x00\x10\x11\x12' b'\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !"#$%&\'()*+,-./01234' b'56789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ') send(pkt) $ sudo ip netns exec B tcpdump -neqlllvi gre1 icmp & ; sleep 1 $ sudo ip netns exec A python3 send_pkt.py In the original packet, the source/destinatio MAC addresses are dst=18:be:92:a0:ee:26 src=18:b0:92:a0:6c:26 In the received packet, they are dst=18:bd:92:a0:ee:26 src=18:b0:92:a0:6c:27 Thanks to Lahav Schlesinger and Isaac Garzon for helping me pinpoint the origin. Fixes: b723748750ec ("tunnel: Propagate ECT(1) when decapsulating as recommended by RFC6040") Cc: David S. Miller Cc: Hideaki YOSHIFUJI Cc: David Ahern Cc: Jakub Kicinski Cc: Toke Høiland-Jørgensen Signed-off-by: Gilad Naaman Acked-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a41282e82a1d13ad2cca0f07879d7042780d8e78 Author: Hoang Le Date: Fri Jul 23 09:25:34 2021 +0700 tipc: fix sleeping in tipc accept routine [ Upstream commit d237a7f11719ff9320721be5818352e48071aab6 ] The release_sock() is blocking function, it would change the state after sleeping. In order to evaluate the stated condition outside the socket lock context, switch to use wait_woken() instead. Fixes: 6398e23cdb1d8 ("tipc: standardize accept routine") Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 10f585740cf0bf5b037a70a4d4eb3096fd713490 Author: Xin Long Date: Thu Jul 22 12:05:41 2021 -0400 tipc: fix implicit-connect for SYN+ [ Upstream commit f8dd60de194817c86bf812700980762bb5a8d9a4 ] For implicit-connect, when it's either SYN- or SYN+, an ACK should be sent back to the client immediately. It's not appropriate for the client to enter established state only after receiving data from the server. On client side, after the SYN is sent out, tipc_wait_for_connect() should be called to wait for the ACK if timeout is set. This patch also restricts __tipc_sendstream() to call __sendmsg() only when it's in TIPC_OPEN state, so that the client can program in a single loop doing both connecting and data sending like: for (...) sendmsg(dest, buf); This makes the implicit-connect more implicit. Fixes: b97bf3fd8f6a ("[TIPC] Initial merge") Signed-off-by: Xin Long Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bb60616162113653d181fe7490354ef57e520fa9 Author: Jedrzej Jagielski Date: Fri Jun 18 08:49:49 2021 +0000 i40e: Fix log TC creation failure when max num of queues is exceeded [ Upstream commit ea52faae1d17cd3048681d86d2e8641f44de484d ] Fix missing failed message if driver does not have enough queues to complete TC command. Without this fix no message is displayed in dmesg. Fixes: a9ce82f744dc ("i40e: Enable 'channel' mode in mqprio for TC configs") Signed-off-by: Grzegorz Szczurek Signed-off-by: Jedrzej Jagielski Tested-by: Imam Hassan Reza Biswas Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit c1cc6bce1afd096b2a3a482de6278e4d181e33ff Author: Jedrzej Jagielski Date: Wed Jun 2 00:47:03 2021 +0000 i40e: Fix queue-to-TC mapping on Tx [ Upstream commit 89ec1f0886c127c7e41ac61a6b6d539f4fb2510b ] In SW DCB mode the packets sent receive incorrect UP tags. They are constructed correctly and put into tx_ring, but UP is later remapped by HW on the basis of TCTUPR register contents according to Tx queue selected, and BW used is consistent with the new UP values. This is caused by Tx queue selection in kernel not taking into account DCB configuration. This patch fixes the issue by implementing the ndo_select_queue NDO callback. Fixes: fd0a05ce74ef ("i40e: transmit, receive, and NAPI") Signed-off-by: Arkadiusz Kubalewski Signed-off-by: Jedrzej Jagielski Tested-by: Imam Hassan Reza Biswas Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4382cca179153d08e0a938d4e97514e5d31e08e2 Author: Arkadiusz Kubalewski Date: Fri May 21 18:41:26 2021 +0200 i40e: Fix firmware LLDP agent related warning [ Upstream commit 71d6fdba4b2d82fdd883fec31dee77fbcf59773a ] Make warning meaningful for the user. Previously the trace: "Starting FW LLDP agent failed: error: I40E_ERR_ADMIN_QUEUE_ERROR, I40E_AQ_RC_EAGAIN" was produced when user tried to start Firmware LLDP agent, just after it was stopped with sequence: ethtool --set-priv-flags disable-fw-lldp on ethtool --set-priv-flags disable-fw-lldp off (without any delay between the commands) At that point the firmware is still processing stop command, the behavior is expected. Fixes: c1041d070437 ("i40e: Missing response checks in driver when starting/stopping FW LLDP") Signed-off-by: Aleksandr Loktionov Signed-off-by: Arkadiusz Kubalewski Tested-by: Imam Hassan Reza Biswas Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e090ffdf056361230797fc170b226bd6ab81b4aa Author: Arkadiusz Kubalewski Date: Thu Apr 29 19:49:47 2021 +0200 i40e: Fix logic of disabling queues [ Upstream commit 65662a8dcdd01342b71ee44234bcfd0162e195af ] Correct the message flow between driver and firmware when disabling queues. Previously in case of PF reset (due to required reinit after reconfig), the error like: "VSI seid 397 Tx ring 60 disable timeout" could show up occasionally. The error was not a real issue of hardware or firmware, it was caused by wrong sequence of messages invoked by the driver. Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Aleksandr Loktionov Signed-off-by: Arkadiusz Kubalewski Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit cbc8012902b34516cae039f12435b78be80493a3 Author: Pablo Neira Ayuso Date: Tue Jul 20 18:22:50 2021 +0200 netfilter: nft_nat: allow to specify layer 4 protocol NAT only [ Upstream commit a33f387ecd5aafae514095c2c4a8c24f7aea7e8b ] nft_nat reports a bogus EAFNOSUPPORT if no layer 3 information is specified. Fixes: d07db9884a5f ("netfilter: nf_tables: introduce nft_validate_register_load()") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3dbda8483f4256530a926dcb6063656a17fe62d9 Author: Florian Westphal Date: Sun Jul 18 18:36:00 2021 +0200 netfilter: conntrack: adjust stop timestamp to real expiry value [ Upstream commit 30a56a2b881821625f79837d4d968c679852444e ] In case the entry is evicted via garbage collection there is delay between the timeout value and the eviction event. This adjusts the stop value based on how much time has passed. Fixes: b87a2f9199ea82 ("netfilter: conntrack: add gc worker to remove timed-out entries") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ac038f4152efd8b4ad86e50df913bd318dc6daa8 Author: Felix Fietkau Date: Fri Jul 2 07:01:11 2021 +0200 mac80211: fix enabling 4-address mode on a sta vif after assoc [ Upstream commit a5d3cbdb09ff1f52cbe040932e06c8b9915c6dad ] Notify the driver about the 4-address mode change and also send a nulldata packet to the AP to notify it about the change Fixes: 1ff4e8f2dec8 ("mac80211: notify the driver when a sta uses 4-address mode") Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20210702050111.47546-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 076bc6ebce48e8144ba9d73c4f37f3a7b7ea66bf Author: Lorenz Bauer Date: Mon Jul 19 09:51:34 2021 +0100 bpf: Fix OOB read when printing XDP link fdinfo [ Upstream commit d6371c76e20d7d3f61b05fd67b596af4d14a8886 ] We got the following UBSAN report on one of our testing machines: ================================================================================ UBSAN: array-index-out-of-bounds in kernel/bpf/syscall.c:2389:24 index 6 is out of range for type 'char *[6]' CPU: 43 PID: 930921 Comm: systemd-coredum Tainted: G O 5.10.48-cloudflare-kasan-2021.7.0 #1 Hardware name: Call Trace: dump_stack+0x7d/0xa3 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold+0x43/0x48 ? seq_printf+0x17d/0x250 bpf_link_show_fdinfo+0x329/0x380 ? bpf_map_value_size+0xe0/0xe0 ? put_files_struct+0x20/0x2d0 ? __kasan_kmalloc.constprop.0+0xc2/0xd0 seq_show+0x3f7/0x540 seq_read_iter+0x3f8/0x1040 seq_read+0x329/0x500 ? seq_read_iter+0x1040/0x1040 ? __fsnotify_parent+0x80/0x820 ? __fsnotify_update_child_dentry_flags+0x380/0x380 vfs_read+0x123/0x460 ksys_read+0xed/0x1c0 ? __x64_sys_pwrite64+0x1f0/0x1f0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ================================================================================ ================================================================================ UBSAN: object-size-mismatch in kernel/bpf/syscall.c:2384:2 From the report, we can infer that some array access in bpf_link_show_fdinfo at index 6 is out of bounds. The obvious candidate is bpf_link_type_strs[BPF_LINK_TYPE_XDP] with BPF_LINK_TYPE_XDP == 6. It turns out that BPF_LINK_TYPE_XDP is missing from bpf_types.h and therefore doesn't have an entry in bpf_link_type_strs: pos: 0 flags: 02000000 mnt_id: 13 link_type: (null) link_id: 4 prog_tag: bcf7977d3b93787c prog_id: 4 ifindex: 1 Fixes: aa8d3a716b59 ("bpf, xdp: Add bpf_link-based XDP attachment API") Signed-off-by: Lorenz Bauer Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210719085134.43325-2-lmb@cloudflare.com Signed-off-by: Sasha Levin commit e6a06a13ec6f6a9b88d5fdc11e3ea0cc8860890e Author: Naresh Kumar PBS Date: Sun Jul 11 06:31:36 2021 -0700 RDMA/bnxt_re: Fix stats counters [ Upstream commit 0c23af52ccd1605926480b5dfd1dd857ef604611 ] Statistical counters are not incrementing in some adapter versions with newer FW. This is due to the stats context length mismatch between FW and driver. Since the L2 driver updates the length correctly, use the stats length from L2 driver while allocating the DMA'able memory and creating the stats context. Fixes: 9d6b648c3112 ("bnxt_en: Update firmware interface spec to 1.10.1.65.") Link: https://lore.kernel.org/r/1626010296-6076-1-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Naresh Kumar PBS Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c8667cb406fdae6718e7dbd4d0b2c85ad1eb9d9d Author: Nguyen Dinh Phi Date: Mon Jun 28 21:23:34 2021 +0800 cfg80211: Fix possible memory leak in function cfg80211_bss_update commit f9a5c358c8d26fed0cc45f2afc64633d4ba21dff upstream. When we exceed the limit of BSS entries, this function will free the new entry, however, at this time, it is the last door to access the inputed ies, so these ies will be unreferenced objects and cause memory leak. Therefore we should free its ies before deallocating the new entry, beside of dropping it from hidden_list. Signed-off-by: Nguyen Dinh Phi Link: https://lore.kernel.org/r/20210628132334.851095-1-phind.uet@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9ab284bc35307ffde4f385dd8f3cf853fd9bb264 Author: Krzysztof Kozlowski Date: Wed Jul 28 08:49:09 2021 +0200 nfc: nfcsim: fix use after free during module unload commit 5e7b30d24a5b8cb691c173b45b50e3ca0191be19 upstream. There is a use after free memory corruption during module exit: - nfcsim_exit() - nfcsim_device_free(dev0) - nfc_digital_unregister_device() This iterates over command queue and frees all commands, - dev->up = false - nfcsim_link_shutdown() - nfcsim_link_recv_wake() This wakes the sleeping thread nfcsim_link_recv_skb(). - nfcsim_link_recv_skb() Wake from wait_event_interruptible_timeout(), call directly the deb->cb callback even though (dev->up == false), - digital_send_cmd_complete() Dereference of "struct digital_cmd" cmd which was freed earlier by nfc_digital_unregister_device(). This causes memory corruption shortly after (with unrelated stack trace): nfc nfc0: NFC: nfcsim_recv_wq: Device is down llcp: nfc_llcp_recv: err -19 nfc nfc1: NFC: nfcsim_recv_wq: Device is down BUG: unable to handle page fault for address: ffffffffffffffed Call Trace: fsnotify+0x54b/0x5c0 __fsnotify_parent+0x1fe/0x300 ? vfs_write+0x27c/0x390 vfs_write+0x27c/0x390 ksys_write+0x63/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae KASAN report: BUG: KASAN: use-after-free in digital_send_cmd_complete+0x16/0x50 Write of size 8 at addr ffff88800a05f720 by task kworker/0:2/71 Workqueue: events nfcsim_recv_wq [nfcsim] Call Trace:  dump_stack_lvl+0x45/0x59  print_address_description.constprop.0+0x21/0x140  ? digital_send_cmd_complete+0x16/0x50  ? digital_send_cmd_complete+0x16/0x50  kasan_report.cold+0x7f/0x11b  ? digital_send_cmd_complete+0x16/0x50  ? digital_dep_link_down+0x60/0x60  digital_send_cmd_complete+0x16/0x50  nfcsim_recv_wq+0x38f/0x3d5 [nfcsim]  ? nfcsim_in_send_cmd+0x4a/0x4a [nfcsim]  ? lock_is_held_type+0x98/0x110  ? finish_wait+0x110/0x110  ? rcu_read_lock_sched_held+0x9c/0xd0  ? rcu_read_lock_bh_held+0xb0/0xb0  ? lockdep_hardirqs_on_prepare+0x12e/0x1f0 This flow of calling digital_send_cmd_complete() callback on driver exit is specific to nfcsim which implements reading and sending work queues. Since the NFC digital device was unregistered, the callback should not be called. Fixes: 204bddcb508f ("NFC: nfcsim: Make use of the Digital layer") Cc: Signed-off-by: Krzysztof Kozlowski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ea04a3b5727e571f628e59b907db9f0c8bdd0d5d Author: Tejun Heo Date: Tue Jul 27 14:38:09 2021 -1000 blk-iocost: fix operation ordering in iocg_wake_fn() commit 5ab189cf3abbc9994bae3be524c5b88589ed56e2 upstream. iocg_wake_fn() open-codes wait_queue_entry removal and wakeup because it wants the wq_entry to be always removed whether it ended up waking the task or not. finish_wait() tests whether wq_entry needs removal without grabbing the wait_queue lock and expects the waker to use list_del_init_careful() after all waking operations are complete, which iocg_wake_fn() didn't do. The operation order was wrong and the regular list_del_init() was used. The result is that if a waiter wakes up racing the waker, it can free pop the wq_entry off stack before the waker is still looking at it, which can lead to a backtrace like the following. [7312084.588951] general protection fault, probably for non-canonical address 0x586bf4005b2b88: 0000 [#1] SMP ... [7312084.647079] RIP: 0010:queued_spin_lock_slowpath+0x171/0x1b0 ... [7312084.858314] Call Trace: [7312084.863548] _raw_spin_lock_irqsave+0x22/0x30 [7312084.872605] try_to_wake_up+0x4c/0x4f0 [7312084.880444] iocg_wake_fn+0x71/0x80 [7312084.887763] __wake_up_common+0x71/0x140 [7312084.895951] iocg_kick_waitq+0xe8/0x2b0 [7312084.903964] ioc_rqos_throttle+0x275/0x650 [7312084.922423] __rq_qos_throttle+0x20/0x30 [7312084.930608] blk_mq_make_request+0x120/0x650 [7312084.939490] generic_make_request+0xca/0x310 [7312084.957600] submit_bio+0x173/0x200 [7312084.981806] swap_readpage+0x15c/0x240 [7312084.989646] read_swap_cache_async+0x58/0x60 [7312084.998527] swap_cluster_readahead+0x201/0x320 [7312085.023432] swapin_readahead+0x2df/0x450 [7312085.040672] do_swap_page+0x52f/0x820 [7312085.058259] handle_mm_fault+0xa16/0x1420 [7312085.066620] do_page_fault+0x2c6/0x5c0 [7312085.074459] page_fault+0x2f/0x40 Fix it by switching to list_del_init_careful() and putting it at the end. Signed-off-by: Tejun Heo Reported-by: Rik van Riel Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit fc2756cce06f9833ebabd309b5b5080ed5c56897 Author: Jiri Kosina Date: Thu Jun 24 13:20:21 2021 +0200 drm/amdgpu: Fix resource leak on probe error path commit d47255d3f87338164762ac56df1f28d751e27246 upstream. This reverts commit 4192f7b5768912ceda82be2f83c87ea7181f9980. It is not true (as stated in the reverted commit changelog) that we never unmap the BAR on failure; it actually does happen properly on amdgpu_driver_load_kms() -> amdgpu_driver_unload_kms() -> amdgpu_device_fini() error path. What's worse, this commit actually completely breaks resource freeing on probe failure (like e.g. failure to load microcode), as amdgpu_driver_unload_kms() notices adev->rmmio being NULL and bails too early, leaving all the resources that'd normally be freed in amdgpu_acpi_fini() and amdgpu_device_fini() still hanging around, leading to all sorts of oopses when someone tries to, for example, access the sysfs and procfs resources which are still around while the driver is gone. Fixes: 4192f7b57689 ("drm/amdgpu: unmap register bar on device init failure") Reported-by: Vojtech Pavlik Signed-off-by: Jiri Kosina Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ccc7a1bb322e4169b738aa3fc8b5dfcfefdacb37 Author: Jiri Kosina Date: Thu Jun 24 13:11:36 2021 +0200 drm/amdgpu: Avoid printing of stack contents on firmware load error commit 6aade587d329ebe88319dfdb8e8c7b6aede80417 upstream. In case when psp_init_asd_microcode() fails to load ASD microcode file, psp_v12_0_init_microcode() tries to print the firmware filename that failed to load before bailing out. This is wrong because: - the firmware filename it would want it print is an incorrect one as psp_init_asd_microcode() and psp_v12_0_init_microcode() are loading different filenames - it tries to print fw_name, but that's not yet been initialized by that time, so it prints random stack contents, e.g. amdgpu 0000:04:00.0: Direct firmware load for amdgpu/renoir_asd.bin failed with error -2 amdgpu 0000:04:00.0: amdgpu: fail to initialize asd microcode amdgpu 0000:04:00.0: amdgpu: psp v12.0: Failed to load firmware "\xfeTO\x8e\xff\xff" Fix that by bailing out immediately, instead of priting the bogus error message. Reported-by: Vojtech Pavlik Signed-off-by: Jiri Kosina Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 63570e578094b4f0b6b8c6ac4a68195455733e31 Author: Dale Zhao Date: Fri Jul 16 09:38:17 2021 +0800 drm/amd/display: ensure dentist display clock update finished in DCN20 commit b53e041d8e4308f7324999398aec092dbcb130f5 upstream. [Why] We don't check DENTIST_DISPCLK_CHG_DONE to ensure dentist display clockis updated to target value. In some scenarios with large display clock margin, it will deliver unfinished display clock and cause issues like display black screen. [How] Checking DENTIST_DISPCLK_CHG_DONE to ensure display clock has been update to target value before driver do other clock related actions. Reviewed-by: Cyr Aric Acked-by: Solomon Chiu Signed-off-by: Dale Zhao Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2eab387507fd449e08014cca0de79a37b2d27744 Author: Paul Jakma Date: Fri Jul 23 16:13:04 2021 +0100 NIU: fix incorrect error return, missed in previous revert commit 15bbf8bb4d4ab87108ecf5f4155ec8ffa3c141d6 upstream. Commit 7930742d6, reverting 26fd962, missed out on reverting an incorrect change to a return value. The niu_pci_vpd_scan_props(..) == 1 case appears to be a normal path - treating it as an error and return -EINVAL was breaking VPD_SCAN and causing the driver to fail to load. Fix, so my Neptune card works again. Cc: Kangjie Lu Cc: Shannon Nelson Cc: David S. Miller Cc: Greg Kroah-Hartman Cc: stable Fixes: 7930742d ('Revert "niu: fix missing checks of niu_pci_eeprom_read"') Signed-off-by: Paul Jakma Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cb71730a6312ae363f31350976cb378e53be7433 Author: Jason Gerecke Date: Mon Jul 19 13:55:28 2021 -0700 HID: wacom: Re-enable touch by default for Cintiq 24HDT / 27QHDT commit 6ca2350e11f09d5d3e53777d1eff8ff6d300ed93 upstream. Commit 670e90924bfe ("HID: wacom: support named keys on older devices") added support for sending named events from the soft buttons on the 24HDT and 27QHDT. In the process, however, it inadvertantly disabled the touchscreen of the 24HDT and 27QHDT by default. The `wacom_set_shared_values` function would normally enable touch by default but because it checks the state of the non-shared `has_mute_touch_switch` flag and `wacom_setup_touch_input_capabilities` sets the state of the /shared/ version, touch ends up being disabled by default. This patch sets the non-shared flag, letting `wacom_set_shared_values` take care of copying the value over to the shared version and setting the default touch state to "on". Fixes: 670e90924bfe ("HID: wacom: support named keys on older devices") CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Jason Gerecke Reviewed-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 7bca5da0053941131ba30479b22ac7091a2da91b Author: Mike Rapoport Date: Tue Jul 27 23:38:24 2021 +0300 alpha: register early reserved memory in memblock commit 640b7ea5f888b521dcf28e2564ce75d08a783fd7 upstream. The memory reserved by console/PALcode or non-volatile memory is not added to memblock.memory. Since commit fa3354e4ea39 (mm: free_area_init: use maximal zone PFNs rather than zone sizes) the initialization of the memory map relies on the accuracy of memblock.memory to properly calculate zone sizes. The holes in memblock.memory caused by absent regions reserved by the firmware cause incorrect initialization of struct pages which leads to BUG() during the initial page freeing: BUG: Bad page state in process swapper pfn:2ffc53 page:fffffc000ecf14c0 refcount:0 mapcount:1 mapping:0000000000000000 index:0x0 flags: 0x0() raw: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 page dumped because: nonzero mapcount Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-03841-gfa3354e4ea39-dirty #26 fffffc0001b5bd68 fffffc0001b5be80 fffffc00011cd148 fffffc000ecf14c0 fffffc00019803df fffffc0001b5be80 fffffc00011ce340 fffffc000ecf14c0 0000000000000000 fffffc0001b5be80 fffffc0001b482c0 fffffc00027d6618 fffffc00027da7d0 00000000002ff97a 0000000000000000 fffffc0001b5be80 fffffc00011d1abc fffffc000ecf14c0 fffffc0002d00000 fffffc0001b5be80 fffffc0001b2350c 0000000000300000 fffffc0001b48298 fffffc0001b482c0 Trace: [] bad_page+0x168/0x1b0 [] free_pcp_prepare+0x1e0/0x290 [] free_unref_page+0x2c/0xa0 [] cmp_ex_sort+0x0/0x30 [] cmp_ex_sort+0x0/0x30 [] _stext+0x1c/0x20 Fix this by registering the reserved ranges in memblock.memory. Link: https://lore.kernel.org/lkml/20210726192311.uffqnanxw3ac5wwi@ivybridge Fixes: fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than zone sizes") Reported-by: Matt Turner Cc: Signed-off-by: Mike Rapoport Signed-off-by: Matt Turner Signed-off-by: Greg Kroah-Hartman commit 30e19d072ea08766adcb280f4562b05fba88d37d Author: Pavel Skripkin Date: Tue Jul 27 20:00:46 2021 +0300 can: esd_usb2: fix memory leak commit 928150fad41ba16df7fcc9f7f945747d0f56cbb6 upstream. In esd_usb2_setup_rx_urbs() MAX_RX_URBS coherent buffers are allocated and there is nothing, that frees them: 1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see esd_usb2_setup_rx_urbs) and this flag cannot be used with coherent buffers. So, all allocated buffers should be freed with usb_free_coherent() explicitly. Side note: This code looks like a copy-paste of other can drivers. The same patch was applied to mcba_usb driver and it works nice with real hardware. There is no change in functionality, only clean-up code for coherent buffers. Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") Link: https://lore.kernel.org/r/b31b096926dcb35998ad0271aac4b51770ca7cc8.1627404470.git.paskripkin@gmail.com Cc: linux-stable Signed-off-by: Pavel Skripkin Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 88b40258162b277016bbec2a9679418c223dca25 Author: Pavel Skripkin Date: Tue Jul 27 20:00:33 2021 +0300 can: ems_usb: fix memory leak commit 9969e3c5f40c166e3396acc36c34f9de502929f6 upstream. In ems_usb_start() MAX_RX_URBS coherent buffers are allocated and there is nothing, that frees them: 1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see ems_usb_start) and this flag cannot be used with coherent buffers. So, all allocated buffers should be freed with usb_free_coherent() explicitly. Side note: This code looks like a copy-paste of other can drivers. The same patch was applied to mcba_usb driver and it works nice with real hardware. There is no change in functionality, only clean-up code for coherent buffers. Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Link: https://lore.kernel.org/r/59aa9fbc9a8cbf9af2bbd2f61a659c480b415800.1627404470.git.paskripkin@gmail.com Cc: linux-stable Signed-off-by: Pavel Skripkin Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit f58ac91ff87daf7362b1acd6445d14f7cc90c6ad Author: Pavel Skripkin Date: Tue Jul 27 19:59:57 2021 +0300 can: usb_8dev: fix memory leak commit 0e865f0c31928d6a313269ef624907eec55287c4 upstream. In usb_8dev_start() MAX_RX_URBS coherent buffers are allocated and there is nothing, that frees them: 1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see usb_8dev_start) and this flag cannot be used with coherent buffers. So, all allocated buffers should be freed with usb_free_coherent() explicitly. Side note: This code looks like a copy-paste of other can drivers. The same patch was applied to mcba_usb driver and it works nice with real hardware. There is no change in functionality, only clean-up code for coherent buffers. Fixes: 0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices") Link: https://lore.kernel.org/r/d39b458cd425a1cf7f512f340224e6e9563b07bd.1627404470.git.paskripkin@gmail.com Cc: linux-stable Signed-off-by: Pavel Skripkin Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit a6ebfbdaca3da6ba66c68fbe6636217bcb98b06a Author: Pavel Skripkin Date: Sun Jul 25 13:36:30 2021 +0300 can: mcba_usb_start(): add missing urb->transfer_dma initialization commit fc43fb69a7af92839551f99c1a96a37b77b3ae7a upstream. Yasushi reported, that his Microchip CAN Analyzer stopped working since commit 91c02557174b ("can: mcba_usb: fix memory leak in mcba_usb"). The problem was in missing urb->transfer_dma initialization. In my previous patch to this driver I refactored mcba_usb_start() code to avoid leaking usb coherent buffers. To archive it, I passed local stack variable to usb_alloc_coherent() and then saved it to private array to correctly free all coherent buffers on ->close() call. But I forgot to initialize urb->transfer_dma with variable passed to usb_alloc_coherent(). All of this was causing device to not work, since dma addr 0 is not valid and following log can be found on bug report page, which points exactly to problem described above. | DMAR: [DMA Write] Request device [00:14.0] PASID ffffffff fault addr 0 [fault reason 05] PTE Write access is not set Fixes: 91c02557174b ("can: mcba_usb: fix memory leak in mcba_usb") Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990850 Link: https://lore.kernel.org/r/20210725103630.23864-1-paskripkin@gmail.com Cc: linux-stable Reported-by: Yasushi SHOJI Signed-off-by: Pavel Skripkin Tested-by: Yasushi SHOJI [mkl: fixed typos in commit message - thanks Yasushi SHOJI] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 2fc2c2816cb76fd39bf446f12a72e3bd20b52018 Author: Stephane Grosjean Date: Fri Jun 25 15:09:29 2021 +0200 can: peak_usb: pcan_usb_handle_bus_evt(): fix reading rxerr/txerr values commit 590eb2b7d8cfafb27e8108d52d4bf4850626d31d upstream. This patch fixes an incorrect way of reading error counters in messages received for this purpose from the PCAN-USB interface. These messages inform about the increase or decrease of the error counters, whose values are placed in bytes 1 and 2 of the message data (not 0 and 1). Fixes: ea8b33bde76c ("can: pcan_usb: add support of rxerr/txerr counters") Link: https://lore.kernel.org/r/20210625130931.27438-4-s.grosjean@peak-system.com Cc: linux-stable Signed-off-by: Stephane Grosjean Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit afe2ffd920615fb50d2f6d94588110b0cdcf5470 Author: Ziyang Xuan Date: Thu Jul 22 15:08:19 2021 +0800 can: raw: raw_setsockopt(): fix raw_rcv panic for sock UAF commit 54f93336d000229f72c26d8a3f69dd256b744528 upstream. We get a bug during ltp can_filter test as following. =========================================== [60919.264984] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [60919.265223] PGD 8000003dda726067 P4D 8000003dda726067 PUD 3dda727067 PMD 0 [60919.265443] Oops: 0000 [#1] SMP PTI [60919.265550] CPU: 30 PID: 3638365 Comm: can_filter Kdump: loaded Tainted: G W 4.19.90+ #1 [60919.266068] RIP: 0010:selinux_socket_sock_rcv_skb+0x3e/0x200 [60919.293289] RSP: 0018:ffff8d53bfc03cf8 EFLAGS: 00010246 [60919.307140] RAX: 0000000000000000 RBX: 000000000000001d RCX: 0000000000000007 [60919.320756] RDX: 0000000000000001 RSI: ffff8d5104a8ed00 RDI: ffff8d53bfc03d30 [60919.334319] RBP: ffff8d9338056800 R08: ffff8d53bfc29d80 R09: 0000000000000001 [60919.347969] R10: ffff8d53bfc03ec0 R11: ffffb8526ef47c98 R12: ffff8d53bfc03d30 [60919.350320] perf: interrupt took too long (3063 > 2500), lowering kernel.perf_event_max_sample_rate to 65000 [60919.361148] R13: 0000000000000001 R14: ffff8d53bcf90000 R15: 0000000000000000 [60919.361151] FS: 00007fb78b6b3600(0000) GS:ffff8d53bfc00000(0000) knlGS:0000000000000000 [60919.400812] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [60919.413730] CR2: 0000000000000010 CR3: 0000003e3f784006 CR4: 00000000007606e0 [60919.426479] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [60919.439339] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [60919.451608] PKRU: 55555554 [60919.463622] Call Trace: [60919.475617] [60919.487122] ? update_load_avg+0x89/0x5d0 [60919.498478] ? update_load_avg+0x89/0x5d0 [60919.509822] ? account_entity_enqueue+0xc5/0xf0 [60919.520709] security_sock_rcv_skb+0x2a/0x40 [60919.531413] sk_filter_trim_cap+0x47/0x1b0 [60919.542178] ? kmem_cache_alloc+0x38/0x1b0 [60919.552444] sock_queue_rcv_skb+0x17/0x30 [60919.562477] raw_rcv+0x110/0x190 [can_raw] [60919.572539] can_rcv_filter+0xbc/0x1b0 [can] [60919.582173] can_receive+0x6b/0xb0 [can] [60919.591595] can_rcv+0x31/0x70 [can] [60919.600783] __netif_receive_skb_one_core+0x5a/0x80 [60919.609864] process_backlog+0x9b/0x150 [60919.618691] net_rx_action+0x156/0x400 [60919.627310] ? sched_clock_cpu+0xc/0xa0 [60919.635714] __do_softirq+0xe8/0x2e9 [60919.644161] do_softirq_own_stack+0x2a/0x40 [60919.652154] [60919.659899] do_softirq.part.17+0x4f/0x60 [60919.667475] __local_bh_enable_ip+0x60/0x70 [60919.675089] __dev_queue_xmit+0x539/0x920 [60919.682267] ? finish_wait+0x80/0x80 [60919.689218] ? finish_wait+0x80/0x80 [60919.695886] ? sock_alloc_send_pskb+0x211/0x230 [60919.702395] ? can_send+0xe5/0x1f0 [can] [60919.708882] can_send+0xe5/0x1f0 [can] [60919.715037] raw_sendmsg+0x16d/0x268 [can_raw] It's because raw_setsockopt() concurrently with unregister_netdevice_many(). Concurrent scenario as following. cpu0 cpu1 raw_bind raw_setsockopt unregister_netdevice_many unlist_netdevice dev_get_by_index raw_notifier raw_enable_filters ...... can_rx_register can_rcv_list_find(..., net->can.rx_alldev_list) ...... sock_close raw_release(sock_a) ...... can_receive can_rcv_filter(net->can.rx_alldev_list, ...) raw_rcv(skb, sock_a) BUG After unlist_netdevice(), dev_get_by_index() return NULL in raw_setsockopt(). Function raw_enable_filters() will add sock and can_filter to net->can.rx_alldev_list. Then the sock is closed. Followed by, we sock_sendmsg() to a new vcan device use the same can_filter. Protocol stack match the old receiver whose sock has been released on net->can.rx_alldev_list in can_rcv_filter(). Function raw_rcv() uses the freed sock. UAF BUG is triggered. We can find that the key issue is that net_device has not been protected in raw_setsockopt(). Use rtnl_lock to protect net_device in raw_setsockopt(). Fixes: c18ce101f2e4 ("[CAN]: Add raw protocol") Link: https://lore.kernel.org/r/20210722070819.1048263-1-william.xuanziyang@huawei.com Cc: linux-stable Signed-off-by: Ziyang Xuan Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit a9c02d0e1513df9b6124599ed2c05695d1d7ff0c Author: Zhang Changzhong Date: Tue Jul 6 19:00:08 2021 +0800 can: j1939: j1939_xtp_rx_dat_one(): fix rxtimer value between consecutive TP.DT to 750ms commit c6eea1c8bda56737752465a298dc6ce07d6b8ce3 upstream. For receive side, the max time interval between two consecutive TP.DT should be 750ms. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/r/1625569210-47506-1-git-send-email-zhangchangzhong@huawei.com Cc: linux-stable Signed-off-by: Zhang Changzhong Acked-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit da4f4916dab2b55cd38eec2f9a33800a7abc6bb9 Author: Junxiao Bi Date: Thu Jul 29 14:53:41 2021 -0700 ocfs2: issue zeroout to EOF blocks commit 9449ad33be8480f538b11a593e2dda2fb33ca06d upstream. For punch holes in EOF blocks, fallocate used buffer write to zero the EOF blocks in last cluster. But since ->writepage will ignore EOF pages, those zeros will not be flushed. This "looks" ok as commit 6bba4471f0cc ("ocfs2: fix data corruption by fallocate") will zero the EOF blocks when extend the file size, but it isn't. The problem happened on those EOF pages, before writeback, those pages had DIRTY flag set and all buffer_head in them also had DIRTY flag set, when writeback run by write_cache_pages(), DIRTY flag on the page was cleared, but DIRTY flag on the buffer_head not. When next write happened to those EOF pages, since buffer_head already had DIRTY flag set, it would not mark page DIRTY again. That made writeback ignore them forever. That will cause data corruption. Even directio write can't work because it will fail when trying to drop pages caches before direct io, as it found the buffer_head for those pages still had DIRTY flag set, then it will fall back to buffer io mode. To make a summary of the issue, as writeback ingores EOF pages, once any EOF page is generated, any write to it will only go to the page cache, it will never be flushed to disk even file size extends and that page is not EOF page any more. The fix is to avoid zero EOF blocks with buffer write. The following code snippet from qemu-img could trigger the corruption. 656 open("6b3711ae-3306-4bdd-823c-cf1c0060a095.conv.2", O_RDWR|O_DIRECT|O_CLOEXEC) = 11 ... 660 fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2275868672, 327680 660 fallocate(11, 0, 2275868672, 327680) = 0 658 pwrite64(11, " Link: https://lkml.kernel.org/r/20210722054923.24389-2-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 94301459306115e007966bd607638232423d15d9 Author: Junxiao Bi Date: Thu Jul 29 14:53:38 2021 -0700 ocfs2: fix zero out valid data commit f267aeb6dea5e468793e5b8eb6a9c72c0020d418 upstream. If append-dio feature is enabled, direct-io write and fallocate could run in parallel to extend file size, fallocate used "orig_isize" to record i_size before taking "ip_alloc_sem", when ocfs2_zeroout_partial_cluster() zeroout EOF blocks, i_size maybe already extended by ocfs2_dio_end_io_write(), that will cause valid data zeroed out. Link: https://lkml.kernel.org/r/20210722054923.24389-1-junxiao.bi@oracle.com Fixes: 6bba4471f0cc ("ocfs2: fix data corruption by fallocate") Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Gang He Cc: Joel Becker Cc: Jun Piao Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 52acb6c147b30aef1e178249620c81b41da4ae8b Author: Paolo Bonzini Date: Tue Jul 27 08:43:10 2021 -0400 KVM: add missing compat KVM_CLEAR_DIRTY_LOG commit 8750f9bbda115f3f79bfe43be85551ee5e12b6ff upstream. The arguments to the KVM_CLEAR_DIRTY_LOG ioctl include a pointer, therefore it needs a compat ioctl implementation. Otherwise, 32-bit userspace fails to invoke it on 64-bit kernels; for x86 it might work fine by chance if the padding is zero, but not on big-endian architectures. Reported-by: Thomas Sattler Cc: stable@vger.kernel.org Fixes: 2a31b9db1535 ("kvm: introduce manual dirty log reprotect") Reviewed-by: Peter Xu Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 7d67d4ab28e3c7daa6151d64e1be8da478b77f3d Author: Juergen Gross Date: Thu Jul 1 17:41:00 2021 +0200 x86/kvm: fix vcpu-id indexed array sizes commit 76b4f357d0e7d8f6f0013c733e6cba1773c266d3 upstream. KVM_MAX_VCPU_ID is the maximum vcpu-id of a guest, and not the number of vcpu-ids. Fix array indexed by vcpu-id to have KVM_MAX_VCPU_ID+1 elements. Note that this is currently no real problem, as KVM_MAX_VCPU_ID is an odd number, resulting in always enough padding being available at the end of those arrays. Nevertheless this should be fixed in order to avoid rare problems in case someone is using an even number for KVM_MAX_VCPU_ID. Signed-off-by: Juergen Gross Message-Id: <20210701154105.23215-2-jgross@suse.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 2388c7674fbdb9d8944caee768e599b02a21b33e Author: Srinivas Pandruvada Date: Tue Jul 27 09:18:24 2021 -0700 ACPI: DPTF: Fix reading of attributes commit 41a8457f3f6f829be1f8f8fa7577a46b9b7223ef upstream. The current assumption that methods to read PCH FIVR attributes will return integer, is not correct. There is no good way to return integer as negative numbers are also valid. These read methods return a package of integers. The first integer returns status, which is 0 on success and any other value for failure. When the returned status is zero, then the second integer returns the actual value. This change fixes this issue by replacing acpi_evaluate_integer() with acpi_evaluate_object() and use acpi_extract_package() to extract results. Fixes: 2ce6324eadb01 ("ACPI: DPTF: Add PCH FIVR participant driver") Signed-off-by: Srinivas Pandruvada Cc: 5.10+ # 5.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 0d6afa25975e73fef3537678e98386020661eed0 Author: Hui Wang Date: Wed Jul 28 23:19:58 2021 +0800 Revert "ACPI: resources: Add checks for ACPI IRQ override" commit e0eef3690dc66b3ecc6e0f1267f332403eb22bea upstream. The commit 0ec4e55e9f57 ("ACPI: resources: Add checks for ACPI IRQ override") introduces regression on some platforms, at least it makes the UART can't get correct irq setting on two different platforms, and it makes the kernel can't bootup on these two platforms. This reverts commit 0ec4e55e9f571f08970ed115ec0addc691eda613. Regression-discuss: https://bugzilla.kernel.org/show_bug.cgi?id=213031 Reported-by: PGNd Cc: 5.4+ # 5.4+ Signed-off-by: Hui Wang Acked-by: Greg Kroah-Hartman Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 0a421a2fc516f39caf3d253c04b76a12fe632011 Author: Goldwyn Rodrigues Date: Fri Jul 9 11:29:22 2021 -0500 btrfs: mark compressed range uptodate only if all bio succeed commit 240246f6b913b0c23733cfd2def1d283f8cc9bbe upstream. In compression write endio sequence, the range which the compressed_bio writes is marked as uptodate if the last bio of the compressed (sub)bios is completed successfully. There could be previous bio which may have failed which is recorded in cb->errors. Set the writeback range as uptodate only if cb->errors is zero, as opposed to checking only the last bio's status. Backporting notes: in all versions up to 4.4 the last argument is always replaced by "!cb->errors". CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Goldwyn Rodrigues Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 4e1a57d75264dd4f10f3497c35dda521947368df Author: Desmond Cheong Zhi Xi Date: Tue Jul 27 15:13:03 2021 +0800 btrfs: fix rw device counting in __btrfs_free_extra_devids commit b2a616676839e2a6b02c8e40be7f886f882ed194 upstream. When removing a writeable device in __btrfs_free_extra_devids, the rw device count should be decremented. This error was caught by Syzbot which reported a warning in close_fs_devices: WARNING: CPU: 1 PID: 9355 at fs/btrfs/volumes.c:1168 close_fs_devices+0x763/0x880 fs/btrfs/volumes.c:1168 Modules linked in: CPU: 0 PID: 9355 Comm: syz-executor552 Not tainted 5.13.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:close_fs_devices+0x763/0x880 fs/btrfs/volumes.c:1168 RSP: 0018:ffffc9000333f2f0 EFLAGS: 00010293 RAX: ffffffff8365f5c3 RBX: 0000000000000001 RCX: ffff888029afd4c0 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff88802846f508 R08: ffffffff8365f525 R09: ffffed100337d128 R10: ffffed100337d128 R11: 0000000000000000 R12: dffffc0000000000 R13: ffff888019be8868 R14: 1ffff1100337d10d R15: 1ffff1100337d10a FS: 00007f6f53828700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000047c410 CR3: 00000000302a6000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: btrfs_close_devices+0xc9/0x450 fs/btrfs/volumes.c:1180 open_ctree+0x8e1/0x3968 fs/btrfs/disk-io.c:3693 btrfs_fill_super fs/btrfs/super.c:1382 [inline] btrfs_mount_root+0xac5/0xc60 fs/btrfs/super.c:1749 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1498 fc_mount fs/namespace.c:993 [inline] vfs_kern_mount+0xc9/0x160 fs/namespace.c:1023 btrfs_mount+0x3d3/0xb50 fs/btrfs/super.c:1809 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1498 do_new_mount fs/namespace.c:2905 [inline] path_mount+0x196f/0x2be0 fs/namespace.c:3235 do_mount fs/namespace.c:3248 [inline] __do_sys_mount fs/namespace.c:3456 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae Because fs_devices->rw_devices was not 0 after closing all devices. Here is the call trace that was observed: btrfs_mount_root(): btrfs_scan_one_device(): device_list_add(); <---------------- device added btrfs_open_devices(): open_fs_devices(): btrfs_open_one_device(); <-------- writable device opened, rw device count ++ btrfs_fill_super(): open_ctree(): btrfs_free_extra_devids(): __btrfs_free_extra_devids(); <--- writable device removed, rw device count not decremented fail_tree_roots: btrfs_close_devices(): close_fs_devices(); <------- rw device count off by 1 As a note, prior to commit cf89af146b7e ("btrfs: dev-replace: fail mount if we don't have replace item with target device"), rw_devices was decremented on removing a writable device in __btrfs_free_extra_devids only if the BTRFS_DEV_STATE_REPLACE_TGT bit was not set for the device. However, this check does not need to be reinstated as it is now redundant and incorrect. In __btrfs_free_extra_devids, we skip removing the device if it is the target for replacement. This is done by checking whether device->devid == BTRFS_DEV_REPLACE_DEVID. Since BTRFS_DEV_STATE_REPLACE_TGT is set only on the device with devid BTRFS_DEV_REPLACE_DEVID, no devices should have the BTRFS_DEV_STATE_REPLACE_TGT bit set after the check, and so it's redundant to test for that bit. Additionally, following commit 82372bc816d7 ("Btrfs: make the logic of source device removing more clear"), rw_devices is incremented whenever a writeable device is added to the alloc list (including the target device in btrfs_dev_replace_finishing), so all removals of writable devices from the alloc list should also be accompanied by a decrement to rw_devices. Reported-by: syzbot+a70e2ad0879f160b9217@syzkaller.appspotmail.com Fixes: cf89af146b7e ("btrfs: dev-replace: fail mount if we don't have replace item with target device") CC: stable@vger.kernel.org # 5.10+ Tested-by: syzbot+a70e2ad0879f160b9217@syzkaller.appspotmail.com Reviewed-by: Anand Jain Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 27aa7171fe2b00c3de01e8e3a3298a3639f37fa3 Author: Linus Torvalds Date: Fri Jul 30 15:42:34 2021 -0700 pipe: make pipe writes always wake up readers commit 3a34b13a88caeb2800ab44a4918f230041b37dd9 upstream. Since commit 1b6b26ae7053 ("pipe: fix and clarify pipe write wakeup logic") we have sanitized the pipe write logic, and would only try to wake up readers if they needed it. In particular, if the pipe already had data in it before the write, there was no point in trying to wake up a reader, since any existing readers must have been aware of the pre-existing data already. Doing extraneous wakeups will only cause potential thundering herd problems. However, it turns out that some Android libraries have misused the EPOLL interface, and expected "edge triggered" be to "any new write will trigger it". Even if there was no edge in sight. Quoting Sandeep Patil: "The commit 1b6b26ae7053 ('pipe: fix and clarify pipe write wakeup logic') changed pipe write logic to wakeup readers only if the pipe was empty at the time of write. However, there are libraries that relied upon the older behavior for notification scheme similar to what's described in [1] One such library 'realm-core'[2] is used by numerous Android applications. The library uses a similar notification mechanism as GNU Make but it never drains the pipe until it is full. When Android moved to v5.10 kernel, all applications using this library stopped working. The library has since been fixed[3] but it will be a while before all applications incorporate the updated library" Our regression rule for the kernel is that if applications break from new behavior, it's a regression, even if it was because the application did something patently wrong. Also note the original report [4] by Michal Kerrisk about a test for this epoll behavior - but at that point we didn't know of any actual broken use case. So add the extraneous wakeup, to approximate the old behavior. [ I say "approximate", because the exact old behavior was to do a wakeup not for each write(), but for each pipe buffer chunk that was filled in. The behavior introduced by this change is not that - this is just "every write will cause a wakeup, whether necessary or not", which seems to be sufficient for the broken library use. ] It's worth noting that this adds the extraneous wakeup only for the write side, while the read side still considers the "edge" to be purely about reading enough from the pipe to allow further writes. See commit f467a6a66419 ("pipe: fix and clarify pipe read wakeup logic") for the pipe read case, which remains that "only wake up if the pipe was full, and we read something from it". Link: https://lore.kernel.org/lkml/CAHk-=wjeG0q1vgzu4iJhW5juPkTsjTYmiqiMUYAebWW+0bam6w@mail.gmail.com/ [1] Link: https://github.com/realm/realm-core [2] Link: https://github.com/realm/realm-core/issues/4666 [3] Link: https://lore.kernel.org/lkml/CAKgNAkjMBGeAwF=2MKK758BhxvW58wYTgYKB2V-gY1PwXxrH+Q@mail.gmail.com/ [4] Link: https://lore.kernel.org/lkml/20210729222635.2937453-1-sspatil@android.com/ Reported-by: Sandeep Patil Cc: Michael Kerrisk Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 02210a5e1894d5da89fbc67f44a182b7739fbaa3 Author: Jan Kiszka Date: Sun Apr 11 10:12:16 2021 +0200 x86/asm: Ensure asm/proto.h can be included stand-alone [ Upstream commit f7b21a0e41171d22296b897dac6e4c41d2a3643c ] Fix: ../arch/x86/include/asm/proto.h:14:30: warning: ‘struct task_struct’ declared \ inside parameter list will not be visible outside of this definition or declaration long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2); ^~~~~~~~~~~ .../arch/x86/include/asm/proto.h:40:34: warning: ‘struct task_struct’ declared \ inside parameter list will not be visible outside of this definition or declaration long do_arch_prctl_common(struct task_struct *task, int option, ^~~~~~~~~~~ if linux/sched.h hasn't be included previously. This fixes a build error when this header is used outside of the kernel tree. [ bp: Massage commit message. ] Signed-off-by: Jan Kiszka Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/b76b4be3-cf66-f6b2-9a6c-3e7ef54f9845@web.de Signed-off-by: Sasha Levin commit 65b2658634fedc0a34fb04832a702834e77791e5 Author: Yang Yingliang Date: Thu Jul 29 22:23:38 2021 +0800 io_uring: fix null-ptr-deref in io_sq_offload_start() I met a null-ptr-deref when doing fault-inject test: [ 65.441626][ T8299] general protection fault, probably for non-canonical address 0xdffffc0000000029: 0000 [#1] PREEMPT SMP KASAN [ 65.443219][ T8299] KASAN: null-ptr-deref in range [0x0000000000000148-0x000000000000014f] [ 65.444331][ T8299] CPU: 2 PID: 8299 Comm: test Not tainted 5.10.49+ #499 [ 65.445277][ T8299] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 65.446614][ T8299] RIP: 0010:io_disable_sqo_submit+0x124/0x260 [ 65.447554][ T8299] Code: 7b 40 89 ee e8 2d b9 9a ff 85 ed 74 40 e8 04 b8 9a ff 49 8d be 48 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 22 01 00 00 49 8b ae 48 01 00 00 48 85 ed 74 0d [ 65.450860][ T8299] RSP: 0018:ffffc9000122fd70 EFLAGS: 00010202 [ 65.451826][ T8299] RAX: dffffc0000000000 RBX: ffff88801b11f000 RCX: ffffffff81d5d783 [ 65.453166][ T8299] RDX: 0000000000000029 RSI: ffffffff81d5d78c RDI: 0000000000000148 [ 65.454606][ T8299] RBP: 0000000000000002 R08: ffff88810168c280 R09: ffffed1003623e79 [ 65.456063][ T8299] R10: ffffc9000122fd70 R11: ffffed1003623e78 R12: ffff88801b11f040 [ 65.457542][ T8299] R13: ffff88801b11f3c0 R14: 0000000000000000 R15: 000000000000001a [ 65.458910][ T8299] FS: 00007ffb602e3500(0000) GS:ffff888064100000(0000) knlGS:0000000000000000 [ 65.460533][ T8299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 65.461736][ T8299] CR2: 00007ffb5fe7eb24 CR3: 000000010a619000 CR4: 0000000000750ee0 [ 65.463146][ T8299] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 65.464618][ T8299] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 65.466052][ T8299] PKRU: 55555554 [ 65.466708][ T8299] Call Trace: [ 65.467304][ T8299] io_uring_setup+0x2041/0x3ac0 [ 65.468169][ T8299] ? io_iopoll_check+0x500/0x500 [ 65.469123][ T8299] ? syscall_enter_from_user_mode+0x1c/0x50 [ 65.470241][ T8299] do_syscall_64+0x2d/0x70 [ 65.471028][ T8299] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 65.472099][ T8299] RIP: 0033:0x7ffb5fdec839 [ 65.472925][ T8299] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 [ 65.476465][ T8299] RSP: 002b:00007ffc33539ef8 EFLAGS: 00000206 ORIG_RAX: 00000000000001a9 [ 65.478026][ T8299] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffb5fdec839 [ 65.479503][ T8299] RDX: 0000000020ffd000 RSI: 0000000020000080 RDI: 0000000000100001 [ 65.480927][ T8299] RBP: 00007ffc33539f70 R08: 0000000000000000 R09: 0000000000000000 [ 65.482416][ T8299] R10: 0000000000000000 R11: 0000000000000206 R12: 0000555e85531320 [ 65.483845][ T8299] R13: 00007ffc3353a0a0 R14: 0000000000000000 R15: 0000000000000000 [ 65.485331][ T8299] Modules linked in: [ 65.486000][ T8299] Dumping ftrace buffer: [ 65.486772][ T8299] (ftrace buffer empty) [ 65.487595][ T8299] ---[ end trace a9a5fad3ebb303b7 ]--- If io_allocate_scq_urings() fails in io_uring_create(), 'ctx->sq_data' is not set yet, when calling io_sq_offload_start() in io_disable_sqo_submit() in error path, it will lead a null-ptr-deref. The io_disable_sqo_submit() has been removed in mainline by commit 70aacfe66136 ("io_uring: kill sqo_dead and sqo submission halting"), so the bug has been eliminated in mainline, it's a fix only for stable-5.10. Signed-off-by: Yang Yingliang Cc: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e44d22fdf75613503b31a38fa824a98c970ea119 Author: Greg Kroah-Hartman Date: Wed Jul 28 13:51:58 2021 +0200 selftest: fix build error in tools/testing/selftests/vm/userfaultfd.c When backporting 0db282ba2c12 ("selftest: use mmap instead of posix_memalign to allocate memory") to this stable branch, I forgot a { breaking the build. Signed-off-by: Greg Kroah-Hartman commit 11fe69a17195cf58eff523f26f90de50660d0100 Author: Greg Kroah-Hartman Date: Sat Jul 31 08:16:13 2021 +0200 Linux 5.10.55 Link: https://lore.kernel.org/r/20210729135137.267680390@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 984e93b8e20731f83e453dd056f8a3931b4a66e5 Author: Vasily Averin Date: Mon Jul 19 10:55:14 2021 +0300 ipv6: ip6_finish_output2: set sk into newly allocated nskb [ Upstream commit 2d85a1b31dde84038ea07ad825c3d8d3e71f4344 ] skb_set_owner_w() should set sk not to old skb but to new nskb. Fixes: 5796015fa968 ("ipv6: allocate enough headroom in ip6_finish_output2()") Signed-off-by: Vasily Averin Link: https://lore.kernel.org/r/70c0744f-89ae-1869-7e3e-4fa292158f4b@virtuozzo.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a74054ca75533dd9a0747b6c308daf27a6433ab4 Author: Sudeep Holla Date: Thu Jul 1 14:21:18 2021 +0100 ARM: dts: versatile: Fix up interrupt controller node names [ Upstream commit 82a1c67554dff610d6be4e1982c425717b3c6a23 ] Once the new schema interrupt-controller/arm,vic.yaml is added, we get the below warnings: arch/arm/boot/dts/versatile-ab.dt.yaml: intc@10140000: $nodename:0: 'intc@10140000' does not match '^interrupt-controller(@[0-9a-f,]+)*$' arch/arm/boot/dts/versatile-ab.dt.yaml: intc@10140000: 'clear-mask' does not match any of the regexes Fix the node names for the interrupt controller to conform to the standard node name interrupt-controller@.. Also drop invalid clear-mask property. Signed-off-by: Sudeep Holla Acked-by: Linus Walleij Link: https://lore.kernel.org/r/20210701132118.759454-1-sudeep.holla@arm.com' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 3510b9b41c70e2d51a05e2c6f558b522de8ab646 Author: Christoph Hellwig Date: Thu Jul 15 09:58:04 2021 -0700 iomap: remove the length variable in iomap_seek_hole [ Upstream commit 49694d14ff68fa4b5f86019dbcfb44a8bd213e58 ] The length variable is rather pointless given that it can be trivially deduced from offset and size. Also the initial calculation can lead to KASAN warnings. Signed-off-by: Christoph Hellwig Reported-by: Leizhen (ThunderTown) Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit 8659186e72d0770720d052d39e4bee4a47366fd3 Author: Christoph Hellwig Date: Thu Jul 15 09:58:04 2021 -0700 iomap: remove the length variable in iomap_seek_data [ Upstream commit 3ac1d426510f97ace05093ae9f2f710d9cbe6215 ] The length variable is rather pointless given that it can be trivially deduced from offset and size. Also the initial calculation can lead to KASAN warnings. Signed-off-by: Christoph Hellwig Reported-by: Leizhen (ThunderTown) Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit 65039407489c3baddbd883acc243867c2c28f9c3 Author: Hyunchul Lee Date: Mon Jul 12 19:34:02 2021 +0900 cifs: fix the out of range assignment to bit fields in parse_server_interfaces [ Upstream commit c9c9c6815f9004ee1ec87401ed0796853bd70f1b ] Because the out of range assignment to bit fields are compiler-dependant, the fields could have wrong value. Signed-off-by: Hyunchul Lee Signed-off-by: Steve French Signed-off-by: Sasha Levin commit fe5fe0b1c8b91877c3b35482fc08c35cc9586842 Author: Cristian Marussi Date: Mon Jul 12 15:18:18 2021 +0100 firmware: arm_scmi: Fix range check for the maximum number of pending messages [ Upstream commit bdb8742dc6f7c599c3d61959234fe4c23638727b ] SCMI message headers carry a sequence number and such field is sized to allow for MSG_TOKEN_MAX distinct numbers; moreover zero is not really an acceptable maximum number of pending in-flight messages. Fix accordingly the checks performed on the value exported by transports in scmi_desc.max_msg Link: https://lore.kernel.org/r/20210712141833.6628-3-cristian.marussi@arm.com Reported-by: Vincent Guittot Signed-off-by: Cristian Marussi [sudeep.holla: updated the patch title and error message] Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 8f8e5475a369d5424b2cac061b47ee08ef285db0 Author: Sudeep Holla Date: Wed Jul 7 14:50:28 2021 +0100 firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflow [ Upstream commit 7a691f16ccad05d770f813d9c4b4337a30c6d63f ] The scmi_linux_errmap buffer access index is supposed to depend on the array size to prevent element out of bounds access. It uses SCMI_ERR_MAX to check bounds but that can mismatch with the array size. It also changes the success into -EIO though scmi_linux_errmap is never used in case of success, it is expected to work for success case too. It is slightly confusing code as the negative of the error code is used as index to the buffer. Fix it by negating it at the start and make it more readable. Link: https://lore.kernel.org/r/20210707135028.1869642-1-sudeep.holla@arm.com Reported-by: kernel test robot Reported-by: Dan Carpenter Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit d01328fef6afffd1bdce6e8ead707b6f5a5de7a7 Author: Desmond Cheong Zhi Xi Date: Wed Jul 14 21:27:08 2021 -0700 hfs: add lock nesting notation to hfs_find_init [ Upstream commit b3b2177a2d795e35dc11597b2609eb1e7e57e570 ] Syzbot reports a possible recursive lock in [1]. This happens due to missing lock nesting information. From the logs, we see that a call to hfs_fill_super is made to mount the hfs filesystem. While searching for the root inode, the lock on the catalog btree is grabbed. Then, when the parent of the root isn't found, a call to __hfs_bnode_create is made to create the parent of the root. This eventually leads to a call to hfs_ext_read_extent which grabs a lock on the extents btree. Since the order of locking is catalog btree -> extents btree, this lock hierarchy does not lead to a deadlock. To tell lockdep that this locking is safe, we add nesting notation to distinguish between catalog btrees, extents btrees, and attributes btrees (for HFS+). This has already been done in hfsplus. Link: https://syzkaller.appspot.com/bug?id=f007ef1d7a31a469e3be7aeb0fde0769b18585db [1] Link: https://lkml.kernel.org/r/20210701030756.58760-4-desmondcheongzx@gmail.com Signed-off-by: Desmond Cheong Zhi Xi Reported-by: syzbot+b718ec84a87b7e73ade4@syzkaller.appspotmail.com Tested-by: syzbot+b718ec84a87b7e73ade4@syzkaller.appspotmail.com Reviewed-by: Viacheslav Dubeyko Cc: Al Viro Cc: Greg Kroah-Hartman Cc: Gustavo A. R. Silva Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 06b3d9923fa05f300c1d92a9259c01f7de72e670 Author: Desmond Cheong Zhi Xi Date: Wed Jul 14 21:27:05 2021 -0700 hfs: fix high memory mapping in hfs_bnode_read [ Upstream commit 54a5ead6f5e2b47131a7385d0c0af18e7b89cb02 ] Pages that we read in hfs_bnode_read need to be kmapped into kernel address space. However, currently only the 0th page is kmapped. If the given offset + length exceeds this 0th page, then we have an invalid memory access. To fix this, we kmap relevant pages one by one and copy their relevant portions of data. An example of invalid memory access occurring without this fix can be seen in the following crash report: ================================================================== BUG: KASAN: use-after-free in memcpy include/linux/fortify-string.h:191 [inline] BUG: KASAN: use-after-free in hfs_bnode_read+0xc4/0xe0 fs/hfs/bnode.c:26 Read of size 2 at addr ffff888125fdcffe by task syz-executor5/4634 CPU: 0 PID: 4634 Comm: syz-executor5 Not tainted 5.13.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x195/0x1f8 lib/dump_stack.c:120 print_address_description.constprop.0+0x1d/0x110 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report.cold+0x7b/0xd4 mm/kasan/report.c:436 check_region_inline mm/kasan/generic.c:180 [inline] kasan_check_range+0x154/0x1b0 mm/kasan/generic.c:186 memcpy+0x24/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [inline] hfs_bnode_read+0xc4/0xe0 fs/hfs/bnode.c:26 hfs_bnode_read_u16 fs/hfs/bnode.c:34 [inline] hfs_bnode_find+0x880/0xcc0 fs/hfs/bnode.c:365 hfs_brec_find+0x2d8/0x540 fs/hfs/bfind.c:126 hfs_brec_read+0x27/0x120 fs/hfs/bfind.c:165 hfs_cat_find_brec+0x19a/0x3b0 fs/hfs/catalog.c:194 hfs_fill_super+0xc13/0x1460 fs/hfs/super.c:419 mount_bdev+0x331/0x3f0 fs/super.c:1368 hfs_mount+0x35/0x40 fs/hfs/super.c:457 legacy_get_tree+0x10c/0x220 fs/fs_context.c:592 vfs_get_tree+0x93/0x300 fs/super.c:1498 do_new_mount fs/namespace.c:2905 [inline] path_mount+0x13f5/0x20e0 fs/namespace.c:3235 do_mount fs/namespace.c:3248 [inline] __do_sys_mount fs/namespace.c:3456 [inline] __se_sys_mount fs/namespace.c:3433 [inline] __x64_sys_mount+0x2b8/0x340 fs/namespace.c:3433 do_syscall_64+0x37/0xc0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x45e63a Code: 48 c7 c2 bc ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 88 04 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9404d410d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000020000248 RCX: 000000000045e63a RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007f9404d41120 RBP: 00007f9404d41120 R08: 00000000200002c0 R09: 0000000020000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003 R13: 0000000000000003 R14: 00000000004ad5d8 R15: 0000000000000000 The buggy address belongs to the page: page:00000000dadbcf3e refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x125fdc flags: 0x2fffc0000000000(node=0|zone=2|lastcpupid=0x3fff) raw: 02fffc0000000000 ffffea000497f748 ffffea000497f6c8 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888125fdce80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888125fdcf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888125fdcf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888125fdd000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888125fdd080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Link: https://lkml.kernel.org/r/20210701030756.58760-3-desmondcheongzx@gmail.com Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: Viacheslav Dubeyko Cc: Al Viro Cc: Greg Kroah-Hartman Cc: Gustavo A. R. Silva Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 680b2917e60ed0cf80d7d4479004844f9cddda81 Author: Desmond Cheong Zhi Xi Date: Wed Jul 14 21:27:01 2021 -0700 hfs: add missing clean-up in hfs_fill_super [ Upstream commit 16ee572eaf0d09daa4c8a755fdb71e40dbf8562d ] Patch series "hfs: fix various errors", v2. This series ultimately aims to address a lockdep warning in hfs_find_init reported by Syzbot [1]. The work done for this led to the discovery of another bug, and the Syzkaller repro test also reveals an invalid memory access error after clearing the lockdep warning. Hence, this series is broken up into three patches: 1. Add a missing call to hfs_find_exit for an error path in hfs_fill_super 2. Fix memory mapping in hfs_bnode_read by fixing calls to kmap 3. Add lock nesting notation to tell lockdep that the observed locking hierarchy is safe This patch (of 3): Before exiting hfs_fill_super, the struct hfs_find_data used in hfs_find_init should be passed to hfs_find_exit to be cleaned up, and to release the lock held on the btree. The call to hfs_find_exit is missing from an error path. We add it back in by consolidating calls to hfs_find_exit for error paths. Link: https://syzkaller.appspot.com/bug?id=f007ef1d7a31a469e3be7aeb0fde0769b18585db [1] Link: https://lkml.kernel.org/r/20210701030756.58760-1-desmondcheongzx@gmail.com Link: https://lkml.kernel.org/r/20210701030756.58760-2-desmondcheongzx@gmail.com Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: Viacheslav Dubeyko Cc: Gustavo A. R. Silva Cc: Al Viro Cc: Shuah Khan Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5c3d753b872a706af9317fef4edfb6b640d8a71e Author: Zheyu Ma Date: Wed Jul 14 14:54:19 2021 +0000 drm/ttm: add a check against null pointer dereference [ Upstream commit 9e5c772954406829e928dbe59891d08938ead04b ] When calling ttm_range_man_fini(), 'man' may be uninitialized, which may cause a null pointer dereference bug. Fix this by checking if it is a null pointer. This log reveals it: [ 7.902580 ] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 7.905721 ] RIP: 0010:ttm_range_man_fini+0x40/0x160 [ 7.911826 ] Call Trace: [ 7.911826 ] radeon_ttm_fini+0x167/0x210 [ 7.911826 ] radeon_bo_fini+0x15/0x40 [ 7.913767 ] rs400_fini+0x55/0x80 [ 7.914358 ] radeon_device_fini+0x3c/0x140 [ 7.914358 ] radeon_driver_unload_kms+0x5c/0xe0 [ 7.914358 ] radeon_driver_load_kms+0x13a/0x200 [ 7.914358 ] ? radeon_driver_unload_kms+0xe0/0xe0 [ 7.914358 ] drm_dev_register+0x1db/0x290 [ 7.914358 ] radeon_pci_probe+0x16a/0x230 [ 7.914358 ] local_pci_probe+0x4a/0xb0 Signed-off-by: Zheyu Ma Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/1626274459-8148-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Christian König Signed-off-by: Sasha Levin commit 2323690eb05865a657709f4d28eb9538ea97bfc2 Author: Vasily Averin Date: Mon Jul 12 09:45:06 2021 +0300 ipv6: allocate enough headroom in ip6_finish_output2() [ Upstream commit 5796015fa968a3349027a27dcd04c71d95c53ba5 ] When TEE target mirrors traffic to another interface, sk_buff may not have enough headroom to be processed correctly. ip_finish_output2() detect this situation for ipv4 and allocates new skb with enogh headroom. However ipv6 lacks this logic in ip_finish_output2 and it leads to skb_under_panic: skbuff: skb_under_panic: text:ffffffffc0866ad4 len:96 put:24 head:ffff97be85e31800 data:ffff97be85e317f8 tail:0x58 end:0xc0 dev:gre0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:110! invalid opcode: 0000 [#1] SMP PTI CPU: 2 PID: 393 Comm: kworker/2:2 Tainted: G OE 5.13.0 #13 Hardware name: Virtuozzo KVM, BIOS 1.11.0-2.vz7.4 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x48/0x4a Call Trace: skb_push.cold.111+0x10/0x10 ipgre_header+0x24/0xf0 [ip_gre] neigh_connected_output+0xae/0xf0 ip6_finish_output2+0x1a8/0x5a0 ip6_output+0x5c/0x110 nf_dup_ipv6+0x158/0x1000 [nf_dup_ipv6] tee_tg6+0x2e/0x40 [xt_TEE] ip6t_do_table+0x294/0x470 [ip6_tables] nf_hook_slow+0x44/0xc0 nf_hook.constprop.34+0x72/0xe0 ndisc_send_skb+0x20d/0x2e0 ndisc_send_ns+0xd1/0x210 addrconf_dad_work+0x3c8/0x540 process_one_work+0x1d1/0x370 worker_thread+0x30/0x390 kthread+0x116/0x130 ret_from_fork+0x22/0x30 Signed-off-by: Vasily Averin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 86cb49e7314eb1ef53a4f7a015536febc889995e Author: Paul E. McKenney Date: Tue May 25 11:28:40 2021 -0700 rcu-tasks: Don't delete holdouts within trc_wait_for_one_reader() [ Upstream commit a9ab9cce9367a2cc02a3c7eb57a004dc0b8f380d ] Invoking trc_del_holdout() from within trc_wait_for_one_reader() is only a performance optimization because the RCU Tasks Trace grace-period kthread will eventually do this within check_all_holdout_tasks_trace(). But it is not a particularly important performance optimization because it only applies to the grace-period kthread, of which there is but one. This commit therefore removes this invocation of trc_del_holdout() in favor of the one in check_all_holdout_tasks_trace() in the grace-period kthread. Reported-by: "Xu, Yanfei" Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 55ddab2bfd7035347765e62748fd1e30cb3528d6 Author: Paul E. McKenney Date: Tue May 25 10:12:45 2021 -0700 rcu-tasks: Don't delete holdouts within trc_inspect_reader() [ Upstream commit 1d10bf55d85d34eb73dd8263635f43fd72135d2d ] As Yanfei pointed out, although invoking trc_del_holdout() is safe from the viewpoint of the integrity of the holdout list itself, the put_task_struct() invoked by trc_del_holdout() can result in use-after-free errors due to later accesses to this task_struct structure by the RCU Tasks Trace grace-period kthread. This commit therefore removes this call to trc_del_holdout() from trc_inspect_reader() in favor of the grace-period thread's existing call to trc_del_holdout(), thus eliminating that particular class of use-after-free errors. Reported-by: "Xu, Yanfei" Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 4d972881f8d8e80e0320169e681284785cfe51e2 Author: Xin Long Date: Tue Jun 29 23:34:08 2021 -0400 sctp: move 198 addresses from unusable to private scope [ Upstream commit 1d11fa231cabeae09a95cb3e4cf1d9dd34e00f08 ] The doc draft-stewart-tsvwg-sctp-ipv4-00 that restricts 198 addresses was never published. These addresses as private addresses should be allowed to use in SCTP. As Michael Tuexen suggested, this patch is to move 198 addresses from unusable to private scope. Reported-by: Sérgio Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 915226f31fd489f9a37894caacd9b4e5f5904a26 Author: Eric Dumazet Date: Tue Jun 29 07:12:45 2021 -0700 net: annotate data race around sk_ll_usec [ Upstream commit 0dbffbb5335a1e3aa6855e4ee317e25e669dd302 ] sk_ll_usec is read locklessly from sk_can_busy_loop() while another thread can change its value in sock_setsockopt() This is correct but needs annotations. BUG: KCSAN: data-race in __skb_try_recv_datagram / sock_setsockopt write to 0xffff88814eb5f904 of 4 bytes by task 14011 on cpu 0: sock_setsockopt+0x1287/0x2090 net/core/sock.c:1175 __sys_setsockopt+0x14f/0x200 net/socket.c:2100 __do_sys_setsockopt net/socket.c:2115 [inline] __se_sys_setsockopt net/socket.c:2112 [inline] __x64_sys_setsockopt+0x62/0x70 net/socket.c:2112 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88814eb5f904 of 4 bytes by task 14001 on cpu 1: sk_can_busy_loop include/net/busy_poll.h:41 [inline] __skb_try_recv_datagram+0x14f/0x320 net/core/datagram.c:273 unix_dgram_recvmsg+0x14c/0x870 net/unix/af_unix.c:2101 unix_seqpacket_recvmsg+0x5a/0x70 net/unix/af_unix.c:2067 ____sys_recvmsg+0x15d/0x310 include/linux/uio.h:244 ___sys_recvmsg net/socket.c:2598 [inline] do_recvmmsg+0x35c/0x9f0 net/socket.c:2692 __sys_recvmmsg net/socket.c:2771 [inline] __do_sys_recvmmsg net/socket.c:2794 [inline] __se_sys_recvmmsg net/socket.c:2787 [inline] __x64_sys_recvmmsg+0xcf/0x150 net/socket.c:2787 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000000 -> 0x00000101 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 14001 Comm: syz-executor.3 Not tainted 5.13.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 92289f58f01d1a7f76c763dbdf1ae4f02ddfab75 Author: Yang Yingliang Date: Tue Jun 29 19:53:28 2021 +0800 net/802/garp: fix memleak in garp_request_join() [ Upstream commit 42ca63f980842918560b25f0244307fd83b4777c ] I got kmemleak report when doing fuzz test: BUG: memory leak unreferenced object 0xffff88810c909b80 (size 64): comm "syz", pid 957, jiffies 4295220394 (age 399.090s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 08 00 00 00 01 02 00 04 ................ backtrace: [<00000000ca1f2e2e>] garp_request_join+0x285/0x3d0 [<00000000bf153351>] vlan_gvrp_request_join+0x15b/0x190 [<0000000024005e72>] vlan_dev_open+0x706/0x980 [<00000000dc20c4d4>] __dev_open+0x2bb/0x460 [<0000000066573004>] __dev_change_flags+0x501/0x650 [<0000000035b42f83>] rtnl_configure_link+0xee/0x280 [<00000000a5e69de0>] __rtnl_newlink+0xed5/0x1550 [<00000000a5258f4a>] rtnl_newlink+0x66/0x90 [<00000000506568ee>] rtnetlink_rcv_msg+0x439/0xbd0 [<00000000b7eaeae1>] netlink_rcv_skb+0x14d/0x420 [<00000000c373ce66>] netlink_unicast+0x550/0x750 [<00000000ec74ce74>] netlink_sendmsg+0x88b/0xda0 [<00000000381ff246>] sock_sendmsg+0xc9/0x120 [<000000008f6a2db3>] ____sys_sendmsg+0x6e8/0x820 [<000000008d9c1735>] ___sys_sendmsg+0x145/0x1c0 [<00000000aa39dd8b>] __sys_sendmsg+0xfe/0x1d0 Calling garp_request_leave() after garp_request_join(), the attr->state is set to GARP_APPLICANT_VO, garp_attr_destroy() won't be called in last transmit event in garp_uninit_applicant(), the attr of applicant will be leaked. To fix this leak, iterate and free each attr of applicant before rerturning from garp_uninit_applicant(). Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5d93810761b4beda2341372bd9d34a78cb9b22c2 Author: Yang Yingliang Date: Tue Jun 29 15:22:37 2021 +0800 net/802/mrp: fix memleak in mrp_request_join() [ Upstream commit 996af62167d0e0ec69b938a3561e96f84ffff1aa ] I got kmemleak report when doing fuzz test: BUG: memory leak unreferenced object 0xffff88810c239500 (size 64): comm "syz-executor940", pid 882, jiffies 4294712870 (age 14.631s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 01 00 00 00 01 02 00 04 ................ backtrace: [<00000000a323afa4>] slab_alloc_node mm/slub.c:2972 [inline] [<00000000a323afa4>] slab_alloc mm/slub.c:2980 [inline] [<00000000a323afa4>] __kmalloc+0x167/0x340 mm/slub.c:4130 [<000000005034ca11>] kmalloc include/linux/slab.h:595 [inline] [<000000005034ca11>] mrp_attr_create net/802/mrp.c:276 [inline] [<000000005034ca11>] mrp_request_join+0x265/0x550 net/802/mrp.c:530 [<00000000fcfd81f3>] vlan_mvrp_request_join+0x145/0x170 net/8021q/vlan_mvrp.c:40 [<000000009258546e>] vlan_dev_open+0x477/0x890 net/8021q/vlan_dev.c:292 [<0000000059acd82b>] __dev_open+0x281/0x410 net/core/dev.c:1609 [<000000004e6dc695>] __dev_change_flags+0x424/0x560 net/core/dev.c:8767 [<00000000471a09af>] rtnl_configure_link+0xd9/0x210 net/core/rtnetlink.c:3122 [<0000000037a4672b>] __rtnl_newlink+0xe08/0x13e0 net/core/rtnetlink.c:3448 [<000000008d5d0fda>] rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3488 [<000000004882fe39>] rtnetlink_rcv_msg+0x369/0xa10 net/core/rtnetlink.c:5552 [<00000000907e6c54>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504 [<00000000e7d7a8c4>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] [<00000000e7d7a8c4>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340 [<00000000e0645d50>] netlink_sendmsg+0x78e/0xc90 net/netlink/af_netlink.c:1929 [<00000000c24559b7>] sock_sendmsg_nosec net/socket.c:654 [inline] [<00000000c24559b7>] sock_sendmsg+0x139/0x170 net/socket.c:674 [<00000000fc210bc2>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350 [<00000000be4577b5>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404 Calling mrp_request_leave() after mrp_request_join(), the attr->state is set to MRP_APPLICANT_VO, mrp_attr_destroy() won't be called in last TX event in mrp_uninit_applicant(), the attr of applicant will be leaked. To fix this leak, iterate and free each attr of applicant before rerturning from mrp_uninit_applicant(). Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit df34f888628e961d8158dbd9712ebf04dfa4ad8c Author: Paul Gortmaker Date: Wed Jun 16 08:51:57 2021 -0400 cgroup1: fix leaked context root causing sporadic NULL deref in LTP commit 1e7107c5ef44431bc1ebbd4c353f1d7c22e5f2ec upstream. Richard reported sporadic (roughly one in 10 or so) null dereferences and other strange behaviour for a set of automated LTP tests. Things like: BUG: kernel NULL pointer dereference, address: 0000000000000008 #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: 1516 Comm: umount Not tainted 5.10.0-yocto-standard #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:kernfs_sop_show_path+0x1b/0x60 ...or these others: RIP: 0010:do_mkdirat+0x6a/0xf0 RIP: 0010:d_alloc_parallel+0x98/0x510 RIP: 0010:do_readlinkat+0x86/0x120 There were other less common instances of some kind of a general scribble but the common theme was mount and cgroup and a dubious dentry triggering the NULL dereference. I was only able to reproduce it under qemu by replicating Richard's setup as closely as possible - I never did get it to happen on bare metal, even while keeping everything else the same. In commit 71d883c37e8d ("cgroup_do_mount(): massage calling conventions") we see this as a part of the overall change: -------------- struct cgroup_subsys *ss; - struct dentry *dentry; [...] - dentry = cgroup_do_mount(&cgroup_fs_type, fc->sb_flags, root, - CGROUP_SUPER_MAGIC, ns); [...] - if (percpu_ref_is_dying(&root->cgrp.self.refcnt)) { - struct super_block *sb = dentry->d_sb; - dput(dentry); + ret = cgroup_do_mount(fc, CGROUP_SUPER_MAGIC, ns); + if (!ret && percpu_ref_is_dying(&root->cgrp.self.refcnt)) { + struct super_block *sb = fc->root->d_sb; + dput(fc->root); deactivate_locked_super(sb); msleep(10); return restart_syscall(); } -------------- In changing from the local "*dentry" variable to using fc->root, we now export/leave that dentry pointer in the file context after doing the dput() in the unlikely "is_dying" case. With LTP doing a crazy amount of back to back mount/unmount [testcases/bin/cgroup_regression_5_1.sh] the unlikely becomes slightly likely and then bad things happen. A fix would be to not leave the stale reference in fc->root as follows: --------------                 dput(fc->root); + fc->root = NULL;                 deactivate_locked_super(sb); -------------- ...but then we are just open-coding a duplicate of fc_drop_locked() so we simply use that instead. Cc: Al Viro Cc: Tejun Heo Cc: Zefan Li Cc: Johannes Weiner Cc: stable@vger.kernel.org # v5.1+ Reported-by: Richard Purdie Fixes: 71d883c37e8d ("cgroup_do_mount(): massage calling conventions") Signed-off-by: Paul Gortmaker Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit dcd00801f3d93bd898b697b7cfc5a5a8069648d2 Author: Yang Yingliang Date: Wed Jul 14 17:19:33 2021 +0800 workqueue: fix UAF in pwq_unbound_release_workfn() commit b42b0bddcbc87b4c66f6497f66fc72d52b712aa7 upstream. I got a UAF report when doing fuzz test: [ 152.880091][ T8030] ================================================================== [ 152.881240][ T8030] BUG: KASAN: use-after-free in pwq_unbound_release_workfn+0x50/0x190 [ 152.882442][ T8030] Read of size 4 at addr ffff88810d31bd00 by task kworker/3:2/8030 [ 152.883578][ T8030] [ 152.883932][ T8030] CPU: 3 PID: 8030 Comm: kworker/3:2 Not tainted 5.13.0+ #249 [ 152.885014][ T8030] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 152.886442][ T8030] Workqueue: events pwq_unbound_release_workfn [ 152.887358][ T8030] Call Trace: [ 152.887837][ T8030] dump_stack_lvl+0x75/0x9b [ 152.888525][ T8030] ? pwq_unbound_release_workfn+0x50/0x190 [ 152.889371][ T8030] print_address_description.constprop.10+0x48/0x70 [ 152.890326][ T8030] ? pwq_unbound_release_workfn+0x50/0x190 [ 152.891163][ T8030] ? pwq_unbound_release_workfn+0x50/0x190 [ 152.891999][ T8030] kasan_report.cold.15+0x82/0xdb [ 152.892740][ T8030] ? pwq_unbound_release_workfn+0x50/0x190 [ 152.893594][ T8030] __asan_load4+0x69/0x90 [ 152.894243][ T8030] pwq_unbound_release_workfn+0x50/0x190 [ 152.895057][ T8030] process_one_work+0x47b/0x890 [ 152.895778][ T8030] worker_thread+0x5c/0x790 [ 152.896439][ T8030] ? process_one_work+0x890/0x890 [ 152.897163][ T8030] kthread+0x223/0x250 [ 152.897747][ T8030] ? set_kthread_struct+0xb0/0xb0 [ 152.898471][ T8030] ret_from_fork+0x1f/0x30 [ 152.899114][ T8030] [ 152.899446][ T8030] Allocated by task 8884: [ 152.900084][ T8030] kasan_save_stack+0x21/0x50 [ 152.900769][ T8030] __kasan_kmalloc+0x88/0xb0 [ 152.901416][ T8030] __kmalloc+0x29c/0x460 [ 152.902014][ T8030] alloc_workqueue+0x111/0x8e0 [ 152.902690][ T8030] __btrfs_alloc_workqueue+0x11e/0x2a0 [ 152.903459][ T8030] btrfs_alloc_workqueue+0x6d/0x1d0 [ 152.904198][ T8030] scrub_workers_get+0x1e8/0x490 [ 152.904929][ T8030] btrfs_scrub_dev+0x1b9/0x9c0 [ 152.905599][ T8030] btrfs_ioctl+0x122c/0x4e50 [ 152.906247][ T8030] __x64_sys_ioctl+0x137/0x190 [ 152.906916][ T8030] do_syscall_64+0x34/0xb0 [ 152.907535][ T8030] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 152.908365][ T8030] [ 152.908688][ T8030] Freed by task 8884: [ 152.909243][ T8030] kasan_save_stack+0x21/0x50 [ 152.909893][ T8030] kasan_set_track+0x20/0x30 [ 152.910541][ T8030] kasan_set_free_info+0x24/0x40 [ 152.911265][ T8030] __kasan_slab_free+0xf7/0x140 [ 152.911964][ T8030] kfree+0x9e/0x3d0 [ 152.912501][ T8030] alloc_workqueue+0x7d7/0x8e0 [ 152.913182][ T8030] __btrfs_alloc_workqueue+0x11e/0x2a0 [ 152.913949][ T8030] btrfs_alloc_workqueue+0x6d/0x1d0 [ 152.914703][ T8030] scrub_workers_get+0x1e8/0x490 [ 152.915402][ T8030] btrfs_scrub_dev+0x1b9/0x9c0 [ 152.916077][ T8030] btrfs_ioctl+0x122c/0x4e50 [ 152.916729][ T8030] __x64_sys_ioctl+0x137/0x190 [ 152.917414][ T8030] do_syscall_64+0x34/0xb0 [ 152.918034][ T8030] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 152.918872][ T8030] [ 152.919203][ T8030] The buggy address belongs to the object at ffff88810d31bc00 [ 152.919203][ T8030] which belongs to the cache kmalloc-512 of size 512 [ 152.921155][ T8030] The buggy address is located 256 bytes inside of [ 152.921155][ T8030] 512-byte region [ffff88810d31bc00, ffff88810d31be00) [ 152.922993][ T8030] The buggy address belongs to the page: [ 152.923800][ T8030] page:ffffea000434c600 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10d318 [ 152.925249][ T8030] head:ffffea000434c600 order:2 compound_mapcount:0 compound_pincount:0 [ 152.926399][ T8030] flags: 0x57ff00000010200(slab|head|node=1|zone=2|lastcpupid=0x7ff) [ 152.927515][ T8030] raw: 057ff00000010200 dead000000000100 dead000000000122 ffff888009c42c80 [ 152.928716][ T8030] raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 [ 152.929890][ T8030] page dumped because: kasan: bad access detected [ 152.930759][ T8030] [ 152.931076][ T8030] Memory state around the buggy address: [ 152.931851][ T8030] ffff88810d31bc00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 152.932967][ T8030] ffff88810d31bc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 152.934068][ T8030] >ffff88810d31bd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 152.935189][ T8030] ^ [ 152.935763][ T8030] ffff88810d31bd80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 152.936847][ T8030] ffff88810d31be00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 152.937940][ T8030] ================================================================== If apply_wqattrs_prepare() fails in alloc_workqueue(), it will call put_pwq() which invoke a work queue to call pwq_unbound_release_workfn() and use the 'wq'. The 'wq' allocated in alloc_workqueue() will be freed in error path when apply_wqattrs_prepare() fails. So it will lead a UAF. CPU0 CPU1 alloc_workqueue() alloc_and_link_pwqs() apply_wqattrs_prepare() fails apply_wqattrs_cleanup() schedule_work(&pwq->unbound_release_work) kfree(wq) worker_thread() pwq_unbound_release_workfn() <- trigger uaf here If apply_wqattrs_prepare() fails, the new pwq are not linked, it doesn't hold any reference to the 'wq', 'wq' is invalid to access in the worker, so add check pwq if linked to fix this. Fixes: 2d5f0764b526 ("workqueue: split apply_workqueue_attrs() into 3 stages") Cc: stable@vger.kernel.org # v4.2+ Reported-by: Hulk Robot Suggested-by: Lai Jiangshan Signed-off-by: Yang Yingliang Reviewed-by: Lai Jiangshan Tested-by: Pavel Skripkin Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 93c5951e0ce137e994237c19cd75a7caa1f80543 Author: Miklos Szeredi Date: Wed Jul 28 14:47:20 2021 +0200 af_unix: fix garbage collect vs MSG_PEEK commit cbcf01128d0a92e131bd09f1688fe032480b65ca upstream. unix_gc() assumes that candidate sockets can never gain an external reference (i.e. be installed into an fd) while the unix_gc_lock is held. Except for MSG_PEEK this is guaranteed by modifying inflight count under the unix_gc_lock. MSG_PEEK does not touch any variable protected by unix_gc_lock (file count is not), yet it needs to be serialized with garbage collection. Do this by locking/unlocking unix_gc_lock: 1) increment file count 2) lock/unlock barrier to make sure incremented file count is visible to garbage collection 3) install file into fd This is a lock barrier (unlike smp_mb()) that ensures that garbage collection is run completely before or completely after the barrier. Cc: Signed-off-by: Miklos Szeredi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dee8119eaa9e00f0d1e14f050e1867813a49a1bb Author: Maxim Levitsky Date: Thu Feb 25 17:41:32 2021 +0200 KVM: x86: determine if an exception has an error code only when injecting it. commit b97f074583736c42fb36f2da1164e28c73758912 upstream. A page fault can be queued while vCPU is in real paged mode on AMD, and AMD manual asks the user to always intercept it (otherwise result is undefined). The resulting VM exit, does have an error code. Signed-off-by: Maxim Levitsky Message-Id: <20210225154135.405125-2-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Zubin Mithra Signed-off-by: Greg Kroah-Hartman commit 6f5d7a45f58d3abe3a936de1441b8d6318f978ff Author: Pavel Begunkov Date: Mon Jul 26 16:17:20 2021 +0100 io_uring: fix link timeout refs [ Upstream commit a298232ee6b9a1d5d732aa497ff8be0d45b5bd82 ] WARNING: CPU: 0 PID: 10242 at lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 RIP: 0010:refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] io_put_req fs/io_uring.c:2140 [inline] io_queue_linked_timeout fs/io_uring.c:6300 [inline] __io_queue_sqe+0xbef/0xec0 fs/io_uring.c:6354 io_submit_sqe fs/io_uring.c:6534 [inline] io_submit_sqes+0x2bbd/0x7c50 fs/io_uring.c:6660 __do_sys_io_uring_enter fs/io_uring.c:9240 [inline] __se_sys_io_uring_enter+0x256/0x1d60 fs/io_uring.c:9182 io_link_timeout_fn() should put only one reference of the linked timeout request, however in case of racing with the master request's completion first io_req_complete() puts one and then io_put_req_deferred() is called. Cc: stable@vger.kernel.org # 5.12+ Fixes: 9ae1f8dd372e0 ("io_uring: fix inconsistent lock state") Reported-by: syzbot+a2910119328ce8e7996f@syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/ff51018ff29de5ffa76f09273ef48cb24c720368.1620417627.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 475312897ea6b4b9a9a56c838aec6370c42f7315 Author: Yonghong Song Date: Tue Apr 13 08:34:19 2021 -0700 tools: Allow proper CC/CXX/... override with LLVM=1 in Makefile.include commit f62700ce63a315b4607cc9e97aa15ea409a677b9 upstream. selftests/bpf/Makefile includes tools/scripts/Makefile.include. With the following command make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 V=1 some files are still compiled with gcc. This patch fixed the case if CC/AR/LD/CXX/STRIP is allowed to be overridden, it will be written to clang/llvm-ar/..., instead of gcc binaries. The definition of CC_NO_CLANG is also relocated to the place after the above CC is defined. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210413153419.3028165-1-yhs@fb.com Cc: Anders Roxell Signed-off-by: Greg Kroah-Hartman commit 08277b9dde633e1447e96b8cb89da2b40f96ae69 Author: Greg Kroah-Hartman Date: Wed Jul 28 14:35:48 2021 +0200 Linux 5.10.54 Link: https://lore.kernel.org/r/20210726153839.371771838@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20210726165240.137482144@linuxfoundation.org Tested-by: Fox Chen Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit c9f8e17990e05b1c848a28566e3a31f7fef8ea2c Author: Florian Fainelli Date: Wed Jul 7 21:10:51 2021 -0700 skbuff: Fix build with SKB extensions disabled commit 9615fe36b31d926f1c5107013b772dc226a6a7ca upstream. We will fail to build with CONFIG_SKB_EXTENSIONS disabled after 8550ff8d8c75 ("skbuff: Release nfct refcount on napi stolen or re-used skbs") since there is an unconditionally use of skb_ext_find() without an appropriate stub. Simply build the code conditionally and properly guard against both COFNIG_SKB_EXTENSIONS as well as CONFIG_NET_TC_SKB_EXT being disabled. Fixes: Fixes: 8550ff8d8c75 ("skbuff: Release nfct refcount on napi stolen or re-used skbs") Signed-off-by: Florian Fainelli Reviewed-by: Roi Dayan Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ba28765d338ae849af3fc60346f9d457df0cffb3 Author: Mathias Nyman Date: Fri Jan 29 15:00:22 2021 +0200 xhci: add xhci_get_virt_ep() helper [commit b1adc42d440df3233255e313a45ab7e9b2b74096 upstream] In several event handlers we need to find the right endpoint structure from slot_id and ep_index in the event. Add a helper for this, check that slot_id and ep_index are valid. Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210129130044.206855-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Carsten Schmid Signed-off-by: Greg Kroah-Hartman commit 624290f368af1be41f16b2474f9dd406706f88f5 Author: Íñigo Huguet Date: Tue Jul 13 16:21:28 2021 +0200 sfc: ensure correct number of XDP queues [ Upstream commit 788bc000d4c2f25232db19ab3a0add0ba4e27671 ] Commit 99ba0ea616aa ("sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues") intended to fix a problem caused by a round up when calculating the number of XDP channels and queues. However, this was not the real problem. The real problem was that the number of XDP TX queues had been reduced to half in commit e26ca4b53582 ("sfc: reduce the number of requested xdp ev queues"), but the variable xdp_tx_queue_count had remained the same. Once the correct number of XDP TX queues is created again in the previous patch of this series, this also can be reverted since the error doesn't actually exist. Only in the case that there is a bug in the code we can have different values in xdp_queue_number and efx->xdp_tx_queue_count. Because of this, and per Edward Cree's suggestion, I add instead a WARN_ON to catch if it happens again in the future. Note that the number of allocated queues can be higher than the number of used ones due to the round up, as explained in the existing comment in the code. That's why we also have to stop increasing xdp_queue_number beyond efx->xdp_tx_queue_count. Signed-off-by: Íñigo Huguet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1df4fe5a8871f49d34d681ff5b7f93a84d50af4b Author: Colin Xu Date: Wed Jul 7 08:45:31 2021 +0800 drm/i915/gvt: Clear d3_entered on elsp cmd submission. commit c90b4503ccf42d9d367e843c223df44aa550e82a upstream. d3_entered flag is used to mark for vgpu_reset a previous power transition from D3->D0, typically for VM resume from S3, so that gvt could skip PPGTT invalidation in current vgpu_reset during resuming. In case S0ix exit, although there is D3->D0, guest driver continue to use vgpu as normal, with d3_entered set, until next shutdown/reboot or power transition. If a reboot follows a S0ix exit, device power state transite as: D0->D3->D0->D0(reboot), while system power state transites as: S0->S0 (reboot). There is no vgpu_reset until D0(reboot), thus d3_entered won't be cleared, the vgpu_reset will skip PPGTT invalidation however those PPGTT entries are no longer valid. Err appears like: gvt: vgpu 2: vfio_pin_pages failed for gfn 0xxxxx, ret -22 gvt: vgpu 2: fail: spt xxxx guest entry 0xxxxx type 2 gvt: vgpu 2: fail: shadow page xxxx guest entry 0xxxxx type 2. Give gvt a chance to clear d3_entered on elsp cmd submission so that the states before & after S0ix enter/exit are consistent. Fixes: ba25d977571e ("drm/i915/gvt: Do not destroy ppgtt_mm during vGPU D3->D0.") Reviewed-by: Zhenyu Wang Signed-off-by: Colin Xu Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/20210707004531.4873-1-colin.xu@intel.com Signed-off-by: Greg Kroah-Hartman commit c938e65768e0a80e7ea24899795878072e79b152 Author: David Jeffery Date: Thu Jul 15 17:37:44 2021 -0400 usb: ehci: Prevent missed ehci interrupts with edge-triggered MSI commit 0b60557230adfdeb8164e0b342ac9cd469a75759 upstream. When MSI is used by the ehci-hcd driver, it can cause lost interrupts which results in EHCI only continuing to work due to a polling fallback. But the reliance of polling drastically reduces performance of any I/O through EHCI. Interrupts are lost as the EHCI interrupt handler does not safely handle edge-triggered interrupts. It fails to ensure all interrupt status bits are cleared, which works with level-triggered interrupts but not the edge-triggered interrupts typical from using MSI. To fix this problem, check if the driver may have raced with the hardware setting additional interrupt status bits and clear status until it is in a stable state. Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices") Tested-by: Laurence Oberman Reviewed-by: Andy Shevchenko Acked-by: Alan Stern Signed-off-by: David Jeffery Link: https://lore.kernel.org/r/20210715213744.GA44506@redhat Cc: stable Signed-off-by: Greg Kroah-Hartman commit 25af91a806d230503e76f23c7d3497541143fccc Author: Riccardo Mancini Date: Thu Jul 15 18:07:15 2021 +0200 perf inject: Close inject.output on exit commit 02e6246f5364d5260a6ea6f92ab6f409058b162f upstream. ASan reports a memory leak when running: # perf test "83: Zstd perf.data compression/decompression" which happens inside 'perf inject'. The bug is caused by inject.output never being closed. This patch adds the missing perf_data__close(). Signed-off-by: Riccardo Mancini Fixes: 6ef81c55a2b6584c ("perf session: Return error code for perf_session__new() function on failure") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mamatha Inamdar Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/c06f682afa964687367cf6e92a64ceb49aec76a5.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit fb35426d123eff7ae47085dc68f15b78f027fdbc Author: Robert Richter Date: Thu Jul 15 11:26:02 2021 +0200 Documentation: Fix intiramfs script name commit 5e60f363b38fd40e4d8838b5d6f4d4ecee92c777 upstream. Documentation was not changed when renaming the script in commit 80e715a06c2d ("initramfs: rename gen_initramfs_list.sh to gen_initramfs.sh"). Fixing this. Basically does: $ sed -i -e s/gen_initramfs_list.sh/gen_initramfs.sh/g $(git grep -l gen_initramfs_list.sh) Fixes: 80e715a06c2d ("initramfs: rename gen_initramfs_list.sh to gen_initramfs.sh") Signed-off-by: Robert Richter Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 570341f10eccfe5c339363544a0339a8550944b7 Author: Paul Blakey Date: Mon Jul 5 13:54:51 2021 +0300 skbuff: Release nfct refcount on napi stolen or re-used skbs commit 8550ff8d8c75416e984d9c4b082845e57e560984 upstream. When multiple SKBs are merged to a new skb under napi GRO, or SKB is re-used by napi, if nfct was set for them in the driver, it will not be released while freeing their stolen head state or on re-use. Release nfct on napi's stolen or re-used SKBs, and in gro_list_prepare, check conntrack metadata diff. Fixes: 5c6b94604744 ("net/mlx5e: CT: Handle misses after executing CT action") Reviewed-by: Roi Dayan Signed-off-by: Paul Blakey Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 31828ffdab19a76170483ce405b3dde449215652 Author: Mahesh Bandewar Date: Fri Jul 16 16:09:41 2021 -0700 bonding: fix build issue commit 5b69874f74cc5707edd95fcdaa757c507ac8af0f upstream. The commit 9a5605505d9c (" bonding: Add struct bond_ipesc to manage SA") is causing following build error when XFRM is not selected in kernel config. lld: error: undefined symbol: xfrm_dev_state_flush >>> referenced by bond_main.c:3453 (drivers/net/bonding/bond_main.c:3453) >>> net/bonding/bond_main.o:(bond_netdev_event) in archive drivers/built-in.a Fixes: 9a5605505d9c (" bonding: Add struct bond_ipesc to manage SA") Signed-off-by: Mahesh Bandewar CC: Taehee Yoo CC: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c9d97b7bb897a3916f300dcc6967261166361107 Author: Evan Quan Date: Wed Jun 2 10:12:55 2021 +0800 PCI: Mark AMD Navi14 GPU ATS as broken commit e8946a53e2a698c148b3b3ed732f43c7747fbeb6 upstream Observed unexpected GPU hang during runpm stress test on 0x7341 rev 0x00. Further debugging shows broken ATS is related. Disable ATS on this part. Similar issues on other devices: a2da5d8cc0b0 ("PCI: Mark AMD Raven iGPU ATS as broken in some platforms") 45beb31d3afb ("PCI: Mark AMD Navi10 GPU rev 0x00 ATS as broken") 5e89cd303e3a ("PCI: Mark AMD Navi14 GPU rev 0xc5 ATS as broken") Suggested-by: Alex Deucher Link: https://lore.kernel.org/r/20210602021255.939090-1-evan.quan@amd.com Signed-off-by: Evan Quan Signed-off-by: Bjorn Helgaas Reviewed-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org [sudip: adjust context] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit f7ee361182e05a39a96528b581ae9215a9d26161 Author: Marek Behún Date: Thu Jul 1 00:22:31 2021 +0200 net: dsa: mv88e6xxx: enable SerDes PCS register dump via ethtool -d on Topaz commit 953b0dcbe2e3f7bee98cc3bca2ec82c8298e9c16 upstream. Commit bf3504cea7d7e ("net: dsa: mv88e6xxx: Add 6390 family PCS registers to ethtool -d") added support for dumping SerDes PCS registers via ethtool -d for Peridot. The same implementation is also valid for Topaz, but was not enabled at the time. Signed-off-by: Marek Behún Fixes: bf3504cea7d7e ("net: dsa: mv88e6xxx: Add 6390 family PCS registers to ethtool -d") Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 30f1d4d03641e4ed446a5e86d019b1ed7b4355bc Author: Marek Behún Date: Thu Jul 1 00:22:30 2021 +0200 net: dsa: mv88e6xxx: enable SerDes RX stats for Topaz commit a03b98d68367b18e5db6d6850e2cc18754fba94a upstream. Commit 0df952873636a ("mv88e6xxx: Add serdes Rx statistics") added support for RX statistics on SerDes ports for Peridot. This same implementation is also valid for Topaz, but was not enabled at the time. We need to use the generic .serdes_get_lane() method instead of the Peridot specific one in the stats methods so that on Topaz the proper one is used. Signed-off-by: Marek Behún Fixes: 0df952873636a ("mv88e6xxx: Add serdes Rx statistics") Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fc31b5be1383e31ca046fdd6e11e0a9a0b3a01d5 Author: Likun Gao Date: Thu Jul 15 11:08:48 2021 +0800 drm/amdgpu: update golden setting for sienna_cichlid commit 3e94b5965e624f7e6d8dd18eb8f3bf2bb99ba30d upstream. Update GFX golden setting for sienna_cichlid. Signed-off-by: Likun Gao Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 69a603aa170e1c145b93d5d7efcca83a8b1268fe Author: Charles Baylis Date: Fri Jul 16 17:43:12 2021 +0100 drm: Return -ENOTTY for non-drm ioctls commit 3abab27c322e0f2acf981595aa8040c9164dc9fb upstream. drm: Return -ENOTTY for non-drm ioctls Return -ENOTTY from drm_ioctl() when userspace passes in a cmd number which doesn't relate to the drm subsystem. Glibc uses the TCGETS ioctl to implement isatty(), and without this change isatty() returns it incorrectly returns true for drm devices. To test run this command: $ if [ -t 0 ]; then echo is a tty; fi < /dev/dri/card0 which shows "is a tty" without this patch. This may also modify memory which the userspace application is not expecting. Signed-off-by: Charles Baylis Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/YPG3IBlzaMhfPqCr@stando.fishzet.co.uk Signed-off-by: Greg Kroah-Hartman commit 2831eeb7bc3d6b2b1ddcd488f7ccfc60ff21808e Author: Adrian Hunter Date: Fri Jul 16 14:44:07 2021 +0300 driver core: Prevent warning when removing a device link from unregistered consumer commit e64daad660a0c9ace3acdc57099fffe5ed83f977 upstream. sysfs_remove_link() causes a warning if the parent directory does not exist. That can happen if the device link consumer has not been registered. So do not attempt sysfs_remove_link() in that case. Fixes: 287905e68dd29 ("driver core: Expose device link details in sysfs") Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org # 5.9+ Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20210716114408.17320-2-adrian.hunter@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 0e759383236a2264f3fcbbb8c338d5b3121cfe83 Author: Greg Kroah-Hartman Date: Tue Jun 29 12:40:24 2021 +0200 nds32: fix up stack guard gap commit c453db6cd96418c79702eaf38259002755ab23ff upstream. Commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") fixed up all architectures to deal with the stack guard gap. But when nds32 was added to the tree, it forgot to do the same thing. Resolve this by properly fixing up the nsd32's version of arch_get_unmapped_area() Cc: Nick Hu Cc: Greentime Hu Cc: Vincent Chen Cc: Michal Hocko Cc: Hugh Dickins Cc: Qiang Liu Cc: stable Reported-by: iLifetruth Acked-by: Hugh Dickins Link: https://lore.kernel.org/r/20210629104024.2293615-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 7497f4c91da381d448090887ca00380f4d99ebb2 Author: Jérôme Glisse Date: Thu Jul 1 08:28:25 2021 -0700 misc: eeprom: at24: Always append device id even if label property is set. commit c36748ac545421d94a5091c754414c0f3664bf10 upstream. We need to append device id even if eeprom have a label property set as some platform can have multiple eeproms with same label and we can not register each of those with same label. Failing to register those eeproms trigger cascade failures on such platform (system is no longer working). This fix regression on such platform introduced with 4e302c3b568e Reported-by: Alexander Fomichev Fixes: 4e302c3b568e ("misc: eeprom: at24: fix NVMEM name with custom AT24 device name") Cc: stable@vger.kernel.org Signed-off-by: Jérôme Glisse Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 8571daace5a6e33c9081a4e0589662d2b4806abc Author: Ilya Dryomov Date: Sat Jul 3 11:56:55 2021 +0200 rbd: always kick acquire on "acquired" and "released" notifications commit 8798d070d416d18a75770fc19787e96705073f43 upstream. Skipping the "lock has been released" notification if the lock owner is not what we expect based on owner_cid can lead to I/O hangs. One example is our own notifications: because owner_cid is cleared in rbd_unlock(), when we get our own notification it is processed as unexpected/duplicate and maybe_kick_acquire() isn't called. If a peer that requested the lock then doesn't go through with acquiring it, I/O requests that came in while the lock was being quiesced would be stalled until another I/O request is submitted and kicks acquire from rbd_img_exclusive_lock(). This makes the comment in rbd_release_lock() actually true: prior to this change the canceled work was being requeued in response to the "lock has been acquired" notification from rbd_handle_acquired_lock(). Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Ilya Dryomov Tested-by: Robin Geuze Signed-off-by: Greg Kroah-Hartman commit 2f3731de5e6970d2d54b6135d164e8c30f1f9177 Author: Ilya Dryomov Date: Sat Jul 3 11:31:26 2021 +0200 rbd: don't hold lock_rwsem while running_list is being drained commit ed9eb71085ecb7ded9a5118cec2ab70667cc7350 upstream. Currently rbd_quiesce_lock() holds lock_rwsem for read while blocking on releasing_wait completion. On the I/O completion side, each image request also needs to take lock_rwsem for read. Because rw_semaphore implementation doesn't allow new readers after a writer has indicated interest in the lock, this can result in a deadlock if something that needs to take lock_rwsem for write gets involved. For example: 1. watch error occurs 2. rbd_watch_errcb() takes lock_rwsem for write, clears owner_cid and releases lock_rwsem 3. after reestablishing the watch, rbd_reregister_watch() takes lock_rwsem for write and calls rbd_reacquire_lock() 4. rbd_quiesce_lock() downgrades lock_rwsem to for read and blocks on releasing_wait until running_list becomes empty 5. another watch error occurs 6. rbd_watch_errcb() blocks trying to take lock_rwsem for write 7. no in-flight image request can complete and delete itself from running_list because lock_rwsem won't be granted anymore A similar scenario can occur with "lock has been acquired" and "lock has been released" notification handers which also take lock_rwsem for write to update owner_cid. We don't actually get anything useful from sitting on lock_rwsem in rbd_quiesce_lock() -- owner_cid updates certainly don't need to be synchronized with. In fact the whole owner_cid tracking logic could probably be removed from the kernel client because we don't support proxied maintenance operations. Cc: stable@vger.kernel.org # 5.3+ URL: https://tracker.ceph.com/issues/42757 Signed-off-by: Ilya Dryomov Tested-by: Robin Geuze Signed-off-by: Greg Kroah-Hartman commit 92291fa2d144b13a761578cb40d36d37e7f332ee Author: Mike Kravetz Date: Fri Jul 23 15:50:44 2021 -0700 hugetlbfs: fix mount mode command line processing commit e0f7e2b2f7e7864238a4eea05cc77ae1be2bf784 upstream. In commit 32021982a324 ("hugetlbfs: Convert to fs_context") processing of the mount mode string was changed from match_octal() to fsparam_u32. This changed existing behavior as match_octal does not require octal values to have a '0' prefix, but fsparam_u32 does. Use fsparam_u32oct which provides the same behavior as match_octal. Link: https://lkml.kernel.org/r/20210721183326.102716-1-mike.kravetz@oracle.com Fixes: 32021982a324 ("hugetlbfs: Convert to fs_context") Signed-off-by: Mike Kravetz Reported-by: Dennis Camera Reviewed-by: Matthew Wilcox (Oracle) Cc: David Howells Cc: Al Viro Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1a25c5738d0c2285a2ffb636cbe4ffb63aa98d4f Author: Mike Rapoport Date: Fri Jul 23 15:50:26 2021 -0700 memblock: make for_each_mem_range() traverse MEMBLOCK_HOTPLUG regions commit 79e482e9c3ae86e849c701c846592e72baddda5a upstream. Commit b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()") didn't take into account that when there is movable_node parameter in the kernel command line, for_each_mem_range() would skip ranges marked with MEMBLOCK_HOTPLUG. The page table setup code in POWER uses for_each_mem_range() to create the linear mapping of the physical memory and since the regions marked as MEMORY_HOTPLUG are skipped, they never make it to the linear map. A later access to the memory in those ranges will fail: BUG: Unable to handle kernel data access on write at 0xc000000400000000 Faulting instruction address: 0xc00000000008a3c0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 0 PID: 53 Comm: kworker/u2:0 Not tainted 5.13.0 #7 NIP: c00000000008a3c0 LR: c0000000003c1ed8 CTR: 0000000000000040 REGS: c000000008a57770 TRAP: 0300 Not tainted (5.13.0) MSR: 8000000002009033 CR: 84222202 XER: 20040000 CFAR: c0000000003c1ed4 DAR: c000000400000000 DSISR: 42000000 IRQMASK: 0 GPR00: c0000000003c1ed8 c000000008a57a10 c0000000019da700 c000000400000000 GPR04: 0000000000000280 0000000000000180 0000000000000400 0000000000000200 GPR08: 0000000000000100 0000000000000080 0000000000000040 0000000000000300 GPR12: 0000000000000380 c000000001bc0000 c0000000001660c8 c000000006337e00 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000040000000 0000000020000000 c000000001a81990 c000000008c30000 GPR24: c000000008c20000 c000000001a81998 000fffffffff0000 c000000001a819a0 GPR28: c000000001a81908 c00c000001000000 c000000008c40000 c000000008a64680 NIP clear_user_page+0x50/0x80 LR __handle_mm_fault+0xc88/0x1910 Call Trace: __handle_mm_fault+0xc44/0x1910 (unreliable) handle_mm_fault+0x130/0x2a0 __get_user_pages+0x248/0x610 __get_user_pages_remote+0x12c/0x3e0 get_arg_page+0x54/0xf0 copy_string_kernel+0x11c/0x210 kernel_execve+0x16c/0x220 call_usermodehelper_exec_async+0x1b0/0x2f0 ret_from_kernel_thread+0x5c/0x70 Instruction dump: 79280fa4 79271764 79261f24 794ae8e2 7ca94214 7d683a14 7c893a14 7d893050 7d4903a6 60000000 60000000 60000000 <7c001fec> 7c091fec 7c081fec 7c051fec ---[ end trace 490b8c67e6075e09 ]--- Making for_each_mem_range() include MEMBLOCK_HOTPLUG regions in the traversal fixes this issue. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976100 Link: https://lkml.kernel.org/r/20210712071132.20902-1-rppt@kernel.org Fixes: b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()") Signed-off-by: Mike Rapoport Tested-by: Greg Kurz Reviewed-by: David Hildenbrand Cc: [5.10+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0b591c020d280cc0cd92d84c24a5be89b4c57033 Author: Peter Collingbourne Date: Fri Jul 23 15:50:01 2021 -0700 userfaultfd: do not untag user pointers commit e71e2ace5721a8b921dca18b045069e7bb411277 upstream. Patch series "userfaultfd: do not untag user pointers", v5. If a user program uses userfaultfd on ranges of heap memory, it may end up passing a tagged pointer to the kernel in the range.start field of the UFFDIO_REGISTER ioctl. This can happen when using an MTE-capable allocator, or on Android if using the Tagged Pointers feature for MTE readiness [1]. When a fault subsequently occurs, the tag is stripped from the fault address returned to the application in the fault.address field of struct uffd_msg. However, from the application's perspective, the tagged address *is* the memory address, so if the application is unaware of memory tags, it may get confused by receiving an address that is, from its point of view, outside of the bounds of the allocation. We observed this behavior in the kselftest for userfaultfd [2] but other applications could have the same problem. Address this by not untagging pointers passed to the userfaultfd ioctls. Instead, let the system call fail. Also change the kselftest to use mmap so that it doesn't encounter this problem. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c This patch (of 2): Do not untag pointers passed to the userfaultfd ioctls. Instead, let the system call fail. This will provide an early indication of problems with tag-unaware userspace code instead of letting the code get confused later, and is consistent with how we decided to handle brk/mmap/mremap in commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()"), as well as being consistent with the existing tagged address ABI documentation relating to how ioctl arguments are handled. The code change is a revert of commit 7d0325749a6c ("userfaultfd: untag user pointers") plus some fixups to some additional calls to validate_range that have appeared since then. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c Link: https://lkml.kernel.org/r/20210714195437.118982-1-pcc@google.com Link: https://lkml.kernel.org/r/20210714195437.118982-2-pcc@google.com Link: https://linux-review.googlesource.com/id/I761aa9f0344454c482b83fcfcce547db0a25501b Fixes: 63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user addresses ABI") Signed-off-by: Peter Collingbourne Reviewed-by: Andrey Konovalov Reviewed-by: Catalin Marinas Cc: Alistair Delva Cc: Andrea Arcangeli Cc: Dave Martin Cc: Evgenii Stepanov Cc: Lokesh Gidra Cc: Mitch Phillips Cc: Vincenzo Frascino Cc: Will Deacon Cc: William McVicker Cc: [5.4] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fca5343b4892c7a1ce6f03fa1988f8ef3a99e7f6 Author: Pavel Begunkov Date: Tue Jul 20 10:50:44 2021 +0100 io_uring: remove double poll entry on arm failure commit 46fee9ab02cb24979bbe07631fc3ae95ae08aa3e upstream. __io_queue_proc() can enqueue both poll entries and still fail afterwards, so the callers trying to cancel it should also try to remove the second poll entry (if any). For example, it may leave the request alive referencing a io_uring context but not accessible for cancellation: [ 282.599913][ T1620] task:iou-sqp-23145 state:D stack:28720 pid:23155 ppid: 8844 flags:0x00004004 [ 282.609927][ T1620] Call Trace: [ 282.613711][ T1620] __schedule+0x93a/0x26f0 [ 282.634647][ T1620] schedule+0xd3/0x270 [ 282.638874][ T1620] io_uring_cancel_generic+0x54d/0x890 [ 282.660346][ T1620] io_sq_thread+0xaac/0x1250 [ 282.696394][ T1620] ret_from_fork+0x1f/0x30 Cc: stable@vger.kernel.org Fixes: 18bceab101add ("io_uring: allow POLL_ADD with double poll_wait() users") Reported-and-tested-by: syzbot+ac957324022b7132accf@syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/0ec1228fc5eda4cb524eeda857da8efdc43c331c.1626774457.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9eef9029151c059ef5225d112f22569142e43f43 Author: Pavel Begunkov Date: Tue Jul 20 10:50:43 2021 +0100 io_uring: explicitly count entries for poll reqs commit 68b11e8b1562986c134764433af64e97d30c9fc0 upstream. If __io_queue_proc() fails to add a second poll entry, e.g. kmalloc() failed, but it goes on with a third waitqueue, it may succeed and overwrite the error status. Count the number of poll entries we added, so we can set pt->error to zero at the beginning and find out when the mentioned scenario happens. Cc: stable@vger.kernel.org Fixes: 18bceab101add ("io_uring: allow POLL_ADD with double poll_wait() users") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/9d6b9e561f88bcc0163623b74a76c39f712151c3.1626774457.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1077e2b15283dff2f8c7dcc2ad934bccb8c617ad Author: Peter Collingbourne Date: Fri Jul 23 15:50:04 2021 -0700 selftest: use mmap instead of posix_memalign to allocate memory commit 0db282ba2c12c1515d490d14a1ff696643ab0f1b upstream. This test passes pointers obtained from anon_allocate_area to the userfaultfd and mremap APIs. This causes a problem if the system allocator returns tagged pointers because with the tagged address ABI the kernel rejects tagged addresses passed to these APIs, which would end up causing the test to fail. To make this test compatible with such system allocators, stop using the system allocator to allocate memory in anon_allocate_area, and instead just use mmap. Link: https://lkml.kernel.org/r/20210714195437.118982-3-pcc@google.com Link: https://linux-review.googlesource.com/id/Icac91064fcd923f77a83e8e133f8631c5b8fc241 Fixes: c47174fc362a ("userfaultfd: selftest") Co-developed-by: Lokesh Gidra Signed-off-by: Lokesh Gidra Signed-off-by: Peter Collingbourne Reviewed-by: Catalin Marinas Cc: Vincenzo Frascino Cc: Dave Martin Cc: Will Deacon Cc: Andrea Arcangeli Cc: Alistair Delva Cc: William McVicker Cc: Evgenii Stepanov Cc: Mitch Phillips Cc: Andrey Konovalov Cc: [5.4] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6e81e2c38a3844a978f90df81ec3302cb3ac4560 Author: Frederic Weisbecker Date: Thu Jun 3 01:15:59 2021 +0200 posix-cpu-timers: Fix rearm racing against process tick commit 1a3402d93c73bf6bb4df6d7c2aac35abfc3c50e2 upstream. Since the process wide cputime counter is started locklessly from posix_cpu_timer_rearm(), it can be concurrently stopped by operations on other timers from the same thread group, such as in the following unlucky scenario: CPU 0 CPU 1 ----- ----- timer_settime(TIMER B) posix_cpu_timer_rearm(TIMER A) cpu_clock_sample_group() (pct->timers_active already true) handle_posix_cpu_timers() check_process_timers() stop_process_timers() pct->timers_active = false arm_timer(TIMER A) tick -> run_posix_cpu_timers() // sees !pct->timers_active, ignore // our TIMER A Fix this with simply locking process wide cputime counting start and timer arm in the same block. Acked-by: Peter Zijlstra (Intel) Signed-off-by: Frederic Weisbecker Fixes: 60f2ceaa8111 ("posix-cpu-timers: Remove unnecessary locking around cpu_clock_sample_group") Cc: stable@vger.kernel.org Cc: Oleg Nesterov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit 3efec3b4b16fc7af25676a94230a8ab2a3bb867c Author: Bhaumik Bhatt Date: Fri Jul 16 13:21:05 2021 +0530 bus: mhi: core: Validate channel ID when processing command completions commit 546362a9ef2ef40b57c6605f14e88ced507f8dd0 upstream. MHI reads the channel ID from the event ring element sent by the device which can be any value between 0 and 255. In order to prevent any out of bound accesses, add a check against the maximum number of channels supported by the controller and those channels not configured yet so as to skip processing of that event ring element. Link: https://lore.kernel.org/r/1624558141-11045-1-git-send-email-bbhatt@codeaurora.org Fixes: 1d3173a3bae7 ("bus: mhi: core: Add support for processing events from client device") Cc: stable@vger.kernel.org #5.10 Reviewed-by: Hemant Kumar Reviewed-by: Manivannan Sadhasivam Reviewed-by: Jeffrey Hugo Signed-off-by: Bhaumik Bhatt Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210716075106.49938-3-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman commit b3f3a58a86c43733af94105739655ebc160c4ae7 Author: Markus Boehme Date: Tue Jul 20 16:26:19 2021 -0700 ixgbe: Fix packet corruption due to missing DMA sync commit 09cfae9f13d51700b0fecf591dcd658fc5375428 upstream. When receiving a packet with multiple fragments, hardware may still touch the first fragment until the entire packet has been received. The driver therefore keeps the first fragment mapped for DMA until end of packet has been asserted, and delays its dma_sync call until then. The driver tries to fit multiple receive buffers on one page. When using 3K receive buffers (e.g. using Jumbo frames and legacy-rx is turned off/build_skb is being used) on an architecture with 4K pages, the driver allocates an order 1 compound page and uses one page per receive buffer. To determine the correct offset for a delayed DMA sync of the first fragment of a multi-fragment packet, the driver then cannot just use PAGE_MASK on the DMA address but has to construct a mask based on the actual size of the backing page. Using PAGE_MASK in the 3K RX buffer/4K page architecture configuration will always sync the first page of a compound page. With the SWIOTLB enabled this can lead to corrupted packets (zeroed out first fragment, re-used garbage from another packet) and various consequences, such as slow/stalling data transfers and connection resets. For example, testing on a link with MTU exceeding 3058 bytes on a host with SWIOTLB enabled (e.g. "iommu=soft swiotlb=262144,force") TCP transfers quickly fizzle out without this patch. Cc: stable@vger.kernel.org Fixes: 0c5661ecc5dd7 ("ixgbe: fix crash in build_skb Rx code path") Signed-off-by: Markus Boehme Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e991457afdcb5f4dbc5bc9d79eaf775be33e7092 Author: Gustavo A. R. Silva Date: Mon Apr 19 18:43:32 2021 -0500 media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Fixes: dae52d009fc9 ("V4L/DVB: ngene: Initial check-in") Cc: stable@vger.kernel.org Reported-by: kernel test robot Reviewed-by: Kees Cook Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman commit 755971dc7ee84fb5d0b6373aa9537c4f62b9e0b4 Author: Anand Jain Date: Sun Jul 4 19:14:39 2021 +0800 btrfs: check for missing device in btrfs_trim_fs commit 16a200f66ede3f9afa2e51d90ade017aaa18d213 upstream. A fstrim on a degraded raid1 can trigger the following null pointer dereference: BTRFS info (device loop0): allowing degraded mounts BTRFS info (device loop0): disk space caching is enabled BTRFS info (device loop0): has skinny extents BTRFS warning (device loop0): devid 2 uuid 97ac16f7-e14d-4db1-95bc-3d489b424adb is missing BTRFS warning (device loop0): devid 2 uuid 97ac16f7-e14d-4db1-95bc-3d489b424adb is missing BTRFS info (device loop0): enabling ssd optimizations BUG: kernel NULL pointer dereference, address: 0000000000000620 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 4574 Comm: fstrim Not tainted 5.13.0-rc7+ #31 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 RIP: 0010:btrfs_trim_fs+0x199/0x4a0 [btrfs] RSP: 0018:ffff959541797d28 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff946f84eca508 RCX: a7a67937adff8608 RDX: ffff946e8122d000 RSI: 0000000000000000 RDI: ffffffffc02fdbf0 RBP: ffff946ea4615000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: ffff946e8122d960 R12: 0000000000000000 R13: ffff959541797db8 R14: ffff946e8122d000 R15: ffff959541797db8 FS: 00007f55917a5080(0000) GS:ffff946f9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000620 CR3: 000000002d2c8001 CR4: 00000000000706f0 Call Trace: btrfs_ioctl_fitrim+0x167/0x260 [btrfs] btrfs_ioctl+0x1c00/0x2fe0 [btrfs] ? selinux_file_ioctl+0x140/0x240 ? syscall_trace_enter.constprop.0+0x188/0x240 ? __x64_sys_ioctl+0x83/0xb0 __x64_sys_ioctl+0x83/0xb0 Reproducer: $ mkfs.btrfs -fq -d raid1 -m raid1 /dev/loop0 /dev/loop1 $ mount /dev/loop0 /btrfs $ umount /btrfs $ btrfs dev scan --forget $ mount -o degraded /dev/loop0 /btrfs $ fstrim /btrfs The reason is we call btrfs_trim_free_extents() for the missing device, which uses device->bdev (NULL for missing device) to find if the device supports discard. Fix is to check if the device is missing before calling btrfs_trim_free_extents(). CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Filipe Manana Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 552b053f1a530c9b8b4b93af7fd3cde374343672 Author: Steven Rostedt (VMware) Date: Wed Jul 21 19:10:08 2021 -0400 tracing: Synthetic event field_pos is an index not a boolean commit 3b13911a2fd0dd0146c9777a254840c5466cf120 upstream. Performing the following: ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\ > events/sched/sched_switch/trigger ># echo 1 > events/synthetic/enable Crashed the kernel: BUG: kernel NULL pointer dereference, address: 000000000000001b #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ #104 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strlen+0x0/0x20 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 9 f8 c3 31 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018 FS: 0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0 Call Trace: trace_event_raw_event_synth+0x90/0x1d0 action_trace+0x5b/0x70 event_hist_trigger+0x4bd/0x4e0 ? cpumask_next_and+0x20/0x30 ? update_sd_lb_stats.constprop.0+0xf6/0x840 ? __lock_acquire.constprop.0+0x125/0x550 ? find_held_lock+0x32/0x90 ? sched_clock_cpu+0xe/0xd0 ? lock_release+0x155/0x440 ? update_load_avg+0x8c/0x6f0 ? enqueue_entity+0x18a/0x920 ? __rb_reserve_next+0xe5/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x1ae/0x240 trace_event_raw_event_sched_switch+0x114/0x170 __traceiter_sched_switch+0x39/0x50 __schedule+0x431/0xb00 schedule_idle+0x28/0x40 do_idle+0x198/0x2e0 cpu_startup_entry+0x19/0x20 secondary_startup_64_no_verify+0xc2/0xcb The reason is that the dynamic events array keeps track of the field position of the fields array, via the field_pos variable in the synth_field structure. Unfortunately, that field is a boolean for some reason, which means any field_pos greater than 1 will be a bug (in this case it was 2). Link: https://lkml.kernel.org/r/20210721191008.638bce34@oasis.local.home Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Ingo Molnar Cc: Andrew Morton Cc: stable@vger.kernel.org Fixes: bd82631d7ccdc ("tracing: Add support for dynamic strings to synthetic events") Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 757bdba8026be19b4f447487695cd0349a648d9e Author: Haoran Luo Date: Wed Jul 21 14:12:07 2021 +0000 tracing: Fix bug in rb_per_cpu_empty() that might cause deadloop. commit 67f0d6d9883c13174669f88adac4f0ee656cc16a upstream. The "rb_per_cpu_empty()" misinterpret the condition (as not-empty) when "head_page" and "commit_page" of "struct ring_buffer_per_cpu" points to the same buffer page, whose "buffer_data_page" is empty and "read" field is non-zero. An error scenario could be constructed as followed (kernel perspective): 1. All pages in the buffer has been accessed by reader(s) so that all of them will have non-zero "read" field. 2. Read and clear all buffer pages so that "rb_num_of_entries()" will return 0 rendering there's no more data to read. It is also required that the "read_page", "commit_page" and "tail_page" points to the same page, while "head_page" is the next page of them. 3. Invoke "ring_buffer_lock_reserve()" with large enough "length" so that it shot pass the end of current tail buffer page. Now the "head_page", "commit_page" and "tail_page" points to the same page. 4. Discard current event with "ring_buffer_discard_commit()", so that "head_page", "commit_page" and "tail_page" points to a page whose buffer data page is now empty. When the error scenario has been constructed, "tracing_read_pipe" will be trapped inside a deadloop: "trace_empty()" returns 0 since "rb_per_cpu_empty()" returns 0 when it hits the CPU containing such constructed ring buffer. Then "trace_find_next_entry_inc()" always return NULL since "rb_num_of_entries()" reports there's no more entry to read. Finally "trace_seq_to_user()" returns "-EBUSY" spanking "tracing_read_pipe" back to the start of the "waitagain" loop. I've also written a proof-of-concept script to construct the scenario and trigger the bug automatically, you can use it to trace and validate my reasoning above: https://github.com/aegistudio/RingBufferDetonator.git Tests has been carried out on linux kernel 5.14-rc2 (2734d6c1b1a089fb593ef6a23d4b70903526fe0c), my fixed version of kernel (for testing whether my update fixes the bug) and some older kernels (for range of affected kernels). Test result is also attached to the proof-of-concept repository. Link: https://lore.kernel.org/linux-trace-devel/YPaNxsIlb2yjSi5Y@aegistudio/ Link: https://lore.kernel.org/linux-trace-devel/YPgrN85WL9VyrZ55@aegistudio Cc: stable@vger.kernel.org Fixes: bf41a158cacba ("ring-buffer: make reentrant") Suggested-by: Linus Torvalds Signed-off-by: Haoran Luo Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit a5e1aff58943f9337e7f1f90126b1db7859f1a4b Author: Steven Rostedt (VMware) Date: Wed Jul 21 11:00:53 2021 -0400 tracing/histogram: Rename "cpu" to "common_cpu" commit 1e3bac71c5053c99d438771fc9fa5082ae5d90aa upstream. Currently the histogram logic allows the user to write "cpu" in as an event field, and it will record the CPU that the event happened on. The problem with this is that there's a lot of events that have "cpu" as a real field, and using "cpu" as the CPU it ran on, makes it impossible to run histograms on the "cpu" field of events. For example, if I want to have a histogram on the count of the workqueue_queue_work event on its cpu field, running: ># echo 'hist:keys=cpu' > events/workqueue/workqueue_queue_work/trigger Gives a misleading and wrong result. Change the command to "common_cpu" as no event should have "common_*" fields as that's a reserved name for fields used by all events. And this makes sense here as common_cpu would be a field used by all events. Now we can even do: ># echo 'hist:keys=common_cpu,cpu if cpu < 100' > events/workqueue/workqueue_queue_work/trigger ># cat events/workqueue/workqueue_queue_work/hist # event histogram # # trigger info: hist:keys=common_cpu,cpu:vals=hitcount:sort=hitcount:size=2048 if cpu < 100 [active] # { common_cpu: 0, cpu: 2 } hitcount: 1 { common_cpu: 0, cpu: 4 } hitcount: 1 { common_cpu: 7, cpu: 7 } hitcount: 1 { common_cpu: 0, cpu: 7 } hitcount: 1 { common_cpu: 0, cpu: 1 } hitcount: 1 { common_cpu: 0, cpu: 6 } hitcount: 2 { common_cpu: 0, cpu: 5 } hitcount: 2 { common_cpu: 1, cpu: 1 } hitcount: 4 { common_cpu: 6, cpu: 6 } hitcount: 4 { common_cpu: 5, cpu: 5 } hitcount: 14 { common_cpu: 4, cpu: 4 } hitcount: 26 { common_cpu: 0, cpu: 0 } hitcount: 39 { common_cpu: 2, cpu: 2 } hitcount: 184 Now for backward compatibility, I added a trick. If "cpu" is used, and the field is not found, it will fall back to "common_cpu" and work as it did before. This way, it will still work for old programs that use "cpu" to get the actual CPU, but if the event has a "cpu" as a field, it will get that event's "cpu" field, which is probably what it wants anyway. I updated the tracefs/README to include documentation about both the common_timestamp and the common_cpu. This way, if that text is present in the README, then an application can know that common_cpu is supported over just plain "cpu". Link: https://lkml.kernel.org/r/20210721110053.26b4f641@oasis.local.home Cc: Namhyung Kim Cc: Ingo Molnar Cc: Andrew Morton Cc: stable@vger.kernel.org Fixes: 8b7622bf94a44 ("tracing: Add cpu field for hist triggers") Reviewed-by: Tom Zanussi Reviewed-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 0edad8b9f65d93fb3578246fe61c4c0cb2c474a9 Author: Steven Rostedt (VMware) Date: Thu Jul 22 21:52:18 2021 -0400 tracepoints: Update static_call before tp_funcs when adding a tracepoint commit 352384d5c84ebe40fa77098cc234fe173247d8ef upstream. Because of the significant overhead that retpolines pose on indirect calls, the tracepoint code was updated to use the new "static_calls" that can modify the running code to directly call a function instead of using an indirect caller, and this function can be changed at runtime. In the tracepoint code that calls all the registered callbacks that are attached to a tracepoint, the following is done: it_func_ptr = rcu_dereference_raw((&__tracepoint_##name)->funcs); if (it_func_ptr) { __data = (it_func_ptr)->data; static_call(tp_func_##name)(__data, args); } If there's just a single callback, the static_call is updated to just call that callback directly. Once another handler is added, then the static caller is updated to call the iterator, that simply loops over all the funcs in the array and calls each of the callbacks like the old method using indirect calling. The issue was discovered with a race between updating the funcs array and updating the static_call. The funcs array was updated first and then the static_call was updated. This is not an issue as long as the first element in the old array is the same as the first element in the new array. But that assumption is incorrect, because callbacks also have a priority field, and if there's a callback added that has a higher priority than the callback on the old array, then it will become the first callback in the new array. This means that it is possible to call the old callback with the new callback data element, which can cause a kernel panic. static_call = callback1() funcs[] = {callback1,data1}; callback2 has higher priority than callback1 CPU 1 CPU 2 ----- ----- new_funcs = {callback2,data2}, {callback1,data1} rcu_assign_pointer(tp->funcs, new_funcs); /* * Now tp->funcs has the new array * but the static_call still calls callback1 */ it_func_ptr = tp->funcs [ new_funcs ] data = it_func_ptr->data [ data2 ] static_call(callback1, data); /* Now callback1 is called with * callback2's data */ [ KERNEL PANIC ] update_static_call(iterator); To prevent this from happening, always switch the static_call to the iterator before assigning the tp->funcs to the new array. The iterator will always properly match the callback with its data. To trigger this bug: In one terminal: while :; do hackbench 50; done In another terminal echo 1 > /sys/kernel/tracing/events/sched/sched_waking/enable while :; do echo 1 > /sys/kernel/tracing/set_event_pid; sleep 0.5 echo 0 > /sys/kernel/tracing/set_event_pid; sleep 0.5 done And it doesn't take long to crash. This is because the set_event_pid adds a callback to the sched_waking tracepoint with a high priority, which will be called before the sched_waking trace event callback is called. Note, the removal to a single callback updates the array first, before changing the static_call to single callback, which is the proper order as the first element in the array is the same as what the static_call is being changed to. Link: https://lore.kernel.org/io-uring/4ebea8f0-58c9-e571-fd30-0ce4f6f09c70@samba.org/ Cc: stable@vger.kernel.org Fixes: d25e37d89dd2f ("tracepoint: Optimize using static_call()") Reported-by: Stefan Metzmacher tested-by: Stefan Metzmacher Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 4ed4074c6c6c1498b0d7f3b95a0104e57a6ecc63 Author: Marc Zyngier Date: Tue Jul 13 19:43:26 2021 +0100 firmware/efi: Tell memblock about EFI iomem reservations commit 2bab693a608bdf614b9fcd44083c5100f34b9f77 upstream. kexec_load_file() relies on the memblock infrastructure to avoid stamping over regions of memory that are essential to the survival of the system. However, nobody seems to agree how to flag these regions as reserved, and (for example) EFI only publishes its reservations in /proc/iomem for the benefit of the traditional, userspace based kexec tool. On arm64 platforms with GICv3, this can result in the payload being placed at the location of the LPI tables. Shock, horror! Let's augment the EFI reservation code with a memblock_reserve() call, protecting our dear tables from the secondary kernel invasion. Reported-by: Moritz Fischer Tested-by: Moritz Fischer Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Cc: Ard Biesheuvel Cc: James Morse Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 647e26b03ee9a641e7dd246e8a7925730c3e8683 Author: Amelie Delaunay Date: Fri Jul 16 14:07:17 2021 +0200 usb: typec: stusb160x: register role switch before interrupt registration commit 86762ad4abcc549deb7a155c8e5e961b9755bcf0 upstream. During interrupt registration, attach state is checked. If attached, then the Type-C state is updated with typec_set_xxx functions and role switch is set with usb_role_switch_set_role(). If the usb_role_switch parameter is error or null, the function simply returns 0. So, to update usb_role_switch role if a device is attached before the irq is registered, usb_role_switch must be registered before irq registration. Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family") Cc: stable Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20210716120718.20398-2-amelie.delaunay@foss.st.com Signed-off-by: Greg Kroah-Hartman commit a206167bd63863b0544e7c36e64d5323fb5e9ee8 Author: Minas Harutyunyan Date: Tue Jul 20 05:41:24 2021 -0700 usb: dwc2: gadget: Fix sending zero length packet in DDMA mode. commit d53dc38857f6dbefabd9eecfcbf67b6eac9a1ef4 upstream. Sending zero length packet in DDMA mode perform by DMA descriptor by setting SP (short packet) flag. For DDMA in function dwc2_hsotg_complete_in() does not need to send zlp. Tested by USBCV MSC tests. Fixes: f71b5e2533de ("usb: dwc2: gadget: fix zero length packet transfers") Cc: stable Signed-off-by: Minas Harutyunyan Link: https://lore.kernel.org/r/967bad78c55dd2db1c19714eee3d0a17cf99d74a.1626777738.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman commit f2c04f6b21ef94c67202a2a2e257c5e35a7bc375 Author: Minas Harutyunyan Date: Tue Jul 13 09:32:55 2021 +0400 usb: dwc2: gadget: Fix GOUTNAK flow for Slave mode. commit fecb3a171db425e5068b27231f8efe154bf72637 upstream. Because of dwc2_hsotg_ep_stop_xfr() function uses poll mode, first need to mask GINTSTS_GOUTNAKEFF interrupt. In Slave mode GINTSTS_GOUTNAKEFF interrupt will be aserted only after pop OUT NAK status packet from RxFIFO. In dwc2_hsotg_ep_sethalt() function before setting DCTL_SGOUTNAK need to unmask GOUTNAKEFF interrupt. Tested by USBCV CH9 and MSC tests set in Slave, BDMA and DDMA. All tests are passed. Fixes: a4f827714539a ("usb: dwc2: gadget: Disable enabled HW endpoint in dwc2_hsotg_ep_disable") Fixes: 6070636c4918c ("usb: dwc2: Fix Stalling a Non-Isochronous OUT EP") Cc: stable Signed-off-by: Minas Harutyunyan Link: https://lore.kernel.org/r/e17fad802bbcaf879e1ed6745030993abb93baf8.1626152924.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 7073acb51a3b4c8d74bf317cd6a860f57fac659b Author: Zhang Qilong Date: Fri Jun 18 22:14:41 2021 +0800 usb: gadget: Fix Unbalanced pm_runtime_enable in tegra_xudc_probe commit 5b01248156bd75303e66985c351dee648c149979 upstream. Add missing pm_runtime_disable() when probe error out. It could avoid pm_runtime implementation complains when removing and probing again the driver. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") Cc: stable Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20210618141441.107817-1-zhangqilong3@huawei.com Signed-off-by: Greg Kroah-Hartman commit 1bf7371b90046114d589c2328ae016886aa947db Author: John Keeping Date: Wed Jul 21 17:17:45 2021 +0100 USB: serial: cp210x: add ID for CEL EM3588 USB ZigBee stick commit d6a206e60124a9759dd7f6dfb86b0e1d3b1df82e upstream. Add the USB serial device ID for the CEL ZigBee EM3588 radio stick. Signed-off-by: John Keeping Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 45c87a94336f4d551a13bca4609d278134149c80 Author: Ian Ray Date: Mon Jul 19 18:43:49 2021 +0200 USB: serial: cp210x: fix comments for GE CS1000 commit e9db418d4b828dd049caaf5ed65dc86f93bb1a0c upstream. Fix comments for GE CS1000 CP210x USB ID assignments. Fixes: 42213a0190b5 ("USB: serial: cp210x: add some more GE USB IDs") Signed-off-by: Ian Ray Signed-off-by: Sebastian Reichel Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f528521c157460fe73d5b604c62bb77b22cf5f62 Author: Marco De Marco Date: Mon Jul 5 19:44:21 2021 +0000 USB: serial: option: add support for u-blox LARA-R6 family commit 94b619a07655805a1622484967754f5848640456 upstream. The patch is meant to support LARA-R6 Cat 1 module family. Module USB ID: Vendor ID: 0x05c6 Product ID: 0x90fA Interface layout: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: QMI wwan (not available in all versions) Signed-off-by: Marco De Marco Link: https://lore.kernel.org/r/49260184.kfMIbaSn9k@mars Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 311fd7f7f18683da90953a3315ab2035d87c0ad1 Author: Yoshihiro Shimoda Date: Thu Jun 24 21:20:39 2021 +0900 usb: renesas_usbhs: Fix superfluous irqs happen after usb_pkt_pop() commit 5719df243e118fb343725e8b2afb1637e1af1373 upstream. This driver has a potential issue which this driver is possible to cause superfluous irqs after usb_pkt_pop() is called. So, after the commit 3af32605289e ("usb: renesas_usbhs: fix error return code of usbhsf_pkt_handler()") had been applied, we could observe the following error happened when we used g_audio. renesas_usbhs e6590000.usb: irq_ready run_error 1 : -22 To fix the issue, disable the tx or rx interrupt in usb_pkt_pop(). Fixes: 2743e7f90dc0 ("usb: renesas_usbhs: fix the usb_pkt_pop()") Cc: # v4.4+ Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20210624122039.596528-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman commit 7af54a4e221e5619a87714567e2258445dc35435 Author: Mark Tomlinson Date: Fri Jun 25 15:14:56 2021 +1200 usb: max-3421: Prevent corruption of freed memory commit b5fdf5c6e6bee35837e160c00ac89327bdad031b upstream. The MAX-3421 USB driver remembers the state of the USB toggles for a device/endpoint. To save SPI writes, this was only done when a new device/endpoint was being used. Unfortunately, if the old device was removed, this would cause writes to freed memory. To fix this, a simpler scheme is used. The toggles are read from hardware when a URB is completed, and the toggles are always written to hardware when any URB transaction is started. This will cause a few more SPI transactions, but no causes kernel panics. Fixes: 2d53139f3162 ("Add support for using a MAX3421E chip as a host driver.") Cc: stable Signed-off-by: Mark Tomlinson Link: https://lore.kernel.org/r/20210625031456.8632-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Greg Kroah-Hartman commit 69da81a964427b9dd9008a57a2fa0b857e40526b Author: Julian Sikorski Date: Tue Jul 20 19:19:10 2021 +0200 USB: usb-storage: Add LaCie Rugged USB3-FW to IGNORE_UAS commit 6abf2fe6b4bf6e5256b80c5817908151d2d33e9f upstream. LaCie Rugged USB3-FW appears to be incompatible with UAS. It generates errors like: [ 1151.582598] sd 14:0:0:0: tag#16 uas_eh_abort_handler 0 uas-tag 1 inflight: IN [ 1151.582602] sd 14:0:0:0: tag#16 CDB: Report supported operation codes a3 0c 01 12 00 00 00 00 02 00 00 00 [ 1151.588594] scsi host14: uas_eh_device_reset_handler start [ 1151.710482] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [ 1151.741398] scsi host14: uas_eh_device_reset_handler success [ 1181.785534] scsi host14: uas_eh_device_reset_handler start Signed-off-by: Julian Sikorski Cc: stable Link: https://lore.kernel.org/r/20210720171910.36497-1-belegdol+github@gmail.com Signed-off-by: Greg Kroah-Hartman commit e6343aab3ee728c7467d0ecf59cbd769c0a285e2 Author: Mathias Nyman Date: Thu Jul 15 18:01:21 2021 +0300 usb: hub: Fix link power management max exit latency (MEL) calculations commit 1bf2761c837571a66ec290fb66c90413821ffda2 upstream. Maximum Exit Latency (MEL) value is used by host to know how much in advance it needs to start waking up a U1/U2 suspended link in order to service a periodic transfer in time. Current MEL calculation only includes the time to wake up the path from U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2 Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include: - tMEL2 which is the time it takes for PING message to reach device - tMEL3 time for device to process the PING and submit a PING_RESPONSE - tMEL4 time for PING_RESPONSE to traverse back upstream to host. Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation. Cc: # v3.5 Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8f087b4cf1a359a29a4fe8b2e0f02e37793c8b25 Author: Mathias Nyman Date: Thu Jul 15 18:01:22 2021 +0300 usb: hub: Disable USB 3 device initiated lpm if exit latency is too high commit 1b7f56fbc7a1b66967b6114d1b5f5a257c3abae6 upstream. The device initiated link power management U1/U2 states should not be enabled in case the system exit latency plus one bus interval (125us) is greater than the shortest service interval of any periodic endpoint. This is the case for both U1 and U2 sytstem exit latencies and link states. See USB 3.2 section 9.4.9 "Set Feature" for more details Note, before this patch the host and device initiated U1/U2 lpm states were both enabled with lpm. After this patch it's possible to end up with only host inititated U1/U2 lpm in case the exit latencies won't allow device initiated lpm. If this case we still want to set the udev->usb3_lpm_ux_enabled flag so that sysfs users can see the link may go to U1/U2. Signed-off-by: Mathias Nyman Cc: stable Link: https://lore.kernel.org/r/20210715150122.1995966-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 709137c853277e41f9fdac941d58ae5aa8aabf3a Author: Nicholas Piggin Date: Thu Jul 8 21:26:22 2021 +1000 KVM: PPC: Book3S HV Nested: Sanitise H_ENTER_NESTED TM state commit d9c57d3ed52a92536f5fa59dc5ccdd58b4875076 upstream. The H_ENTER_NESTED hypercall is handled by the L0, and it is a request by the L1 to switch the context of the vCPU over to that of its L2 guest, and return with an interrupt indication. The L1 is responsible for switching some registers to guest context, and the L0 switches others (including all the hypervisor privileged state). If the L2 MSR has TM active, then the L1 is responsible for recheckpointing the L2 TM state. Then the L1 exits to L0 via the H_ENTER_NESTED hcall, and the L0 saves the TM state as part of the exit, and then it recheckpoints the TM state as part of the nested entry and finally HRFIDs into the L2 with TM active MSR. Not efficient, but about the simplest approach for something that's horrendously complicated. Problems arise if the L1 exits to the L0 with a TM state which does not match the L2 TM state being requested. For example if the L1 is transactional but the L2 MSR is non-transactional, or vice versa. The L0's HRFID can take a TM Bad Thing interrupt and crash. Fix this by disallowing H_ENTER_NESTED in TM[T] state entirely, and then ensuring that if the L1 is suspended then the L2 must have TM active, and if the L1 is not suspended then the L2 must not have TM active. Fixes: 360cae313702 ("KVM: PPC: Book3S HV: Nested guest entry via hypercall") Cc: stable@vger.kernel.org # v4.20+ Reported-by: Alexey Kardashevskiy Acked-by: Michael Neuling Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit c1fbdf0f3c26004a2803282fdc1c35086908a99e Author: Nicholas Piggin Date: Tue Jul 20 20:43:09 2021 +1000 KVM: PPC: Book3S: Fix H_RTAS rets buffer overflow commit f62f3c20647ebd5fb6ecb8f0b477b9281c44c10a upstream. The kvmppc_rtas_hcall() sets the host rtas_args.rets pointer based on the rtas_args.nargs that was provided by the guest. That guest nargs value is not range checked, so the guest can cause the host rets pointer to be pointed outside the args array. The individual rtas function handlers check the nargs and nrets values to ensure they are correct, but if they are not, the handlers store a -3 (0xfffffffd) failure indication in rets[0] which corrupts host memory. Fix this by testing up front whether the guest supplied nargs and nret would exceed the array size, and fail the hcall directly without storing a failure indication to rets[0]. Also expand on a comment about why we kill the guest and try not to return errors directly if we have a valid rets[0] pointer. Fixes: 8e591cb72047 ("KVM: PPC: Book3S: Add infrastructure to implement kernel-side RTAS calls") Cc: stable@vger.kernel.org # v3.10+ Reported-by: Alexey Kardashevskiy Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit e3eb672c169d3b3b636a12df7e260f3cada07b81 Author: Mathias Nyman Date: Thu Jul 15 18:06:51 2021 +0300 xhci: Fix lost USB 2 remote wake commit 72f68bf5c756f5ce1139b31daae2684501383ad5 upstream. There's a small window where a USB 2 remote wake may be left unhandled due to a race between hub thread and xhci port event interrupt handler. When the resume event is detected in the xhci interrupt handler it kicks the hub timer, which should move the port from resume to U0 once resume has been signalled for long enough. To keep the hub "thread" running we set a bus_state->resuming_ports flag. This flag makes sure hub timer function kicks itself. checking this flag was not properly protected by the spinlock. Flag was copied to a local variable before lock was taken. The local variable was then checked later with spinlock held. If interrupt is handled right after copying the flag to the local variable we end up stopping the hub thread before it can handle the USB 2 resume. CPU0 CPU1 (hub thread) (xhci event handler) xhci_hub_status_data() status = bus_state->resuming_ports; handle_port_status() spin_lock() bus_state->resuming_ports = 1 set_flag(HCD_FLAG_POLL_RH) spin_unlock() spin_lock() if (!status) clear_flag(HCD_FLAG_POLL_RH) spin_unlock() Fix this by taking the lock a bit earlier so that it covers the resuming_ports flag copy in the hub thread Cc: Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210715150651.1996099-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 02e2e96ba56c08e2a7fdade623145f571228a88d Author: Greg Thelen Date: Fri Jul 2 00:12:24 2021 -0700 usb: xhci: avoid renesas_usb_fw.mem when it's unusable commit 0665e387318607d8269bfdea60723c627c8bae43 upstream. Commit a66d21d7dba8 ("usb: xhci: Add support for Renesas controller with memory") added renesas_usb_fw.mem firmware reference to xhci-pci. Thus modinfo indicates xhci-pci.ko has "firmware: renesas_usb_fw.mem". But the firmware is only actually used with CONFIG_USB_XHCI_PCI_RENESAS. An unusable firmware reference can trigger safety checkers which look for drivers with unmet firmware dependencies. Avoid referring to renesas_usb_fw.mem in circumstances when it cannot be loaded (when CONFIG_USB_XHCI_PCI_RENESAS isn't set). Fixes: a66d21d7dba8 ("usb: xhci: Add support for Renesas controller with memory") Cc: stable Signed-off-by: Greg Thelen Link: https://lore.kernel.org/r/20210702071224.3673568-1-gthelen@google.com Signed-off-by: Greg Kroah-Hartman commit 9e9cf23b77d41d1d9b69c1a93f20b6de9ce9ea9a Author: Moritz Fischer Date: Mon Jul 19 00:05:19 2021 -0700 Revert "usb: renesas-xhci: Fix handling of unknown ROM state" commit 44cf53602f5a0db80d53c8fff6cdbcae59650a42 upstream. This reverts commit d143825baf15f204dac60acdf95e428182aa3374. Justin reports some of his systems now fail as result of this commit: xhci_hcd 0000:04:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2 xhci_hcd 0000:04:00.0: request_firmware failed: -2 xhci_hcd: probe of 0000:04:00.0 failed with error -2 The revert brings back the original issue the commit tried to solve but at least unbreaks existing systems relying on previous behavior. Cc: stable@vger.kernel.org Cc: Mathias Nyman Cc: Vinod Koul Cc: Justin Forbes Reported-by: Justin Forbes Signed-off-by: Moritz Fischer Fixes: d143825baf15 ("usb: renesas-xhci: Fix handling of unknown ROM state") Link: https://lore.kernel.org/r/20210719070519.41114-1-mdf@kernel.org Signed-off-by: Greg Kroah-Hartman commit ebaa67086fae3faf402028f9957e8d15ee8f95ba Author: Takashi Iwai Date: Tue Jul 20 11:26:40 2021 +0200 ALSA: pcm: Fix mmap capability check commit c4824ae7db418aee6f50f308a20b832e58e997fd upstream. The hw_support_mmap() doesn't cover all memory allocation types and might use a wrong device pointer for checking the capability. Check the all memory allocation types more completely. Cc: Link: https://lore.kernel.org/r/20210720092640.12338-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 431e31105579f22c778d02cfcb3b23bd28d69d32 Author: Alan Young Date: Fri Jul 9 09:48:54 2021 +0100 ALSA: pcm: Call substream ack() method upon compat mmap commit commit 2e2832562c877e6530b8480982d99a4ff90c6777 upstream. If a 32-bit application is being used with a 64-bit kernel and is using the mmap mechanism to write data, then the SNDRV_PCM_IOCTL_SYNC_PTR ioctl results in calling snd_pcm_ioctl_sync_ptr_compat(). Make this use pcm_lib_apply_appl_ptr() so that the substream's ack() method, if defined, is called. The snd_pcm_sync_ptr() function, used in the 64-bit ioctl case, already uses snd_pcm_ioctl_sync_ptr_compat(). Fixes: 9027c4639ef1 ("ALSA: pcm: Call ack() whenever appl_ptr is updated") Signed-off-by: Alan Young Cc: Link: https://lore.kernel.org/r/c441f18c-eb2a-3bdd-299a-696ccca2de9c@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3c9afa23f3fc6da6d88ef0f514de612d871337c2 Author: Takashi Iwai Date: Fri Jul 16 15:56:00 2021 +0200 ALSA: hdmi: Expose all pins on MSI MS-7C94 board commit 33f735f137c6539e3ceceb515cd1e2a644005b49 upstream. The BIOS on MSI Mortar B550m WiFi (MS-7C94) board with AMDGPU seems disabling the other pins than HDMI although it has more outputs including DP. This patch adds the board to the allow list for enabling all pins. Reported-by: Damjan Georgievski Cc: Link: https://lore.kernel.org/r/CAEk1YH4Jd0a8vfZxORVu7qg+Zsc-K+pR187ezNq8QhJBPW4gpw@mail.gmail.com Link: https://lore.kernel.org/r/20210716135600.24176-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 253759df808272efcf33acfeaaae3557255d14b1 Author: Hui Wang Date: Mon Jul 19 11:02:31 2021 +0800 ALSA: hda/realtek: Fix pop noise and 2 Front Mic issues on a machine commit e4efa82660e6d80338c554e45e903714e1b2c27b upstream. This is a Lenovo ThinkStation machine which uses the codec alc623. There are 2 issues on this machine, the 1st one is the pop noise in the lineout, the 2nd one is there are 2 Front Mics and pulseaudio can't handle them, After applying the fixup of ALC623_FIXUP_LENOVO_THINKSTATION_P340 to this machine, the 2 issues are fixed. Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210719030231.6870-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2b3cdf581993de19d8e03353b4d90a0d604d07a5 Author: Takashi Iwai Date: Fri Jul 16 15:27:23 2021 +0200 ALSA: sb: Fix potential ABBA deadlock in CSP driver commit 1c2b9519159b470ef24b2638f4794e86e2952ab7 upstream. SB16 CSP driver may hit potentially a typical ABBA deadlock in two code paths: In snd_sb_csp_stop(): spin_lock_irqsave(&p->chip->mixer_lock, flags); spin_lock(&p->chip->reg_lock); In snd_sb_csp_load(): spin_lock_irqsave(&p->chip->reg_lock, flags); spin_lock(&p->chip->mixer_lock); Also the similar pattern is seen in snd_sb_csp_start(). Although the practical impact is very small (those states aren't triggered in the same running state and this happens only on a real hardware, decades old ISA sound boards -- which must be very difficult to find nowadays), it's a real scenario and has to be fixed. This patch addresses those deadlocks by splitting the locks in snd_sb_csp_start() and snd_sb_csp_stop() for avoiding the nested locks. Reported-by: Jia-Ju Bai Cc: Link: https://lore.kernel.org/r/7b0fcdaf-cd4f-4728-2eae-48c151a92e10@gmail.com Link: https://lore.kernel.org/r/20210716132723.13216-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5858c8a464219e6b7424ddaee204575bff478593 Author: Alexander Tsoy Date: Thu Jul 22 02:56:05 2021 +0300 ALSA: usb-audio: Add registration quirk for JBL Quantum headsets commit b0084afde27fe8a504377dee65f55bc6aa776937 upstream. These devices has two interfaces, but only the second interface contains the capture endpoint, thus quirk is required to delay the registration until the second interface appears. Tested-by: Jakub Fišer Signed-off-by: Alexander Tsoy Cc: Link: https://lore.kernel.org/r/20210721235605.53741-1-alexander@tsoy.me Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2de518548de182d341dc1e7e660065369d5d0cb4 Author: Takashi Iwai Date: Wed Jul 14 10:48:36 2021 +0200 ALSA: usb-audio: Add missing proc text entry for BESPOKEN type commit 64752a95b702817602d72f109ceaf5ec0780e283 upstream. Recently we've added a new usb_mixer element type, USB_MIXER_BESPOKEN, but it wasn't added in the table in snd_usb_mixer_dump_cval(). This is no big problem since each bespoken type should have its own dump method, but it still isn't disallowed to use the standard one, so we should cover it as well. Along with it, define the table with the explicit array initializer for avoiding other pitfalls. Fixes: 785b6f29a795 ("ALSA: usb-audio: scarlett2: Fix wrong resume call") Reported-by: Pavel Machek Cc: Link: https://lore.kernel.org/r/20210714084836.1977-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 37a88b41dc29438e406e4a40ef7e3159a5139e30 Author: Alexander Egorenkov Date: Fri Jul 16 22:00:22 2021 +0200 s390/boot: fix use of expolines in the DMA code commit 463f36c76fa4ec015c640ff63ccf52e7527abee0 upstream. The DMA code section of the decompressor must be compiled with expolines if Spectre V2 mitigation has been enabled for the decompressed kernel. This is required because although the decompressor's image contains the DMA code section, it is handed over to the decompressed kernel for use. Because the DMA code is already slow w/o expolines, use expolines always regardless whether the decompressed kernel is using them or not. This simplifies the DMA code by dropping the conditional compilation of expolines. Fixes: bf72630130c2 ("s390: use proper expoline sections for .dma code") Cc: # 5.2 Signed-off-by: Alexander Egorenkov Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit d1ab96288061dd8238a2b51ce385fe76c943dced Author: Vasily Gorbik Date: Fri Jun 25 23:50:07 2021 +0200 s390/ftrace: fix ftrace_update_ftrace_func implementation commit f8c2602733c953ed7a16e060640b8e96f9d94b9b upstream. s390 enforces DYNAMIC_FTRACE if FUNCTION_TRACER is selected. At the same time implementation of ftrace_caller is not compliant with HAVE_DYNAMIC_FTRACE since it doesn't provide implementation of ftrace_update_ftrace_func() and calls ftrace_trace_function() directly. The subtle difference is that during ftrace code patching ftrace replaces function tracer via ftrace_update_ftrace_func() and activates it back afterwards. Unexpected direct calls to ftrace_trace_function() during ftrace code patching leads to nullptr-dereferences when tracing is activated for one of functions which are used during code patching. Those function currently are: copy_from_kernel_nofault() copy_from_kernel_nofault_allowed() preempt_count_sub() [with debug_defconfig] preempt_count_add() [with debug_defconfig] Corresponding KASAN report: BUG: KASAN: nullptr-dereference in function_trace_call+0x316/0x3b0 Read of size 4 at addr 0000000000001e08 by task migration/0/15 CPU: 0 PID: 15 Comm: migration/0 Tainted: G B 5.13.0-41423-g08316af3644d Hardware name: IBM 3906 M04 704 (LPAR) Stopper: multi_cpu_stop+0x0/0x3e0 <- stop_machine_cpuslocked+0x1e4/0x218 Call Trace: [<0000000001f77caa>] show_stack+0x16a/0x1d0 [<0000000001f8de42>] dump_stack+0x15a/0x1b0 [<0000000001f81d56>] print_address_description.constprop.0+0x66/0x2e0 [<000000000082b0ca>] kasan_report+0x152/0x1c0 [<00000000004cfd8e>] function_trace_call+0x316/0x3b0 [<0000000001fb7082>] ftrace_caller+0x7a/0x7e [<00000000006bb3e6>] copy_from_kernel_nofault_allowed+0x6/0x10 [<00000000006bb42e>] copy_from_kernel_nofault+0x3e/0xd0 [<000000000014605c>] ftrace_make_call+0xb4/0x1f8 [<000000000047a1b4>] ftrace_replace_code+0x134/0x1d8 [<000000000047a6e0>] ftrace_modify_all_code+0x120/0x1d0 [<000000000047a7ec>] __ftrace_modify_code+0x5c/0x78 [<000000000042395c>] multi_cpu_stop+0x224/0x3e0 [<0000000000423212>] cpu_stopper_thread+0x33a/0x5a0 [<0000000000243ff2>] smpboot_thread_fn+0x302/0x708 [<00000000002329ea>] kthread+0x342/0x408 [<00000000001066b2>] __ret_from_fork+0x92/0xf0 [<0000000001fb57fa>] ret_from_fork+0xa/0x30 The buggy address belongs to the page: page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1 flags: 0x1ffff00000001000(reserved|node=0|zone=0|lastcpupid=0x1ffff) raw: 1ffff00000001000 0000040000000048 0000040000000048 0000000000000000 raw: 0000000000000000 0000000000000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 0000000000001d00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 0000000000001d80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 >0000000000001e00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 ^ 0000000000001e80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 0000000000001f00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 ================================================================== To fix that introduce ftrace_func callback to be called from ftrace_caller and update it in ftrace_update_ftrace_func(). Fixes: 4cc9bed034d1 ("[S390] cleanup ftrace backend functions") Cc: stable@vger.kernel.org Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 3b4009b496344c11b2f197481382e34b760c527c Author: Stephen Boyd Date: Wed Jun 23 00:50:02 2021 -0700 mmc: core: Don't allocate IDA for OF aliases commit 10252bae863d09b9648bed2e035572d207200ca1 upstream. There's a chance that the IDA allocated in mmc_alloc_host() is not freed for some time because it's freed as part of a class' release function (see mmc_host_classdev_release() where the IDA is freed). If another thread is holding a reference to the class, then only once all balancing device_put() calls (in turn calling kobject_put()) have been made will the IDA be released and usable again. Normally this isn't a problem because the kobject is released before anything else that may want to use the same number tries to again, but with CONFIG_DEBUG_KOBJECT_RELEASE=y and OF aliases it becomes pretty easy to try to allocate an alias from the IDA twice while the first time it was allocated is still pending a call to ida_simple_remove(). It's also possible to trigger it by using CONFIG_DEBUG_KOBJECT_RELEASE and probe defering a driver at boot that calls mmc_alloc_host() before trying to get resources that may defer likes clks or regulators. Instead of allocating from the IDA in this scenario, let's just skip it if we know this is an OF alias. The number is already "claimed" and devices that aren't using OF aliases won't try to use the claimed numbers anyway (see mmc_first_nonreserved_index()). This should avoid any issues with mmc_alloc_host() returning failures from the ida_simple_get() in the case that we're using an OF alias. Cc: Matthias Schiffer Cc: Sujit Kautkar Reported-by: Zubin Mithra Fixes: fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree alias") Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210623075002.1746924-3-swboyd@chromium.org Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit fc6ac92cfcab3269a4398f185f8ac460dd359b86 Author: Marcelo Henrique Cerri Date: Wed Jun 30 18:54:38 2021 -0700 proc: Avoid mixing integer types in mem_rw() [ Upstream commit d238692b4b9f2c36e35af4c6e6f6da36184aeb3e ] Use size_t when capping the count argument received by mem_rw(). Since count is size_t, using min_t(int, ...) can lead to a negative value that will later be passed to access_remote_vm(), which can cause unexpected behavior. Since we are capping the value to at maximum PAGE_SIZE, the conversion from size_t to int when passing it to access_remote_vm() as "len" shouldn't be a problem. Link: https://lkml.kernel.org/r/20210512125215.3348316-1-marcelo.cerri@canonical.com Reviewed-by: David Disseldorp Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Marcelo Henrique Cerri Cc: Alexey Dobriyan Cc: Souza Cascardo Cc: Christian Brauner Cc: Michel Lespinasse Cc: Helge Deller Cc: Oleg Nesterov Cc: Lorenzo Stoakes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 76f7eae7ec802e54daba4b5fae9e0a6e96b267c9 Author: Ronnie Sahlberg Date: Fri Jul 23 11:21:24 2021 +1000 cifs: fix fallocate when trying to allocate a hole. [ Upstream commit 488968a8945c119859d91bb6a8dc13bf50002f15 ] Remove the conditional checking for out_data_len and skipping the fallocate if it is 0. This is wrong will actually change any legitimate the fallocate where the entire region is unallocated into a no-op. Additionally, before allocating the range, if FALLOC_FL_KEEP_SIZE is set then we need to clamp the length of the fallocate region as to not extend the size of the file. Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation") Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c26372b8a8c301d56204cddb9aedfa2c67adac17 Author: Ronnie Sahlberg Date: Thu Jul 22 14:53:32 2021 +1000 cifs: only write 64kb at a time when fallocating a small region of a file [ Upstream commit 2485bd7557a7edb4520b4072af464f0a08c8efe0 ] We only allow sending single credit writes through the SMB2_write() synchronous api so split this into smaller chunks. Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation") Signed-off-by: Ronnie Sahlberg Reported-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b91e5b63470d7a2f5225540e8093b06426d00bf9 Author: Maxime Ripard Date: Tue Jul 20 15:45:23 2021 +0200 drm/panel: raspberrypi-touchscreen: Prevent double-free [ Upstream commit 7bbcb919e32d776ca8ddce08abb391ab92eef6a9 ] The mipi_dsi_device allocated by mipi_dsi_device_register_full() is already free'd on release. Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7" Touchscreen.") Signed-off-by: Maxime Ripard Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210720134525.563936-9-maxime@cerno.tech Signed-off-by: Sasha Levin commit 9e0373945ed63615689b1982e60044d2c41b3e5d Author: Yajun Deng Date: Thu Jul 22 11:23:43 2021 +0800 net: sched: cls_api: Fix the the wrong parameter [ Upstream commit 9d85a6f44bd5585761947f40f7821c9cd78a1bbe ] The 4th parameter in tc_chain_notify() should be flags rather than seq. Let's change it back correctly. Fixes: 32a4f5ecd738 ("net: sched: introduce chain object to uapi") Signed-off-by: Yajun Deng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c8ebf135c1996e60a28be269e6fdaf9b46e1ff99 Author: Vladimir Oltean Date: Wed Jul 21 15:37:59 2021 +0300 net: dsa: sja1105: make VID 4095 a bridge VLAN too [ Upstream commit e40cba9490bab1414d45c2d62defc0ad4f6e4136 ] This simple series of commands: ip link add br0 type bridge vlan_filtering 1 ip link set swp0 master br0 fails on sja1105 with the following error: [ 33.439103] sja1105 spi0.1: vlan-lookup-table needs to have at least the default untagged VLAN [ 33.447710] sja1105 spi0.1: Invalid config, cannot upload Warning: sja1105: Failed to change VLAN Ethertype. For context, sja1105 has 3 operating modes: - SJA1105_VLAN_UNAWARE: the dsa_8021q_vlans are committed to hardware - SJA1105_VLAN_FILTERING_FULL: the bridge_vlans are committed to hardware - SJA1105_VLAN_FILTERING_BEST_EFFORT: both the dsa_8021q_vlans and the bridge_vlans are committed to hardware Swapping out a VLAN list and another in happens in sja1105_build_vlan_table(), which performs a delta update procedure. That function is called from a few places, notably from sja1105_vlan_filtering() which is called from the SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING handler. The above set of 2 commands fails when run on a kernel pre-commit 8841f6e63f2c ("net: dsa: sja1105: make devlink property best_effort_vlan_filtering true by default"). So the priv->vlan_state transition that takes place is between VLAN-unaware and full VLAN filtering. So the dsa_8021q_vlans are swapped out and the bridge_vlans are swapped in. So why does it fail? Well, the bridge driver, through nbp_vlan_init(), first sets up the SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING attribute, and only then proceeds to call nbp_vlan_add for the default_pvid. So when we swap out the dsa_8021q_vlans and swap in the bridge_vlans in the SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING handler, there are no bridge VLANs (yet). So we have wiped the VLAN table clean, and the low-level static config checker complains of an invalid configuration. We _will_ add the bridge VLANs using the dynamic config interface, albeit later, when nbp_vlan_add() calls us. So it is natural that it fails. So why did it ever work? Surprisingly, it looks like I only tested this configuration with 2 things set up in a particular way: - a network manager that brings all ports up - a kernel with CONFIG_VLAN_8021Q=y It is widely known that commit ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)") installs VID 0 to every net device that comes up. DSA treats these VLANs as bridge VLANs, and therefore, in my testing, the list of bridge_vlans was never empty. However, if CONFIG_VLAN_8021Q is not enabled, or the port is not up when it joins a VLAN-aware bridge, the bridge_vlans list will be temporarily empty, and the sja1105_static_config_reload() call from sja1105_vlan_filtering() will fail. To fix this, the simplest thing is to keep VID 4095, the one used for CPU-injected control packets since commit ed040abca4c1 ("net: dsa: sja1105: use 4095 as the private VLAN for untagged traffic"), in the list of bridge VLANs too, not just the list of tag_8021q VLANs. This ensures that the list of bridge VLANs will never be empty. Fixes: ec5ae61076d0 ("net: dsa: sja1105: save/restore VLANs using a delta commit method") Reported-by: Radu Pirea (NXP OSS) Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 164294d09c47b9a6c6160b08c43d74ae93c82758 Author: Wei Wang Date: Wed Jul 21 10:27:38 2021 -0700 tcp: disable TFO blackhole logic by default [ Upstream commit 213ad73d06073b197a02476db3a4998e219ddb06 ] Multiple complaints have been raised from the TFO users on the internet stating that the TFO blackhole logic is too aggressive and gets falsely triggered too often. (e.g. https://blog.apnic.net/2021/07/05/tcp-fast-open-not-so-fast/) Considering that most middleboxes no longer drop TFO packets, we decide to disable the blackhole logic by setting /proc/sys/net/ipv4/tcp_fastopen_blackhole_timeout_set to 0 by default. Fixes: cf1ef3f0719b4 ("net/tcp_fastopen: Disable active side TFO in certain scenarios") Signed-off-by: Wei Wang Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell Acked-by: Soheil Hassas Yeganeh Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8eb225873246312660ccd68296959a7b213d0cdd Author: Xin Long Date: Tue Jul 20 16:07:01 2021 -0400 sctp: update active_key for asoc when old key is being replaced [ Upstream commit 58acd10092268831e49de279446c314727101292 ] syzbot reported a call trace: BUG: KASAN: use-after-free in sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 Call Trace: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:131 [inline] sctp_sendmsg_to_asoc+0x152e/0x2180 net/sctp/socket.c:1865 sctp_sendmsg+0x103b/0x1d30 net/sctp/socket.c:2027 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:821 sock_sendmsg_nosec net/socket.c:703 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:723 This is an use-after-free issue caused by not updating asoc->shkey after it was replaced in the key list asoc->endpoint_shared_keys, and the old key was freed. This patch is to fix by also updating active_key for asoc when old key is being replaced with a new one. Note that this issue doesn't exist in sctp_auth_del_key_id(), as it's not allowed to delete the active_key from the asoc. Fixes: 1b1e0bc99474 ("sctp: add refcnt support for sh_key") Reported-by: syzbot+b774577370208727d12b@syzkaller.appspotmail.com Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ef799bd8ff5a8b11a3bb7767f8940a987a4415c6 Author: Christoph Hellwig Date: Wed Jul 21 10:00:11 2021 +0200 nvme: set the PRACT bit when using Write Zeroes with T10 PI [ Upstream commit aaeb7bb061be545251606f4d9c82d710ca2a7c8e ] When using Write Zeroes on a namespace that has protection information enabled they behavior without the PRACT bit counter-intuitive and will generally lead to validation failures when reading the written blocks. Fix this by always setting the PRACT bit that generates matching PI data on the fly. Fixes: 6e02318eaea5 ("nvme: add support for the Write Zeroes command") Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7850f03ed8146ee25892c778aa66a6433a37e430 Author: Sayanta Pattanayak Date: Tue Jul 20 17:17:40 2021 +0100 r8169: Avoid duplicate sysfs entry creation error [ Upstream commit e9a72f874d5b95cef0765bafc56005a50f72c5fe ] When registering the MDIO bus for a r8169 device, we use the PCI bus/device specifier as a (seemingly) unique device identifier. However the very same BDF number can be used on another PCI segment, which makes the driver fail probing: [ 27.544136] r8169 0002:07:00.0: enabling device (0000 -> 0003) [ 27.559734] sysfs: cannot create duplicate filename '/class/mdio_bus/r8169-700' .... [ 27.684858] libphy: mii_bus r8169-700 failed to register [ 27.695602] r8169: probe of 0002:07:00.0 failed with error -22 Add the segment number to the device name to make it more unique. This fixes operation on ARM N1SDP boards, with two boards connected together to form an SMP system, and all on-board devices showing up twice, just on different PCI segments. A similar issue would occur on large systems with many PCI slots and multiple RTL8169 NICs. Fixes: f1e911d5d0dfd ("r8169: add basic phylib support") Signed-off-by: Sayanta Pattanayak [Andre: expand commit message, use pci_domain_nr()] Signed-off-by: Andre Przywara Acked-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0f5dc39714733f58615ff246cb180b1a83304963 Author: David Howells Date: Tue Jun 15 11:57:26 2021 +0100 afs: Fix tracepoint string placement with built-in AFS [ Upstream commit 6c881ca0b3040f3e724eae513117ba4ddef86057 ] To quote Alexey[1]: I was adding custom tracepoint to the kernel, grabbed full F34 kernel .config, disabled modules and booted whole shebang as VM kernel. Then did perf record -a -e ... It crashed: general protection fault, probably for non-canonical address 0x435f5346592e4243: 0000 [#1] SMP PTI CPU: 1 PID: 842 Comm: cat Not tainted 5.12.6+ #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:t_show+0x22/0xd0 Then reproducer was narrowed to # cat /sys/kernel/tracing/printk_formats Original F34 kernel with modules didn't crash. So I started to disable options and after disabling AFS everything started working again. The root cause is that AFS was placing char arrays content into a section full of _pointers_ to strings with predictable consequences. Non canonical address 435f5346592e4243 is "CB.YFS_" which came from CM_NAME macro. Steps to reproduce: CONFIG_AFS=y CONFIG_TRACING=y # cat /sys/kernel/tracing/printk_formats Fix this by the following means: (1) Add enum->string translation tables in the event header with the AFS and YFS cache/callback manager operations listed by RPC operation ID. (2) Modify the afs_cb_call tracepoint to print the string from the translation table rather than using the string at the afs_call name pointer. (3) Switch translation table depending on the service we're being accessed as (AFS or YFS) in the tracepoint print clause. Will this cause problems to userspace utilities? Note that the symbolic representation of the YFS service ID isn't available to this header, so I've put it in as a number. I'm not sure if this is the best way to do this. (4) Remove the name wrangling (CM_NAME) macro and put the names directly into the afs_call_type structs in cmservice.c. Fixes: 8e8d7f13b6d5a9 ("afs: Add some tracepoints") Reported-by: Alexey Dobriyan (SK hynix) Signed-off-by: David Howells Reviewed-by: Steven Rostedt (VMware) Reviewed-by: Marc Dionne cc: Andrew Morton cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/YLAXfvZ+rObEOdc%2F@localhost.localdomain/ [1] Link: https://lore.kernel.org/r/643721.1623754699@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/162430903582.2896199.6098150063997983353.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/162609463957.3133237.15916579353149746363.stgit@warthog.procyon.org.uk/ # v1 (repost) Link: https://lore.kernel.org/r/162610726860.3408253.445207609466288531.stgit@warthog.procyon.org.uk/ # v2 Signed-off-by: Sasha Levin commit 711057846aa7e72d4d8bc5029845c3b08159c71f Author: Vincent Palatin Date: Wed Jul 21 11:25:16 2021 +0200 Revert "USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem" [ Upstream commit f3a1a937f7b240be623d989c8553a6d01465d04f ] This reverts commit 0bd860493f81eb2a46173f6f5e44cc38331c8dbd. While the patch was working as stated,ie preventing the L850-GL LTE modem from crashing on some U3 wake-ups due to a race condition between the host wake-up and the modem-side wake-up, when using the MBIM interface, this would force disabling the USB runtime PM on the device. The increased power consumption is significant for LTE laptops, and given that with decently recent modem firmwares, when the modem hits the bug, it automatically recovers (ie it drops from the bus, but automatically re-enumerates after less than half a second, rather than being stuck until a power cycle as it was doing with ancient firmware), for most people, the trade-off now seems in favor of re-enabling it by default. For people with access to the platform code, the bug can also be worked-around successfully by changing the USB3 LFPM polling off-time for the XHCI controller in the BIOS code. Signed-off-by: Vincent Palatin Link: https://lore.kernel.org/r/20210721092516.2775971-1-vpalatin@chromium.org Fixes: 0bd860493f81 ("USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem") Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8985dc2cabd67101c923be3c03fc178d956ef4c8 Author: Zhihao Cheng Date: Mon Jul 5 21:38:29 2021 +0800 nvme-pci: don't WARN_ON in nvme_reset_work if ctrl.state is not RESETTING [ Upstream commit 7764656b108cd308c39e9a8554353b8f9ca232a3 ] Followling process: nvme_probe nvme_reset_ctrl nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING) queue_work(nvme_reset_wq, &ctrl->reset_work) --------------> nvme_remove nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING) worker_thread process_one_work nvme_reset_work WARN_ON(dev->ctrl.state != NVME_CTRL_RESETTING) , which will trigger WARN_ON in nvme_reset_work(): [ 127.534298] WARNING: CPU: 0 PID: 139 at drivers/nvme/host/pci.c:2594 [ 127.536161] CPU: 0 PID: 139 Comm: kworker/u8:7 Not tainted 5.13.0 [ 127.552518] Call Trace: [ 127.552840] ? kvm_sched_clock_read+0x25/0x40 [ 127.553936] ? native_send_call_func_single_ipi+0x1c/0x30 [ 127.555117] ? send_call_function_single_ipi+0x9b/0x130 [ 127.556263] ? __smp_call_single_queue+0x48/0x60 [ 127.557278] ? ttwu_queue_wakelist+0xfa/0x1c0 [ 127.558231] ? try_to_wake_up+0x265/0x9d0 [ 127.559120] ? ext4_end_io_rsv_work+0x160/0x290 [ 127.560118] process_one_work+0x28c/0x640 [ 127.561002] worker_thread+0x39a/0x700 [ 127.561833] ? rescuer_thread+0x580/0x580 [ 127.562714] kthread+0x18c/0x1e0 [ 127.563444] ? set_kthread_struct+0x70/0x70 [ 127.564347] ret_from_fork+0x1f/0x30 The preceding problem can be easily reproduced by executing following script (based on blktests suite): test() { pdev="$(_get_pci_dev_from_blkdev)" sysfs="/sys/bus/pci/devices/${pdev}" for ((i = 0; i < 10; i++)); do echo 1 > "$sysfs/remove" echo 1 > /sys/bus/pci/rescan done } Since the device ctrl could be updated as an non-RESETTING state by repeating probe/remove in userspace (which is a normal situation), we can replace stack dumping WARN_ON with a warnning message. Fixes: 82b057caefaff ("nvme-pci: fix multiple ctrl removal schedulin") Signed-off-by: Zhihao Cheng Signed-off-by: Sasha Levin commit fb28b15920989a30c144530203e4ce608f6c53ec Author: Luis Henriques Date: Thu Jul 15 14:40:39 2021 +0100 ceph: don't WARN if we're still opening a session to an MDS [ Upstream commit cdb330f4b41ab55feb35487729e883c9e08b8a54 ] If MDSs aren't available while mounting a filesystem, the session state will transition from SESSION_OPENING to SESSION_CLOSING. And in that scenario check_session_state() will be called from delayed_work() and trigger this WARN. Avoid this by only WARNing after a session has already been established (i.e., the s_ttl will be different from 0). Fixes: 62575e270f66 ("ceph: check session state after bumping session->s_seq") Signed-off-by: Luis Henriques Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit ce8fafb68051fba52546f8bbe8621f7641683680 Author: Paolo Abeni Date: Tue Jul 20 15:08:40 2021 +0200 ipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions [ Upstream commit 8fb4792f091e608a0a1d353dfdf07ef55a719db5 ] While running the self-tests on a KASAN enabled kernel, I observed a slab-out-of-bounds splat very similar to the one reported in commit 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions"). We additionally need to take care of fib6_metrics initialization failure when the caller provides an nh. The fix is similar, explicitly free the route instead of calling fib6_info_release on a half-initialized object. Fixes: f88d8ea67fbdb ("ipv6: Plumb support for nexthop object in a fib6_info") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 071729150be9e1d1b851b70efb6d91ee9269d57b Author: Peilin Ye Date: Mon Jul 19 16:41:24 2021 -0700 net/sched: act_skbmod: Skip non-Ethernet packets [ Upstream commit 727d6a8b7ef3d25080fad228b2c4a1d4da5999c6 ] Currently tcf_skbmod_act() assumes that packets use Ethernet as their L2 protocol, which is not always the case. As an example, for CAN devices: $ ip link add dev vcan0 type vcan $ ip link set up vcan0 $ tc qdisc add dev vcan0 root handle 1: htb $ tc filter add dev vcan0 parent 1: protocol ip prio 10 \ matchall action skbmod swap mac Doing the above silently corrupts all the packets. Do not perform skbmod actions for non-Ethernet packets. Fixes: 86da71b57383 ("net_sched: Introduce skbmod action") Reviewed-by: Cong Wang Signed-off-by: Peilin Ye Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ee36bb47138949a5aaa79b8a6acde2c40379b67d Author: Alexandru Tachici Date: Sat Jul 17 00:02:45 2021 +0300 spi: spi-bcm2835: Fix deadlock [ Upstream commit c45c1e82bba130db4f19d9dbc1deefcf4ea994ed ] The bcm2835_spi_transfer_one function can create a deadlock if it is called while another thread already has the CCF lock. Signed-off-by: Alexandru Tachici Fixes: f8043872e796 ("spi: add driver for BCM2835") Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20210716210245.13240-2-alexandru.tachici@analog.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 432738c9740c735cb359e89b8b3605400e4e551a Author: Jian Shen Date: Mon Jul 19 17:13:08 2021 +0800 net: hns3: fix rx VLAN offload state inconsistent issue [ Upstream commit bbfd4506f962e7e6fff8f37f017154a3c3791264 ] Currently, VF doesn't enable rx VLAN offload when initializating, and PF does it for VFs. If user disable the rx VLAN offload for VF with ethtool -K, and reload the VF driver, it may cause the rx VLAN offload state being inconsistent between hardware and software. Fixes it by enabling rx VLAN offload when VF initializing. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Jian Shen Signed-off-by: Guangbin Huang Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3e903e0b578bd72f6349fb5a83a892f85a25b03b Author: Chengwen Feng Date: Mon Jul 19 17:13:05 2021 +0800 net: hns3: fix possible mismatches resp of mailbox [ Upstream commit 1b713d14dc3c077ec45e65dab4ea01a8bc41b8c1 ] Currently, the mailbox synchronous communication between VF and PF use the following fields to maintain communication: 1. Origin_mbx_msg which was combined by message code and subcode, used to match request and response. 2. Received_resp which means whether received response. There may possible mismatches of the following situation: 1. VF sends message A with code=1 subcode=1. 2. PF was blocked about 500ms when processing the message A. 3. VF will detect message A timeout because it can't get the response within 500ms. 4. VF sends message B with code=1 subcode=1 which equal message A. 5. PF processes the first message A and send the response message to VF. 6. VF will identify the response matched the message B because the code/subcode is the same. This will lead to mismatch of request and response. To fix the above bug, we use the following scheme: 1. The message sent from VF was labelled with match_id which was a unique 16-bit non-zero value. 2. The response sent from PF will label with match_id which got from the request. 3. The VF uses the match_id to match request and response message. As for PF driver, it only needs to copy the match_id from request to response. Fixes: dde1a86e93ca ("net: hns3: Add mailbox support to PF driver") Signed-off-by: Chengwen Feng Signed-off-by: Guangbin Huang Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4305375f031acbe908c166e2b61952aa49b1a42 Author: Pierre-Louis Bossart Date: Mon Jul 19 18:17:46 2021 -0500 ALSA: hda: intel-dsp-cfg: add missing ElkhartLake PCI ID [ Upstream commit 114613f62f42e7cbc1242c4e82076a0153043761 ] We missed the fact that ElkhartLake platforms have two different PCI IDs. We only added one so the SOF driver is never selected by the autodetection logic for the missing configuration. BugLink: https://github.com/thesofproject/linux/issues/2990 Fixes: cc8f81c7e625 ('ALSA: hda: fix intel DSP config') Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210719231746.557325-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 41a839437a0776f99c23dfe19138a0dc842d8bb3 Author: Eric Dumazet Date: Mon Jul 19 02:12:18 2021 -0700 net/tcp_fastopen: fix data races around tfo_active_disable_stamp [ Upstream commit 6f20c8adb1813467ea52c1296d52c4e95978cb2f ] tfo_active_disable_stamp is read and written locklessly. We need to annotate these accesses appropriately. Then, we need to perform the atomic_inc(tfo_active_disable_times) after the timestamp has been updated, and thus add barriers to make sure tcp_fastopen_active_should_disable() wont read a stale timestamp. Fixes: cf1ef3f0719b ("net/tcp_fastopen: Disable active side TFO in certain scenarios") Signed-off-by: Eric Dumazet Cc: Wei Wang Cc: Yuchung Cheng Cc: Neal Cardwell Acked-by: Wei Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ba3336397677a9d773d17254c837d43e1c5cd214 Author: Randy Dunlap Date: Sun Jul 18 13:38:34 2021 -0700 net: hisilicon: rename CACHE_LINE_MASK to avoid redefinition [ Upstream commit b16f3299ae1aa3c327e1fb742d0379ae4d6e86f2 ] Building on ARCH=arc causes a "redefined" warning, so rename this driver's CACHE_LINE_MASK to avoid the warning. ../drivers/net/ethernet/hisilicon/hip04_eth.c:134: warning: "CACHE_LINE_MASK" redefined 134 | #define CACHE_LINE_MASK 0x3F In file included from ../include/linux/cache.h:6, from ../include/linux/printk.h:9, from ../include/linux/kernel.h:19, from ../include/linux/list.h:9, from ../include/linux/module.h:12, from ../drivers/net/ethernet/hisilicon/hip04_eth.c:7: ../arch/arc/include/asm/cache.h:17: note: this is the location of the previous definition 17 | #define CACHE_LINE_MASK (~(L1_CACHE_BYTES - 1)) Fixes: d413779cdd93 ("net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC") Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: Jiangfeng Xiao Cc: "David S. Miller" Cc: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 320dcbdec4c62627848a48f4f37663c1b5746daf Author: Somnath Kotur Date: Sun Jul 18 15:36:31 2021 -0400 bnxt_en: Check abort error state in bnxt_half_open_nic() [ Upstream commit 11a39259ff79b74bc99f8b7c44075a2d6d5e7ab1 ] bnxt_half_open_nic() is called during during ethtool self test and is protected by rtnl_lock. Firmware reset can be happening at the same time. Only critical portions of the entire firmware reset sequence are protected by the rtnl_lock. It is possible that bnxt_half_open_nic() can be called when the firmware reset sequence is aborting. In that case, bnxt_half_open_nic() needs to check if the ABORT_ERR flag is set and abort if it is. The ethtool self test will fail but the NIC will be brought to a consistent IF_DOWN state. Without this patch, if bnxt_half_open_nic() were to continue in this error state, it may crash like this: bnxt_en 0000:82:00.1 enp130s0f1np1: FW reset in progress during close, FW reset will be aborted Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... Process ethtool (pid: 333327, stack limit = 0x0000000046476577) Call trace: bnxt_alloc_mem+0x444/0xef0 [bnxt_en] bnxt_half_open_nic+0x24/0xb8 [bnxt_en] bnxt_self_test+0x2dc/0x390 [bnxt_en] ethtool_self_test+0xe0/0x1f8 dev_ethtool+0x1744/0x22d0 dev_ioctl+0x190/0x3e0 sock_ioctl+0x238/0x480 do_vfs_ioctl+0xc4/0x758 ksys_ioctl+0x84/0xb8 __arm64_sys_ioctl+0x28/0x38 el0_svc_handler+0xb0/0x180 el0_svc+0x8/0xc Fixes: a1301f08c5ac ("bnxt_en: Check abort error state in bnxt_open_nic().") Signed-off-by: Somnath Kotur Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 134a0536f0a4922003054d5edfb30b4c21c2cf3d Author: Michael Chan Date: Sun Jul 18 15:36:30 2021 -0400 bnxt_en: Validate vlan protocol ID on RX packets [ Upstream commit 96bdd4b9ea7ef9a12db8fdd0ce90e37dffbd3703 ] Only pass supported VLAN protocol IDs for stripped VLAN tags to the stack. The stack will hit WARN() if the protocol ID is unsupported. Existing firmware sets up the chip to strip 0x8100, 0x88a8, 0x9100. Only the 1st two protocols are supported by the kernel. Fixes: a196e96bb68f ("bnxt_en: clean up VLAN feature bit handling") Reviewed-by: Somnath Kotur Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4f7da0f97bebc506a429b289dffa2f3641ef1ab2 Author: Michael Chan Date: Sun Jul 18 15:36:28 2021 -0400 bnxt_en: Add missing check for BNXT_STATE_ABORT_ERR in bnxt_fw_rset_task() [ Upstream commit 6cd657cb3ee6f4de57e635b126ffbe0e51d00f1a ] In the BNXT_FW_RESET_STATE_POLL_VF state in bnxt_fw_reset_task() after all VFs have unregistered, we need to check for BNXT_STATE_ABORT_ERR after we acquire the rtnl_lock. If the flag is set, we need to abort. Fixes: 230d1f0de754 ("bnxt_en: Handle firmware reset.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 927370485e9809888da1bcf283eac3b314ec5248 Author: Michael Chan Date: Sun Jul 18 15:36:27 2021 -0400 bnxt_en: Refresh RoCE capabilities in bnxt_ulp_probe() [ Upstream commit 2c9f046bc377efd1f5e26e74817d5f96e9506c86 ] The capabilities can change after firmware upgrade/downgrade, so we should get the up-to-date RoCE capabilities everytime bnxt_ulp_probe() is called. Fixes: 2151fe0830fd ("bnxt_en: Handle RESET_NOTIFY async event from firmware.") Reviewed-by: Somnath Kotur Reviewed-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ab830c3bae192743635c13422ad00afc26716b08 Author: Kalesh AP Date: Sun Jul 18 15:36:25 2021 -0400 bnxt_en: don't disable an already disabled PCI device [ Upstream commit c81cfb6256d90ea5ba4a6fb280ea3b171be4e05c ] If device is already disabled in reset path and PCI io error is detected before the device could be enabled, driver could call pci_disable_device() for already disabled device. Fix this problem by calling pci_disable_device() only if the device is already enabled. Fixes: 6316ea6db93d ("bnxt_en: Enable AER support.") Signed-off-by: Kalesh AP Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 26463689445d24990a42da1d04f9df26bb76f792 Author: Robert Richter Date: Thu Jul 15 11:26:01 2021 +0200 ACPI: Kconfig: Fix table override from built-in initrd [ Upstream commit d2cbbf1fe503c07e466c62f83aa1926d74d15821 ] During a rework of initramfs code the INITRAMFS_COMPRESSION config option was removed in commit 65e00e04e5ae. A leftover as a dependency broke the config option ACPI_TABLE_OVERRIDE_VIA_ BUILTIN_INITRD that is used to enable the overriding of ACPI tables from built-in initrd. Fixing the dependency. Fixes: 65e00e04e5ae ("initramfs: refactor the initramfs build rules") Signed-off-by: Robert Richter Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 113ce8c5043a81cbaee6132efe126430ab1887af Author: Marek Vasut Date: Fri Jul 16 20:21:33 2021 +0200 spi: cadence: Correct initialisation of runtime PM again [ Upstream commit 56912da7a68c8356df6a6740476237441b0b792a ] The original implementation of RPM handling in probe() was mostly correct, except it failed to call pm_runtime_get_*() to activate the hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM"), breaks the implementation further, to the point where the system using this hard IP on ZynqMP hangs on boot, because it accesses hardware which is gated off. Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM") and instead add missing pm_runtime_get_noresume() and move the RPM disabling all the way to the end of probe(). That makes ZynqMP not hang on boot yet again. Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM") Signed-off-by: Marek Vasut Cc: Charles Keepax Cc: Mark Brown Link: https://lore.kernel.org/r/20210716182133.218640-1-marex@denx.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3ea448b62b49f2554b2df1527cf437ac6676b710 Author: Dmitry Bogdanov Date: Fri Jul 2 12:16:55 2021 +0300 scsi: target: Fix protect handling in WRITE SAME(32) [ Upstream commit 6d8e7e7c932162bccd06872362751b0e1d76f5af ] WRITE SAME(32) command handling reads WRPROTECT at the wrong offset in 1st byte instead of 10th byte. Link: https://lore.kernel.org/r/20210702091655.22818-1-d.bogdanov@yadro.com Fixes: afd73f1b60fc ("target: Perform PROTECT sanity checks for WRITE_SAME") Signed-off-by: Dmitry Bogdanov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b82a1a26aaeebbc7cfd89a0bbf1d96758546f526 Author: Mike Christie Date: Wed Jun 30 19:25:59 2021 -0500 scsi: iscsi: Fix iface sysfs attr detection [ Upstream commit e746f3451ec7f91dcc9fd67a631239c715850a34 ] A ISCSI_IFACE_PARAM can have the same value as a ISCSI_NET_PARAM so when iscsi_iface_attr_is_visible tries to figure out the type by just checking the value, we can collide and return the wrong type. When we call into the driver we might not match and return that we don't want attr visible in sysfs. The patch fixes this by setting the type when we figure out what the param is. Link: https://lore.kernel.org/r/20210701002559.89533-1-michael.christie@oracle.com Fixes: 3e0f65b34cc9 ("[SCSI] iscsi_transport: Additional parameters for network settings") Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6811744bd0efb9e472cb15d066cdb460beb8cb8a Author: Nguyen Dinh Phi Date: Sun Jul 18 22:40:13 2021 +0800 netrom: Decrease sock refcount when sock timers expire [ Upstream commit 517a16b1a88bdb6b530f48d5d153478b2552d9a8 ] Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use sock timer API. It replaces mod_timer() by sk_reset_timer(), and del_timer() by sk_stop_timer(). Function sk_reset_timer() will increase the refcount of sock if it is called on an inactive timer, hence, in case the timer expires, we need to decrease the refcount ourselves in the handler, otherwise, the sock refcount will be unbalanced and the sock will never be freed. Signed-off-by: Nguyen Dinh Phi Reported-by: syzbot+10f1194569953b72f1ae@syzkaller.appspotmail.com Fixes: 63346650c1a9 ("netrom: switch to sock timer API") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 096a8dca8ca5191292bcc6409c552a7b7f5e7362 Author: Xin Long Date: Sat Jul 17 17:19:19 2021 -0400 sctp: trim optlen when it's a huge value in sctp_setsockopt [ Upstream commit 2f3fdd8d4805015fa964807e1c7f3d88f31bd389 ] After commit ca84bd058dae ("sctp: copy the optval from user space in sctp_setsockopt"), it does memory allocation in sctp_setsockopt with the optlen, and it would fail the allocation and return error if the optlen from user space is a huge value. This breaks some sockopts, like SCTP_HMAC_IDENT, SCTP_RESET_STREAMS and SCTP_AUTH_KEY, as when processing these sockopts before, optlen would be trimmed to a biggest value it needs when optlen is a huge value, instead of failing the allocation and returning error. This patch is to fix the allocation failure when it's a huge optlen from user space by trimming it to the biggest size sctp sockopt may need when necessary, and this biggest size is from sctp_setsockopt_reset_streams() for SCTP_RESET_STREAMS, which is bigger than those for SCTP_HMAC_IDENT and SCTP_AUTH_KEY. Fixes: ca84bd058dae ("sctp: copy the optval from user space in sctp_setsockopt") Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8e9662fde6d63c78eb1350f6167f64c9d71a865b Author: Pavel Skripkin Date: Sat Jul 17 14:29:33 2021 +0300 net: sched: fix memory leak in tcindex_partial_destroy_work [ Upstream commit f5051bcece50140abd1a11a2d36dc3ec5484fc32 ] Syzbot reported memory leak in tcindex_set_parms(). The problem was in non-freed perfect hash in tcindex_partial_destroy_work(). In tcindex_set_parms() new tcindex_data is allocated and some fields from old one are copied to new one, but not the perfect hash. Since tcindex_partial_destroy_work() is the destroy function for old tcindex_data, we need to free perfect hash to avoid memory leak. Reported-and-tested-by: syzbot+f0bbb2287b8993d4fa74@syzkaller.appspotmail.com Fixes: 331b72922c5f ("net: sched: RCU cls_tcindex") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e14ef1095387f764d95614d3ec9e4d07c82a3533 Author: Nicholas Piggin Date: Fri Jul 16 12:43:10 2021 +1000 KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak [ Upstream commit bc4188a2f56e821ea057aca6bf444e138d06c252 ] vcpu_put is not called if the user copy fails. This can result in preempt notifier corruption and crashes, among other issues. Fixes: b3cebfe8c1ca ("KVM: PPC: Move vcpu_load/vcpu_put down to each ioctl case in kvm_arch_vcpu_ioctl") Reported-by: Alexey Kardashevskiy Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210716024310.164448-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit fcbad8e18d31e46d06c3458c8dcad897b8194cd9 Author: Nicholas Piggin Date: Fri Jul 16 12:43:09 2021 +1000 KVM: PPC: Book3S: Fix CONFIG_TRANSACTIONAL_MEM=n crash [ Upstream commit bd31ecf44b8e18ccb1e5f6b50f85de6922a60de3 ] When running CPU_FTR_P9_TM_HV_ASSIST, HFSCR[TM] is set for the guest even if the host has CONFIG_TRANSACTIONAL_MEM=n, which causes it to be unprepared to handle guest exits while transactional. Normal guests don't have a problem because the HTM capability will not be advertised, but a rogue or buggy one could crash the host. Fixes: 4bb3c7a0208f ("KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9") Reported-by: Alexey Kardashevskiy Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210716024310.164448-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit 30b8302151588e6c178fab0fe8f95369a1b0efb1 Author: Yajun Deng Date: Wed Jul 14 17:13:20 2021 +0800 net: decnet: Fix sleeping inside in af_decnet [ Upstream commit 5f119ba1d5771bbf46d57cff7417dcd84d3084ba ] The release_sock() is blocking function, it would change the state after sleeping. use wait_woken() instead. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yajun Deng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d402c60da0fdd7e7e8f886c0213e8c928a58c793 Author: Michal Suchanek Date: Thu Jul 8 11:46:54 2021 +0200 efi/tpm: Differentiate missing and invalid final event log table. [ Upstream commit 674a9f1f6815849bfb5bf385e7da8fc198aaaba9 ] Missing TPM final event log table is not a firmware bug. Clearly if providing event log in the old format makes the final event log invalid it should not be provided at least in that case. Fixes: b4f1874c6216 ("tpm: check event log version before reading final events") Signed-off-by: Michal Suchanek Reviewed-by: Jarkko Sakkinen Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 89837669031005da8644ecb1476936421aaaab40 Author: Roman Skakun Date: Fri Jul 16 11:39:34 2021 +0300 dma-mapping: handle vmalloc addresses in dma_common_{mmap,get_sgtable} [ Upstream commit 40ac971eab89330d6153e7721e88acd2d98833f9 ] xen-swiotlb can use vmalloc backed addresses for dma coherent allocations and uses the common helpers. Properly handle them to unbreak Xen on ARM platforms. Fixes: 1b65c4e5a9af ("swiotlb-xen: use xen_alloc/free_coherent_pages") Signed-off-by: Roman Skakun Reviewed-by: Andrii Anisov [hch: split the patch, renamed the helpers] Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 115e4f5b64ae8d9dd933167cafe2070aaac45849 Author: Dongliang Mu Date: Wed Jul 14 17:13:22 2021 +0800 usb: hso: fix error handling code of hso_create_net_device [ Upstream commit a6ecfb39ba9d7316057cea823b196b734f6b18ca ] The current error handling code of hso_create_net_device is hso_free_net_device, no matter which errors lead to. For example, WARNING in hso_free_net_device [1]. Fix this by refactoring the error handling code of hso_create_net_device by handling different errors by different code. [1] https://syzkaller.appspot.com/bug?id=66eff8d49af1b28370ad342787413e35bbe76efe Reported-by: syzbot+44d53c7255bb1aea22d2@syzkaller.appspotmail.com Fixes: 5fcfb6d0bfcd ("hso: fix bailout in error case of probe") Signed-off-by: Dongliang Mu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1582a02fecffcee306663035a295e28e1c4aaaff Author: Ziyang Xuan Date: Thu Jul 15 20:22:04 2021 +0800 net: fix uninit-value in caif_seqpkt_sendmsg [ Upstream commit 991e634360f2622a683b48dfe44fe6d9cb765a09 ] When nr_segs equal to zero in iovec_from_user, the object msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg which is defined in ___sys_sendmsg. So we cann't just judge msg->msg_iter.iov->base directlly. We can use nr_segs to judge msg in caif_seqpkt_sendmsg whether has data buffers. ===================================================== BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [inline] __sys_sendmmsg+0x808/0xc90 net/socket.c:2480 __compat_sys_sendmmsg net/compat.c:656 [inline] Reported-by: syzbot+09a5d591c1f98cf5efcb@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=1ace85e8fc9b0d5a45c08c2656c3e91762daa9b8 Fixes: bece7b2398d0 ("caif: Rewritten socket implementation") Signed-off-by: Ziyang Xuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2fc8048265ce8a4357addac6874e2fad905134be Author: Tobias Klauser Date: Thu Jul 15 13:06:09 2021 +0200 bpftool: Check malloc return value in mount_bpffs_for_pin [ Upstream commit d444b06e40855219ef38b5e9286db16d435f06dc ] Fix and add a missing NULL check for the prior malloc() call. Fixes: 49a086c201a9 ("bpftool: implement prog load command") Signed-off-by: Tobias Klauser Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Acked-by: Roman Gushchin Link: https://lore.kernel.org/bpf/20210715110609.29364-1-tklauser@distanz.ch Signed-off-by: Sasha Levin commit 3b5b0afd8d97b0e98e5dc91526414e9d27c08027 Author: Jakub Sitnicki Date: Wed Jul 14 17:47:50 2021 +0200 bpf, sockmap, udp: sk_prot needs inuse_idx set for proc stats [ Upstream commit 54ea2f49fd9400dd698c25450be3352b5613b3b4 ] The proc socket stats use sk_prot->inuse_idx value to record inuse sock stats. We currently do not set this correctly from sockmap side. The result is reading sock stats '/proc/net/sockstat' gives incorrect values. The socket counter is incremented correctly, but because we don't set the counter correctly when we replace sk_prot we may omit the decrement. To get the correct inuse_idx value move the core_initcall that initializes the UDP proto handlers to late_initcall. This way it is initialized after UDP has the chance to assign the inuse_idx value from the register protocol handler. Fixes: edc6741cc660 ("bpf: Add sockmap hooks for UDP sockets") Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Reviewed-by: Cong Wang Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20210714154750.528206-1-jakub@cloudflare.com Signed-off-by: Sasha Levin commit c260442431b4a9bb17e0ae4b727cc6838bea5f33 Author: John Fastabend Date: Mon Jul 12 12:55:46 2021 -0700 bpf, sockmap, tcp: sk_prot needs inuse_idx set for proc stats [ Upstream commit 228a4a7ba8e99bb9ef980b62f71e3be33f4aae69 ] The proc socket stats use sk_prot->inuse_idx value to record inuse sock stats. We currently do not set this correctly from sockmap side. The result is reading sock stats '/proc/net/sockstat' gives incorrect values. The socket counter is incremented correctly, but because we don't set the counter correctly when we replace sk_prot we may omit the decrement. To get the correct inuse_idx value move the core_initcall that initializes the TCP proto handlers to late_initcall. This way it is initialized after TCP has the chance to assign the inuse_idx value from the register protocol handler. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Suggested-by: Jakub Sitnicki Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Reviewed-by: Cong Wang Link: https://lore.kernel.org/bpf/20210712195546.423990-3-john.fastabend@gmail.com Signed-off-by: Sasha Levin commit 715f378f42909c401ec043f5150c4fdf57fb8889 Author: John Fastabend Date: Mon Jul 12 12:55:45 2021 -0700 bpf, sockmap: Fix potential memory leak on unlikely error case [ Upstream commit 7e6b27a69167f97c56b5437871d29e9722c3e470 ] If skb_linearize is needed and fails we could leak a msg on the error handling. To fix ensure we kfree the msg block before returning error. Found during code review. Fixes: 4363023d2668e ("bpf, sockmap: Avoid failures from skb_to_sgvec when skb has frag_list") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Reviewed-by: Cong Wang Link: https://lore.kernel.org/bpf/20210712195546.423990-2-john.fastabend@gmail.com Signed-off-by: Sasha Levin commit e3a9548ae53834a44a52791af31f272f15c16d59 Author: Colin Ian King Date: Thu Jul 15 13:57:12 2021 +0100 s390/bpf: Perform r1 range checking before accessing jit->seen_reg[r1] [ Upstream commit 91091656252f5d6d8c476e0c92776ce9fae7b445 ] Currently array jit->seen_reg[r1] is being accessed before the range checking of index r1. The range changing on r1 should be performed first since it will avoid any potential out-of-range accesses on the array seen_reg[] and also it is more optimal to perform checks on r1 before fetching data from the array. Fix this by swapping the order of the checks before the array access. Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend") Signed-off-by: Colin Ian King Signed-off-by: Daniel Borkmann Tested-by: Ilya Leoshkevich Acked-by: Ilya Leoshkevich Link: https://lore.kernel.org/bpf/20210715125712.24690-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 9264bebe9ef9058936089891d545f8b2a53104d5 Author: Colin Ian King Date: Wed Jul 14 16:23:43 2021 +0100 liquidio: Fix unintentional sign extension issue on left shift of u16 [ Upstream commit e7efc2ce3d0789cd7c21b70ff00cd7838d382639 ] Shifting the u16 integer oct->pcie_port by CN23XX_PKT_INPUT_CTL_MAC_NUM_POS (29) bits will be promoted to a 32 bit signed int and then sign-extended to a u64. In the cases where oct->pcie_port where bit 2 is set (e.g. 3..7) the shifted value will be sign extended and the top 32 bits of the result will be set. Fix this by casting the u16 values to a u64 before the 29 bit left shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 3451b97cce2d ("liquidio: CN23XX register setup") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0ff2ea9d8fa355613bfe4ed297e8dd068aa5a309 Author: Nicolas Saenz Julienne Date: Fri Jul 9 16:13:25 2021 +0200 timers: Fix get_next_timer_interrupt() with no timers pending [ Upstream commit aebacb7f6ca1926918734faae14d1f0b6fae5cb7 ] 31cd0e119d50 ("timers: Recalculate next timer interrupt only when necessary") subtly altered get_next_timer_interrupt()'s behaviour. The function no longer consistently returns KTIME_MAX with no timers pending. In order to decide if there are any timers pending we check whether the next expiry will happen NEXT_TIMER_MAX_DELTA jiffies from now. Unfortunately, the next expiry time and the timer base clock are no longer updated in unison. The former changes upon certain timer operations (enqueue, expire, detach), whereas the latter keeps track of jiffies as they move forward. Ultimately breaking the logic above. A simplified example: - Upon entering get_next_timer_interrupt() with: jiffies = 1 base->clk = 0; base->next_expiry = NEXT_TIMER_MAX_DELTA; 'base->next_expiry == base->clk + NEXT_TIMER_MAX_DELTA', the function returns KTIME_MAX. - 'base->clk' is updated to the jiffies value. - The next time we enter get_next_timer_interrupt(), taking into account no timer operations happened: base->clk = 1; base->next_expiry = NEXT_TIMER_MAX_DELTA; 'base->next_expiry != base->clk + NEXT_TIMER_MAX_DELTA', the function returns a valid expire time, which is incorrect. This ultimately might unnecessarily rearm sched's timer on nohz_full setups, and add latency to the system[1]. So, introduce 'base->timers_pending'[2], update it every time 'base->next_expiry' changes, and use it in get_next_timer_interrupt(). [1] See tick_nohz_stop_tick(). [2] A quick pahole check on x86_64 and arm64 shows it doesn't make 'struct timer_base' any bigger. Fixes: 31cd0e119d50 ("timers: Recalculate next timer interrupt only when necessary") Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Frederic Weisbecker Signed-off-by: Sasha Levin commit ca9ba1de8f09976b45ccc8e655c51c6201992139 Author: Xuan Zhuo Date: Sat Jul 10 11:16:35 2021 +0800 xdp, net: Fix use-after-free in bpf_xdp_link_release [ Upstream commit 5acc7d3e8d342858405fbbc671221f676b547ce7 ] The problem occurs between dev_get_by_index() and dev_xdp_attach_link(). At this point, dev_xdp_uninstall() is called. Then xdp link will not be detached automatically when dev is released. But link->dev already points to dev, when xdp link is released, dev will still be accessed, but dev has been released. dev_get_by_index() | link->dev = dev | | rtnl_lock() | unregister_netdevice_many() | dev_xdp_uninstall() | rtnl_unlock() rtnl_lock(); | dev_xdp_attach_link() | rtnl_unlock(); | | netdev_run_todo() // dev released bpf_xdp_link_release() | /* access dev. | use-after-free */ | [ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0 [ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732 [ 45.968297] [ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22 [ 45.969222] Hardware name: linux,dummy-virt (DT) [ 45.969795] Call trace: [ 45.970106] dump_backtrace+0x0/0x4c8 [ 45.970564] show_stack+0x30/0x40 [ 45.970981] dump_stack_lvl+0x120/0x18c [ 45.971470] print_address_description.constprop.0+0x74/0x30c [ 45.972182] kasan_report+0x1e8/0x200 [ 45.972659] __asan_report_load8_noabort+0x2c/0x50 [ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.973834] bpf_link_free+0xd0/0x188 [ 45.974315] bpf_link_put+0x1d0/0x218 [ 45.974790] bpf_link_release+0x3c/0x58 [ 45.975291] __fput+0x20c/0x7e8 [ 45.975706] ____fput+0x24/0x30 [ 45.976117] task_work_run+0x104/0x258 [ 45.976609] do_notify_resume+0x894/0xaf8 [ 45.977121] work_pending+0xc/0x328 [ 45.977575] [ 45.977775] The buggy address belongs to the page: [ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998 [ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff) [ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000 [ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 45.982259] page dumped because: kasan: bad access detected [ 45.982948] [ 45.983153] Memory state around the buggy address: [ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.986419] ^ [ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988895] ================================================================== [ 45.989773] Disabling lock debugging due to kernel taint [ 45.990552] Kernel panic - not syncing: panic_on_warn set ... [ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22 [ 45.991929] Hardware name: linux,dummy-virt (DT) [ 45.992448] Call trace: [ 45.992753] dump_backtrace+0x0/0x4c8 [ 45.993208] show_stack+0x30/0x40 [ 45.993627] dump_stack_lvl+0x120/0x18c [ 45.994113] dump_stack+0x1c/0x34 [ 45.994530] panic+0x3a4/0x7d8 [ 45.994930] end_report+0x194/0x198 [ 45.995380] kasan_report+0x134/0x200 [ 45.995850] __asan_report_load8_noabort+0x2c/0x50 [ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.997007] bpf_link_free+0xd0/0x188 [ 45.997474] bpf_link_put+0x1d0/0x218 [ 45.997942] bpf_link_release+0x3c/0x58 [ 45.998429] __fput+0x20c/0x7e8 [ 45.998833] ____fput+0x24/0x30 [ 45.999247] task_work_run+0x104/0x258 [ 45.999731] do_notify_resume+0x894/0xaf8 [ 46.000236] work_pending+0xc/0x328 [ 46.000697] SMP: stopping secondary CPUs [ 46.001226] Dumping ftrace buffer: [ 46.001663] (ftrace buffer empty) [ 46.002110] Kernel Offset: disabled [ 46.002545] CPU features: 0x00000001,23202c00 [ 46.003080] Memory Limit: none Fixes: aa8d3a716b59db6c ("bpf, xdp: Add bpf_link-based XDP attachment API") Reported-by: Abaci Signed-off-by: Xuan Zhuo Signed-off-by: Alexei Starovoitov Reviewed-by: Dust Li Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210710031635.41649-1-xuanzhuo@linux.alibaba.com Signed-off-by: Sasha Levin commit 39f1735c8107ef43a53c4daf82f330d880488d8f Author: Daniel Borkmann Date: Mon Jul 12 22:57:35 2021 +0200 bpf: Fix tail_call_reachable rejection for interpreter when jit failed [ Upstream commit 5dd0a6b8582ffbfa88351949d50eccd5b6694ade ] During testing of f263a81451c1 ("bpf: Track subprog poke descriptors correctly and fix use-after-free") under various failure conditions, for example, when jit_subprogs() fails and tries to clean up the program to be run under the interpreter, we ran into the following freeze: [...] #127/8 tailcall_bpf2bpf_3:FAIL [...] [ 92.041251] BUG: KASAN: slab-out-of-bounds in ___bpf_prog_run+0x1b9d/0x2e20 [ 92.042408] Read of size 8 at addr ffff88800da67f68 by task test_progs/682 [ 92.043707] [ 92.044030] CPU: 1 PID: 682 Comm: test_progs Tainted: G O 5.13.0-53301-ge6c08cb33a30-dirty #87 [ 92.045542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 [ 92.046785] Call Trace: [ 92.047171] ? __bpf_prog_run_args64+0xc0/0xc0 [ 92.047773] ? __bpf_prog_run_args32+0x8b/0xb0 [ 92.048389] ? __bpf_prog_run_args64+0xc0/0xc0 [ 92.049019] ? ktime_get+0x117/0x130 [...] // few hundred [similar] lines more [ 92.659025] ? ktime_get+0x117/0x130 [ 92.659845] ? __bpf_prog_run_args64+0xc0/0xc0 [ 92.660738] ? __bpf_prog_run_args32+0x8b/0xb0 [ 92.661528] ? __bpf_prog_run_args64+0xc0/0xc0 [ 92.662378] ? print_usage_bug+0x50/0x50 [ 92.663221] ? print_usage_bug+0x50/0x50 [ 92.664077] ? bpf_ksym_find+0x9c/0xe0 [ 92.664887] ? ktime_get+0x117/0x130 [ 92.665624] ? kernel_text_address+0xf5/0x100 [ 92.666529] ? __kernel_text_address+0xe/0x30 [ 92.667725] ? unwind_get_return_address+0x2f/0x50 [ 92.668854] ? ___bpf_prog_run+0x15d4/0x2e20 [ 92.670185] ? ktime_get+0x117/0x130 [ 92.671130] ? __bpf_prog_run_args64+0xc0/0xc0 [ 92.672020] ? __bpf_prog_run_args32+0x8b/0xb0 [ 92.672860] ? __bpf_prog_run_args64+0xc0/0xc0 [ 92.675159] ? ktime_get+0x117/0x130 [ 92.677074] ? lock_is_held_type+0xd5/0x130 [ 92.678662] ? ___bpf_prog_run+0x15d4/0x2e20 [ 92.680046] ? ktime_get+0x117/0x130 [ 92.681285] ? __bpf_prog_run32+0x6b/0x90 [ 92.682601] ? __bpf_prog_run64+0x90/0x90 [ 92.683636] ? lock_downgrade+0x370/0x370 [ 92.684647] ? mark_held_locks+0x44/0x90 [ 92.685652] ? ktime_get+0x117/0x130 [ 92.686752] ? lockdep_hardirqs_on+0x79/0x100 [ 92.688004] ? ktime_get+0x117/0x130 [ 92.688573] ? __cant_migrate+0x2b/0x80 [ 92.689192] ? bpf_test_run+0x2f4/0x510 [ 92.689869] ? bpf_test_timer_continue+0x1c0/0x1c0 [ 92.690856] ? rcu_read_lock_bh_held+0x90/0x90 [ 92.691506] ? __kasan_slab_alloc+0x61/0x80 [ 92.692128] ? eth_type_trans+0x128/0x240 [ 92.692737] ? __build_skb+0x46/0x50 [ 92.693252] ? bpf_prog_test_run_skb+0x65e/0xc50 [ 92.693954] ? bpf_prog_test_run_raw_tp+0x2d0/0x2d0 [ 92.694639] ? __fget_light+0xa1/0x100 [ 92.695162] ? bpf_prog_inc+0x23/0x30 [ 92.695685] ? __sys_bpf+0xb40/0x2c80 [ 92.696324] ? bpf_link_get_from_fd+0x90/0x90 [ 92.697150] ? mark_held_locks+0x24/0x90 [ 92.698007] ? lockdep_hardirqs_on_prepare+0x124/0x220 [ 92.699045] ? finish_task_switch+0xe6/0x370 [ 92.700072] ? lockdep_hardirqs_on+0x79/0x100 [ 92.701233] ? finish_task_switch+0x11d/0x370 [ 92.702264] ? __switch_to+0x2c0/0x740 [ 92.703148] ? mark_held_locks+0x24/0x90 [ 92.704155] ? __x64_sys_bpf+0x45/0x50 [ 92.705146] ? do_syscall_64+0x35/0x80 [ 92.706953] ? entry_SYSCALL_64_after_hwframe+0x44/0xae [...] Turns out that the program rejection from e411901c0b77 ("bpf: allow for tailcalls in BPF subprograms for x64 JIT") is buggy since env->prog->aux->tail_call_reachable is never true. Commit ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT") added a tracker into check_max_stack_depth() which propagates the tail_call_reachable condition throughout the subprograms. This info is then assigned to the subprogram's func[i]->aux->tail_call_reachable. However, in the case of the rejection check upon JIT failure, env->prog->aux->tail_call_reachable is used. func[0]->aux->tail_call_reachable which represents the main program's information did not propagate this to the outer env->prog->aux, though. Add this propagation into check_max_stack_depth() where it needs to belong so that the check can be done reliably. Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT") Fixes: e411901c0b77 ("bpf: allow for tailcalls in BPF subprograms for x64 JIT") Co-developed-by: John Fastabend Signed-off-by: Daniel Borkmann Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Acked-by: Maciej Fijalkowski Link: https://lore.kernel.org/bpf/618c34e3163ad1a36b1e82377576a6081e182f25.1626123173.git.daniel@iogearbox.net Signed-off-by: Sasha Levin commit 2b4046e64f7dea0a48b6f65d3b1242c865322969 Author: Xuan Zhuo Date: Thu Jul 8 16:04:09 2021 +0800 bpf, test: fix NULL pointer dereference on invalid expected_attach_type [ Upstream commit 5e21bb4e812566aef86fbb77c96a4ec0782286e4 ] These two types of XDP progs (BPF_XDP_DEVMAP, BPF_XDP_CPUMAP) will not be executed directly in the driver, therefore we should also not directly run them from here. To run in these two situations, there must be further preparations done, otherwise these may cause a kernel panic. For more details, see also dev_xdp_attach(). [ 46.982479] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 46.984295] #PF: supervisor read access in kernel mode [ 46.985777] #PF: error_code(0x0000) - not-present page [ 46.987227] PGD 800000010dca4067 P4D 800000010dca4067 PUD 10dca6067 PMD 0 [ 46.989201] Oops: 0000 [#1] SMP PTI [ 46.990304] CPU: 7 PID: 562 Comm: a.out Not tainted 5.13.0+ #44 [ 46.992001] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/24 [ 46.995113] RIP: 0010:___bpf_prog_run+0x17b/0x1710 [ 46.996586] Code: 49 03 14 cc e8 76 f6 fe ff e9 ad fe ff ff 0f b6 43 01 48 0f bf 4b 02 48 83 c3 08 89 c2 83 e0 0f c0 ea 04 02 [ 47.001562] RSP: 0018:ffffc900005afc58 EFLAGS: 00010246 [ 47.003115] RAX: 0000000000000000 RBX: ffffc9000023f068 RCX: 0000000000000000 [ 47.005163] RDX: 0000000000000000 RSI: 0000000000000079 RDI: ffffc900005afc98 [ 47.007135] RBP: 0000000000000000 R08: ffffc9000023f048 R09: c0000000ffffdfff [ 47.009171] R10: 0000000000000001 R11: ffffc900005afb40 R12: ffffc900005afc98 [ 47.011172] R13: 0000000000000001 R14: 0000000000000001 R15: ffffffff825258a8 [ 47.013244] FS: 00007f04a5207580(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 [ 47.015705] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 47.017475] CR2: 0000000000000000 CR3: 0000000100182005 CR4: 0000000000770ee0 [ 47.019558] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 47.021595] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 47.023574] PKRU: 55555554 [ 47.024571] Call Trace: [ 47.025424] __bpf_prog_run32+0x32/0x50 [ 47.026296] ? printk+0x53/0x6a [ 47.027066] ? ktime_get+0x39/0x90 [ 47.027895] bpf_test_run.cold.28+0x23/0x123 [ 47.028866] ? printk+0x53/0x6a [ 47.029630] bpf_prog_test_run_xdp+0x149/0x1d0 [ 47.030649] __sys_bpf+0x1305/0x23d0 [ 47.031482] __x64_sys_bpf+0x17/0x20 [ 47.032316] do_syscall_64+0x3a/0x80 [ 47.033165] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 47.034254] RIP: 0033:0x7f04a51364dd [ 47.035133] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 48 [ 47.038768] RSP: 002b:00007fff8f9fc518 EFLAGS: 00000213 ORIG_RAX: 0000000000000141 [ 47.040344] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f04a51364dd [ 47.041749] RDX: 0000000000000048 RSI: 0000000020002a80 RDI: 000000000000000a [ 47.043171] RBP: 00007fff8f9fc530 R08: 0000000002049300 R09: 0000000020000100 [ 47.044626] R10: 0000000000000004 R11: 0000000000000213 R12: 0000000000401070 [ 47.046088] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 47.047579] Modules linked in: [ 47.048318] CR2: 0000000000000000 [ 47.049120] ---[ end trace 7ad34443d5be719a ]--- [ 47.050273] RIP: 0010:___bpf_prog_run+0x17b/0x1710 [ 47.051343] Code: 49 03 14 cc e8 76 f6 fe ff e9 ad fe ff ff 0f b6 43 01 48 0f bf 4b 02 48 83 c3 08 89 c2 83 e0 0f c0 ea 04 02 [ 47.054943] RSP: 0018:ffffc900005afc58 EFLAGS: 00010246 [ 47.056068] RAX: 0000000000000000 RBX: ffffc9000023f068 RCX: 0000000000000000 [ 47.057522] RDX: 0000000000000000 RSI: 0000000000000079 RDI: ffffc900005afc98 [ 47.058961] RBP: 0000000000000000 R08: ffffc9000023f048 R09: c0000000ffffdfff [ 47.060390] R10: 0000000000000001 R11: ffffc900005afb40 R12: ffffc900005afc98 [ 47.061803] R13: 0000000000000001 R14: 0000000000000001 R15: ffffffff825258a8 [ 47.063249] FS: 00007f04a5207580(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 [ 47.065070] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 47.066307] CR2: 0000000000000000 CR3: 0000000100182005 CR4: 0000000000770ee0 [ 47.067747] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 47.069217] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 47.070652] PKRU: 55555554 [ 47.071318] Kernel panic - not syncing: Fatal exception [ 47.072854] Kernel Offset: disabled [ 47.073683] ---[ end Kernel panic - not syncing: Fatal exception ]--- Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Fixes: fbee97feed9b ("bpf: Add support to attach bpf program to a devmap entry") Reported-by: Abaci Signed-off-by: Xuan Zhuo Signed-off-by: Daniel Borkmann Reviewed-by: Dust Li Acked-by: Jesper Dangaard Brouer Acked-by: David Ahern Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20210708080409.73525-1-xuanzhuo@linux.alibaba.com Signed-off-by: Sasha Levin commit 3dba72d1fc01c2d69734cb26c71863aeadd2715c Author: Maxim Schwalm Date: Mon Jul 12 03:50:11 2021 +0300 ASoC: rt5631: Fix regcache sync errors on resume [ Upstream commit c71f78a662611fe2c67f3155da19b0eff0f29762 ] The ALC5631 does not like multi-write accesses, avoid them. This fixes: rt5631 4-001a: Unable to sync registers 0x3a-0x3c. -121 errors on resume from suspend (and all registers after the registers in the error not being synced). Inspired by commit 2d30e9494f1e ("ASoC: rt5651: Fix regcache sync errors on resume") from Hans de Geode, which fixed the same errors on ALC5651. Signed-off-by: Maxim Schwalm Link: https://lore.kernel.org/r/20210712005011.28536-1-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2435dcfd16ac482803c6ecf2ba0d2a0553214d54 Author: Peter Hess Date: Tue Jul 6 14:16:09 2021 +0200 spi: mediatek: fix fifo rx mode [ Upstream commit 3a70dd2d050331ee4cf5ad9d5c0a32d83ead9a43 ] In FIFO mode were two problems: - RX mode was never handled and - in this case the tx_buf pointer was NULL and caused an exception fix this by handling RX mode in mtk_spi_fifo_transfer Fixes: a568231f4632 ("spi: mediatek: Add spi bus for Mediatek MT8173") Signed-off-by: Peter Hess Signed-off-by: Frank Wunderlich Link: https://lore.kernel.org/r/20210706121609.680534-1-linux@fw-web.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a9a85bfedd838a0c2fd15e30c13b233c39abeb76 Author: Axel Lin Date: Wed Jun 30 17:59:59 2021 +0800 regulator: hi6421: Fix getting wrong drvdata [ Upstream commit 1c73daee4bf30ccdff5e86dc400daa6f74735da5 ] Since config.dev = pdev->dev.parent in current code, so dev_get_drvdata(rdev->dev.parent) call in hi6421_regulator_enable returns the drvdata of the mfd device rather than the regulator. Fix it. This was broken while converting to use simplified DT parsing because the config.dev changed from pdev->dev to pdev->dev.parent for parsing the parent's of_node. Fixes: 29dc269a85ef ("regulator: hi6421: Convert to use simplified DT parsing") Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210630095959.2411543-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5cdc986aad95ad27935d69f0542fdb5a3635fc1e Author: Axel Lin Date: Sat Jun 19 20:41:33 2021 +0800 regulator: hi6421: Use correct variable type for regmap api val argument [ Upstream commit ae60e6a9d24e89a74e2512204ad04de94921bdd2 ] Use unsigned int instead of u32 for regmap_read/regmap_update_bits val argument. Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210619124133.4096683-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 23811b75fdb8c513da1119ded9d938dbb8a03e1d Author: Alain Volmat Date: Wed Jul 7 10:27:00 2021 +0200 spi: stm32: fixes pm_runtime calls in probe/remove [ Upstream commit 7999d2555c9f879d006ea8469d74db9cdb038af0 ] Add pm_runtime calls in probe/probe error path and remove in order to be consistent in all places in ordering and ensure that pm_runtime is disabled prior to resources used by the SPI controller. This patch also fixes the 2 following warnings on driver remove: WARNING: CPU: 0 PID: 743 at drivers/clk/clk.c:594 clk_core_disable_lock+0x18/0x24 WARNING: CPU: 0 PID: 743 at drivers/clk/clk.c:476 clk_unprepare+0x24/0x2c Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support") Signed-off-by: Amelie Delaunay Signed-off-by: Alain Volmat Link: https://lore.kernel.org/r/1625646426-5826-2-git-send-email-alain.volmat@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 844ab04b62a5fcb110b98de70ce5da7da8ad8dcf Author: Clark Wang Date: Thu Apr 8 18:33:47 2021 +0800 spi: imx: add a check for speed_hz before calculating the clock [ Upstream commit 4df2f5e1372e9eec8f9e1b4a3025b9be23487d36 ] When some drivers use spi to send data, spi_transfer->speed_hz is not assigned. If spidev->max_speed_hz is not assigned as well, it will cause an error in configuring the clock. Add a check for these two values before configuring the clock. An error will be returned when they are not assigned. Signed-off-by: Clark Wang Link: https://lore.kernel.org/r/20210408103347.244313-2-xiaoning.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3b6c430d1248aebdd3064e0b191a8c13a77e105c Author: Charles Keepax Date: Sat Jun 26 16:59:39 2021 +0100 ASoC: wm_adsp: Correct wm_coeff_tlv_get handling [ Upstream commit dd6fb8ff2210f74b056bf9234d0605e8c26a8ac0 ] When wm_coeff_tlv_get was updated it was accidentally switch to the _raw version of the helper causing it to ignore the current DSP state it should be checking. Switch the code back to the correct helper so that users can't read the controls when they arn't available. Fixes: 73ecf1a673d3 ("ASoC: wm_adsp: Correct cache handling of new kernel control API") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20210626155941.12251-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 57efe4f82a76439d2c812bf78193de311aa7863c Author: Yang Jihong Date: Tue Jul 13 19:23:58 2021 +0800 perf sched: Fix record failure when CONFIG_SCHEDSTATS is not set [ Upstream commit b0f008551f0bf4d5f6db9b5f0e071b02790d6a2e ] The tracepoints trace_sched_stat_{wait, sleep, iowait} are not exposed to user if CONFIG_SCHEDSTATS is not set, "perf sched record" records the three events. As a result, the command fails. Before: #perf sched record sleep 1 event syntax error: 'sched:sched_stat_wait' \___ unknown tracepoint Error: File /sys/kernel/tracing/events/sched/sched_stat_wait not found. Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?. Run 'perf list' for a list of valid events Usage: perf record [] [] or: perf record [] -- [] -e, --event event selector. use 'perf list' to list available events Solution: Check whether schedstat tracepoints are exposed. If no, these events are not recorded. After: # perf sched record sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.163 MB perf.data (1091 samples) ] # perf sched report run measurement overhead: 4736 nsecs sleep measurement overhead: 9059979 nsecs the run test took 999854 nsecs the sleep test took 8945271 nsecs nr_run_events: 716 nr_sleep_events: 785 nr_wakeup_events: 0 ... ------------------------------------------------------------ Fixes: 2a09b5de235a6 ("sched/fair: do not expose some tracepoints to user if CONFIG_SCHEDSTATS is not set") Signed-off-by: Yang Jihong Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Steven Rostedt (VMware) Cc: Yafang Shao Link: http://lore.kernel.org/lkml/20210713112358.194693-1-yangjihong1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 61f2e1e7957845be5179abe93659fa5378496882 Author: Riccardo Mancini Date: Fri Jul 16 16:11:20 2021 +0200 perf data: Close all files in close_dir() [ Upstream commit d4b3eedce151e63932ce4a00f1d0baa340a8b907 ] When using 'perf report' in directory mode, the first file is not closed on exit, causing a memory leak. The problem is caused by the iterating variable never reaching 0. Fixes: 145520631130bd64 ("perf data: Add perf_data__(create_dir|close_dir) functions") Signed-off-by: Riccardo Mancini Acked-by: Namhyung Kim Cc: Alexander Shishkin Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Cc: Zhen Lei Link: http://lore.kernel.org/lkml/20210716141122.858082-1-rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7c91e0ce260174c6b60032e96cd3d36429320c36 Author: Riccardo Mancini Date: Thu Jul 15 18:07:25 2021 +0200 perf probe-file: Delete namelist in del_events() on the error path [ Upstream commit e0fa7ab42232e742dcb3de9f3c1f6127b5adc019 ] ASan reports some memory leaks when running: # perf test "42: BPF filter" This second leak is caused by a strlist not being dellocated on error inside probe_file__del_events. This patch adds a goto label before the deallocation and makes the error path jump to it. Signed-off-by: Riccardo Mancini Fixes: e7895e422e4da63d ("perf probe: Split del_perf_probe_events()") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/174963c587ae77fa108af794669998e4ae558338.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a6c32317cd3d5a5526031ac9699b26442d44c689 Author: Riccardo Mancini Date: Thu Jul 15 18:07:19 2021 +0200 perf lzma: Close lzma stream on exit [ Upstream commit f8cbb0f926ae1e1fb5f9e51614e5437560ed4039 ] ASan reports memory leaks when running: # perf test "88: Check open filename arg using perf trace + vfs_getname" One of these is caused by the lzma stream never being closed inside lzma_decompress_to_file(). This patch adds the missing lzma_end(). Signed-off-by: Riccardo Mancini Fixes: 80a32e5b498a7547 ("perf tools: Add lzma decompression support for kernel module") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/aaf50bdce7afe996cfc06e1bbb36e4a2a9b9db93.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2ae8f40a8fdfc013ab9fb5440b2e570c1e4f1708 Author: Riccardo Mancini Date: Thu Jul 15 18:07:18 2021 +0200 perf script: Fix memory 'threads' and 'cpus' leaks on exit [ Upstream commit faf3ac305d61341c74e5cdd9e41daecce7f67bfe ] ASan reports several memory leaks while running: # perf test "82: Use vfs_getname probe to get syscall args filenames" Two of these are caused by some refcounts not being decreased on perf-script exit, namely script.threads and script.cpus. This patch adds the missing __put calls in a new perf_script__exit function, which is called at the end of cmd_script. This patch concludes the fixes of all remaining memory leaks in perf test "82: Use vfs_getname probe to get syscall args filenames". Signed-off-by: Riccardo Mancini Fixes: cfc8874a48599249 ("perf script: Process cpu/threads maps") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/5ee73b19791c6fa9d24c4d57f4ac1a23609400d7.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 51077d315a4698eaba72010cf0781b6189a8bf8c Author: Riccardo Mancini Date: Thu Jul 15 18:07:14 2021 +0200 perf report: Free generated help strings for sort option [ Upstream commit a37338aad8c4d8676173ead14e881d2ec308155c ] ASan reports the memory leak of the strings allocated by sort_help() when running perf report. This patch changes the returned pointer to char* (instead of const char*), saves it in a temporary variable, and finally deallocates it at function exit. Signed-off-by: Riccardo Mancini Fixes: 702fb9b415e7c99b ("perf report: Show all sort keys in help output") Cc: Andi Kleen Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/a38b13f02812a8a6759200b9063c6191337f44d4.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2bfa3c53ea8a1dc5e485f0b656285048ef106810 Author: Riccardo Mancini Date: Thu Jul 15 18:07:13 2021 +0200 perf env: Fix memory leak of cpu_pmu_caps [ Upstream commit da6b7c6c0626901428245f65712385805e42eba6 ] ASan reports memory leaks while running: # perf test "83: Zstd perf.data compression/decompression" The first of the leaks is caused by env->cpu_pmu_caps not being freed. This patch adds the missing (z)free inside perf_env__exit. Signed-off-by: Riccardo Mancini Fixes: 6f91ea283a1ed23e ("perf header: Support CPU PMU capabilities") Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/6ba036a8220156ec1f3d6be3e5d25920f6145028.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a2f0da3af61455cdd86dc13bc305e50db58a5b08 Author: Riccardo Mancini Date: Thu Jul 15 18:07:12 2021 +0200 perf test maps__merge_in: Fix memory leak of maps [ Upstream commit 244d1797c8c8e850b8de7992af713aa5c70d5650 ] ASan reports a memory leak when running: # perf test "65: maps__merge_in" This is the second and final patch addressing these memory leaks. This time, the problem is simply that the maps object is never destructed. This patch adds the missing maps__exit call. Signed-off-by: Riccardo Mancini Fixes: 79b6bb73f888933c ("perf maps: Merge 'struct maps' with 'struct map_groups'") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/a1a29b97a58738987d150e94d4ebfad0282fb038.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b7bfd8aeb95622f5bd1b4fa229ceb0b88ed4ef5a Author: Riccardo Mancini Date: Thu Jul 15 18:07:11 2021 +0200 perf dso: Fix memory leak in dso__new_map() [ Upstream commit 581e295a0f6b5c2931d280259fbbfff56959faa9 ] ASan reports a memory leak when running: # perf test "65: maps__merge_in". The causes of the leaks are two, this patch addresses only the first one, which is related to dso__new_map(). The bug is that dso__new_map() creates a new dso but never decreases the refcount it gets from creating it. This patch adds the missing dso__put(). Signed-off-by: Riccardo Mancini Fixes: d3a7c489c7fd2463 ("perf tools: Reference count struct dso") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/60bfe0cd06e89e2ca33646eb8468d7f5de2ee597.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit c9c101da3e83563e595693282167c04592b5536d Author: Riccardo Mancini Date: Thu Jul 15 18:07:09 2021 +0200 perf test event_update: Fix memory leak of evlist [ Upstream commit fc56f54f6fcd5337634f4545af6459613129b432 ] ASan reports a memory leak when running: # perf test "49: Synthesize attr update" Caused by evlist not being deleted. This patch adds the missing evlist__delete and removes the perf_cpu_map__put since it's already being deleted by evlist__delete. Signed-off-by: Riccardo Mancini Fixes: a6e5281780d1da65 ("perf tools: Add event_update event unit type") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/f7994ad63d248f7645f901132d208fadf9f2b7e4.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b768db7f8070617405ab02fffe1b7a0633fcac63 Author: Riccardo Mancini Date: Thu Jul 15 18:07:08 2021 +0200 perf test session_topology: Delete session->evlist [ Upstream commit 233f2dc1c284337286f9a64c0152236779a42f6c ] ASan reports a memory leak related to session->evlist while running: # perf test "41: Session topology". When perf_data is in write mode, session->evlist is owned by the caller, which should also take care of deleting it. This patch adds the missing evlist__delete(). Signed-off-by: Riccardo Mancini Fixes: c84974ed9fb67293 ("perf test: Add entry to test cpu topology") Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/822f741f06eb25250fb60686cf30a35f447e9e91.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b8892d16a9287c1b3f57fa7480188da13b14e30d Author: Riccardo Mancini Date: Thu Jul 15 18:07:07 2021 +0200 perf env: Fix sibling_dies memory leak [ Upstream commit 42db3d9ded555f7148b5695109a7dc8d66f0dde4 ] ASan reports a memory leak in perf_env while running: # perf test "41: Session topology" Caused by sibling_dies not being freed. This patch adds the required free. Fixes: acae8b36cded0ee6 ("perf header: Add die information in CPU topology") Signed-off-by: Riccardo Mancini Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/2140d0b57656e4eb9021ca9772250c24c032924b.1626343282.git.rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 306411a8bf75568380bf00f37eb535c7c09eef0d Author: Riccardo Mancini Date: Thu Jul 15 18:07:06 2021 +0200 perf probe: Fix dso->nsinfo refcounting [ Upstream commit dedeb4be203b382ba7245d13079bc3b0f6d40c65 ] ASan reports a memory leak of nsinfo during the execution of: # perf test "31: Lookup mmap thread". The leak is caused by a refcounted variable being replaced without dropping the refcount. This patch makes sure that the refcnt of nsinfo is decreased whenever a refcounted variable is replaced with a new value. Signed-off-by: Riccardo Mancini Fixes: 544abd44c7064c8a ("perf probe: Allow placing uprobes in alternate namespaces.") Cc: Ian Rogers Cc: Jiri Olsa Cc: Krister Johansen Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/55223bc8821b34ccb01f92ef1401c02b6a32e61f.1626343282.git.rickyman7@gmail.com [ Split from a larger patch ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f21987d7bb58f2afbf3e797c9506bb74fd39ef52 Author: Riccardo Mancini Date: Thu Jul 15 18:07:06 2021 +0200 perf map: Fix dso->nsinfo refcounting [ Upstream commit 2d6b74baa7147251c30a46c4996e8cc224aa2dc5 ] ASan reports a memory leak of nsinfo during the execution of # perf test "31: Lookup mmap thread" The leak is caused by a refcounted variable being replaced without dropping the refcount. This patch makes sure that the refcnt of nsinfo is decreased whenever a refcounted variable is replaced with a new value. Signed-off-by: Riccardo Mancini Fixes: bf2e710b3cb8445c ("perf maps: Lookup maps in both intitial mountns and inner mountns.") Cc: Ian Rogers Cc: Jiri Olsa Cc: Krister Johansen Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/55223bc8821b34ccb01f92ef1401c02b6a32e61f.1626343282.git.rickyman7@gmail.com [ Split from a larger patch ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7337ff2093e0ebb17d6b760c39a6d5dc96748c97 Author: Riccardo Mancini Date: Thu Jul 15 18:07:06 2021 +0200 perf inject: Fix dso->nsinfo refcounting [ Upstream commit 0967ebffe098157180a0bbd180ac90348c6e07d7 ] ASan reports a memory leak of nsinfo during the execution of: # perf test "31: Lookup mmap thread" The leak is caused by a refcounted variable being replaced without dropping the refcount. This patch makes sure that the refcnt of nsinfo is decreased when a refcounted variable is replaced with a new value. Signed-off-by: Riccardo Mancini Fixes: 27c9c3424fc217da ("perf inject: Add --buildid-all option") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/55223bc8821b34ccb01f92ef1401c02b6a32e61f.1626343282.git.rickyman7@gmail.com [ Split from a larger patch ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a87d42ae7f5db37fe3a1f93a6fcb28befe66d7fc Author: Like Xu Date: Mon Jun 28 15:43:54 2021 +0800 KVM: x86/pmu: Clear anythread deprecated bit when 0xa leaf is unsupported on the SVM [ Upstream commit 7234c362ccb3c2228f06f19f93b132de9cfa7ae4 ] The AMD platform does not support the functions Ah CPUID leaf. The returned results for this entry should all remain zero just like the native does: AMD host: 0x0000000a 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 (uncanny) AMD guest: 0x0000000a 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00008000 Fixes: cadbaa039b99 ("perf/x86/intel: Make anythread filter support conditional") Signed-off-by: Like Xu Message-Id: <20210628074354.33848-1-likexu@tencent.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit b990585f9b7a81f7eaa7d63b353037159d6c5ddb Author: Casey Chen Date: Wed Jul 7 14:14:32 2021 -0700 nvme-pci: do not call nvme_dev_remove_admin from nvme_remove [ Upstream commit 251ef6f71be2adfd09546a26643426fe62585173 ] nvme_dev_remove_admin could free dev->admin_q and the admin_tagset while they are being accessed by nvme_dev_disable(), which can be called by nvme_reset_work via nvme_remove_dead_ctrl. Commit cb4bfda62afa ("nvme-pci: fix hot removal during error handling") intended to avoid requests being stuck on a removed controller by killing the admin queue. But the later fix c8e9e9b7646e ("nvme-pci: unquiesce admin queue on shutdown"), together with nvme_dev_disable(dev, true) right before nvme_dev_remove_admin() could help dispatch requests and fail them early, so we don't need nvme_dev_remove_admin() any more. Fixes: cb4bfda62afa ("nvme-pci: fix hot removal during error handling") Signed-off-by: Casey Chen Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 0fa11e1a20c7af1bdbae463b74cd2ab75864b36a Author: Jianguo Wu Date: Fri Jul 9 17:20:46 2021 -0700 mptcp: fix warning in __skb_flow_dissect() when do syn cookie for subflow join [ Upstream commit 0c71929b5893e410e0efbe1bbeca6f19a5f19956 ] I did stress test with wrk[1] and webfsd[2] with the assistance of mptcp-tools[3]: Server side: ./use_mptcp.sh webfsd -4 -R /tmp/ -p 8099 Client side: ./use_mptcp.sh wrk -c 200 -d 30 -t 4 http://192.168.174.129:8099/ and got the following warning message: [ 55.552626] TCP: request_sock_subflow: Possible SYN flooding on port 8099. Sending cookies. Check SNMP counters. [ 55.553024] ------------[ cut here ]------------ [ 55.553027] WARNING: CPU: 0 PID: 10 at net/core/flow_dissector.c:984 __skb_flow_dissect+0x280/0x1650 ... [ 55.553117] CPU: 0 PID: 10 Comm: ksoftirqd/0 Not tainted 5.12.0+ #18 [ 55.553121] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 [ 55.553124] RIP: 0010:__skb_flow_dissect+0x280/0x1650 ... [ 55.553133] RSP: 0018:ffffb79580087770 EFLAGS: 00010246 [ 55.553137] RAX: 0000000000000000 RBX: ffffffff8ddb58e0 RCX: ffffb79580087888 [ 55.553139] RDX: ffffffff8ddb58e0 RSI: ffff8f7e4652b600 RDI: 0000000000000000 [ 55.553141] RBP: ffffb79580087858 R08: 0000000000000000 R09: 0000000000000008 [ 55.553143] R10: 000000008c622965 R11: 00000000d3313a5b R12: ffff8f7e4652b600 [ 55.553146] R13: ffff8f7e465c9062 R14: 0000000000000000 R15: ffffb79580087888 [ 55.553149] FS: 0000000000000000(0000) GS:ffff8f7f75e00000(0000) knlGS:0000000000000000 [ 55.553152] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 55.553154] CR2: 00007f73d1d19000 CR3: 0000000135e10004 CR4: 00000000003706f0 [ 55.553160] Call Trace: [ 55.553166] ? __sha256_final+0x67/0xd0 [ 55.553173] ? sha256+0x7e/0xa0 [ 55.553177] __skb_get_hash+0x57/0x210 [ 55.553182] subflow_init_req_cookie_join_save+0xac/0xc0 [ 55.553189] subflow_check_req+0x474/0x550 [ 55.553195] ? ip_route_output_key_hash+0x67/0x90 [ 55.553200] ? xfrm_lookup_route+0x1d/0xa0 [ 55.553207] subflow_v4_route_req+0x8e/0xd0 [ 55.553212] tcp_conn_request+0x31e/0xab0 [ 55.553218] ? selinux_socket_sock_rcv_skb+0x116/0x210 [ 55.553224] ? tcp_rcv_state_process+0x179/0x6d0 [ 55.553229] tcp_rcv_state_process+0x179/0x6d0 [ 55.553235] tcp_v4_do_rcv+0xaf/0x220 [ 55.553239] tcp_v4_rcv+0xce4/0xd80 [ 55.553243] ? ip_route_input_rcu+0x246/0x260 [ 55.553248] ip_protocol_deliver_rcu+0x35/0x1b0 [ 55.553253] ip_local_deliver_finish+0x44/0x50 [ 55.553258] ip_local_deliver+0x6c/0x110 [ 55.553262] ? ip_rcv_finish_core.isra.19+0x5a/0x400 [ 55.553267] ip_rcv+0xd1/0xe0 ... After debugging, I found in __skb_flow_dissect(), skb->dev and skb->sk are both NULL, then net is NULL, and trigger WARN_ON_ONCE(!net), actually net is always NULL in this code path, as skb->dev is set to NULL in tcp_v4_rcv(), and skb->sk is never set. Code snippet in __skb_flow_dissect() that trigger warning: 975 if (skb) { 976 if (!net) { 977 if (skb->dev) 978 net = dev_net(skb->dev); 979 else if (skb->sk) 980 net = sock_net(skb->sk); 981 } 982 } 983 984 WARN_ON_ONCE(!net); So, using seq and transport header derived hash. [1] https://github.com/wg/wrk [2] https://github.com/ourway/webfsd [3] https://github.com/pabeni/mptcp-tools Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use") Suggested-by: Paolo Abeni Suggested-by: Florian Westphal Signed-off-by: Jianguo Wu Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3714e0bb0dcfcb65a16296a54b7969a2f4c2d550 Author: Shahjada Abul Husain Date: Thu Jul 8 21:51:56 2021 +0530 cxgb4: fix IRQ free race during driver unload [ Upstream commit 015fe6fd29c4b9ac0f61b8c4455ef88e6018b9cc ] IRQs are requested during driver's ndo_open() and then later freed up in disable_interrupts() during driver unload. A race exists where driver can set the CXGB4_FULL_INIT_DONE flag in ndo_open() after the disable_interrupts() in driver unload path checks it, and hence misses calling free_irq(). Fix by unregistering netdevice first and sync with driver's ndo_open(). This ensures disable_interrupts() checks the flag correctly and frees up the IRQs properly. Fixes: b37987e8db5f ("cxgb4: Disable interrupts and napi before unregistering netdev") Signed-off-by: Shahjada Abul Husain Signed-off-by: Raju Rangoju Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d92337bf54f27ee5a240ce5a168bf6dd6401b9f6 Author: Uwe Kleine-König Date: Thu Jul 1 10:27:51 2021 +0200 pwm: sprd: Ensure configuring period and duty_cycle isn't wrongly skipped [ Upstream commit 65e2e6c1c20104ed19060a38f4edbf14e9f9a9a5 ] As the last call to sprd_pwm_apply() might have exited early if state->enabled was false, the values for period and duty_cycle stored in pwm->state might not have been written to hardware and it must be ensured that they are configured before enabling the PWM. Fixes: 8aae4b02e8a6 ("pwm: sprd: Add Spreadtrum PWM support") Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit f1edbcc47f460a255c459e3fbb3751d735093011 Author: Hangbin Liu Date: Wed Jul 7 16:15:30 2021 +0800 selftests: icmp_redirect: IPv6 PMTU info should be cleared after redirect [ Upstream commit 0e02bf5de46ae30074a2e1a8194a422a84482a1a ] After redirecting, it's already a new path. So the old PMTU info should be cleared. The IPv6 test "mtu exception plus redirect" should only has redirect info without old PMTU. The IPv4 test can not be changed because of legacy. Fixes: ec8105352869 ("selftests: Add redirect tests") Signed-off-by: Hangbin Liu Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 906bbb18db782d8d7f77764bbf69d5733796870a Author: Hangbin Liu Date: Wed Jul 7 16:15:29 2021 +0800 selftests: icmp_redirect: remove from checking for IPv6 route get [ Upstream commit 24b671aad4eae423e1abf5b7f08d9a5235458b8d ] If the kernel doesn't enable option CONFIG_IPV6_SUBTREES, the RTA_SRC info will not be exported to userspace in rt6_fill_node(). And ip cmd will not print "from ::" to the route output. So remove this check. Fixes: ec8105352869 ("selftests: Add redirect tests") Signed-off-by: Hangbin Liu Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bb737eceb9a40ac596978bcda657763010e996dd Author: YueHaibing Date: Wed Jul 7 15:53:35 2021 +0800 stmmac: platform: Fix signedness bug in stmmac_probe_config_dt() [ Upstream commit eca81f09145d765c21dd8fb1ba5d874ca255c32c ] The "plat->phy_interface" variable is an enum and in this context GCC will treat it as an unsigned int so the error handling is never triggered. Fixes: b9f0b2f634c0 ("net: stmmac: platform: fix probe for ACPI devices") Signed-off-by: YueHaibing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 79ec7b5b2f4fe38e5c7459ed0bdff4ef3386ab63 Author: Nicolas Dichtel Date: Tue Jul 6 11:13:35 2021 +0200 ipv6: fix 'disable_policy' for fwd packets [ Upstream commit ccd27f05ae7b8ebc40af5b004e94517a919aa862 ] The goal of commit df789fe75206 ("ipv6: Provide ipv6 version of "disable_policy" sysctl") was to have the disable_policy from ipv4 available on ipv6. However, it's not exactly the same mechanism. On IPv4, all packets coming from an interface, which has disable_policy set, bypass the policy check. For ipv6, this is done only for local packets, ie for packets destinated to an address configured on the incoming interface. Let's align ipv6 with ipv4 so that the 'disable_policy' sysctl has the same effect for both protocols. My first approach was to create a new kind of route cache entries, to be able to set DST_NOPOLICY without modifying routes. This would have added a lot of code. Because the local delivery path is already handled, I choose to focus on the forwarding path to minimize code churn. Fixes: df789fe75206 ("ipv6: Provide ipv6 version of "disable_policy" sysctl") Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 35eaefb44ed7dbcc361b2513bf136264624ddd2b Author: Taehee Yoo Date: Mon Jul 5 15:38:14 2021 +0000 bonding: fix incorrect return value of bond_ipsec_offload_ok() [ Upstream commit 168e696a36792a4a3b2525a06249e7472ef90186 ] bond_ipsec_offload_ok() is called to check whether the interface supports ipsec offload or not. bonding interface support ipsec offload only in active-backup mode. So, if a bond interface is not in active-backup mode, it should return false but it returns true. Fixes: a3b658cfb664 ("bonding: allow xfrm offload setup post-module-load") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 13626bad63e82564fc6b2d083e1d58d589d64cf2 Author: Taehee Yoo Date: Mon Jul 5 15:38:13 2021 +0000 bonding: fix suspicious RCU usage in bond_ipsec_offload_ok() [ Upstream commit 955b785ec6b3b2f9b91914d6eeac8ee66ee29239 ] To dereference bond->curr_active_slave, it uses rcu_dereference(). But it and the caller doesn't acquire RCU so a warning occurs. So add rcu_read_lock(). Splat looks like: WARNING: suspicious RCU usage 5.13.0-rc6+ #1179 Not tainted drivers/net/bonding/bond_main.c:571 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ping/974: #0: ffff888109e7db70 (sk_lock-AF_INET){+.+.}-{0:0}, at: raw_sendmsg+0x1303/0x2cb0 stack backtrace: CPU: 2 PID: 974 Comm: ping Not tainted 5.13.0-rc6+ #1179 Call Trace: dump_stack+0xa4/0xe5 bond_ipsec_offload_ok+0x1f4/0x260 [bonding] xfrm_output+0x179/0x890 xfrm4_output+0xfa/0x410 ? __xfrm4_output+0x4b0/0x4b0 ? __ip_make_skb+0xecc/0x2030 ? xfrm4_udp_encap_rcv+0x800/0x800 ? ip_local_out+0x21/0x3a0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1bfd/0x2cb0 Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 56ccdf868ab6010739a24a3d72c3e53fd0e1ace2 Author: Taehee Yoo Date: Mon Jul 5 15:38:12 2021 +0000 bonding: Add struct bond_ipesc to manage SA [ Upstream commit 9a5605505d9c7dbfdb89cc29a8f5fc5cf9fd2334 ] bonding has been supporting ipsec offload. When SA is added, bonding just passes SA to its own active real interface. But it doesn't manage SA. So, when events(add/del real interface, active real interface change, etc) occur, bonding can't handle that well because It doesn't manage SA. So some problems(panic, UAF, refcnt leak)occur. In order to make it stable, it should manage SA. That's the reason why struct bond_ipsec is added. When a new SA is added to bonding interface, it is stored in the bond_ipsec list. And the SA is passed to a current active real interface. If events occur, it uses bond_ipsec data to handle these events. bond->ipsec_list is protected by bond->ipsec_lock. If a current active real interface is changed, the following logic works. 1. delete all SAs from old active real interface 2. Add all SAs to the new active real interface. 3. If a new active real interface doesn't support ipsec offload or SA's option, it sets real_dev to NULL. Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b3bd1f5e503716e09610e49bdccc36ed9356d27c Author: Taehee Yoo Date: Mon Jul 5 15:38:11 2021 +0000 bonding: disallow setting nested bonding + ipsec offload [ Upstream commit b121693381b112b78c076dea171ee113e237c0e4 ] bonding interface can be nested and it supports ipsec offload. So, it allows setting the nested bonding + ipsec scenario. But code does not support this scenario. So, it should be disallowed. interface graph: bond2 | bond1 | eth0 The nested bonding + ipsec offload may not a real usecase. So, disallowing this scenario is fine. Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 43511a6a164acbf0d466c175e8e117039df7465c Author: Taehee Yoo Date: Mon Jul 5 15:38:10 2021 +0000 bonding: fix suspicious RCU usage in bond_ipsec_del_sa() [ Upstream commit a22c39b831a081da9b2c488bd970a4412d926f30 ] To dereference bond->curr_active_slave, it uses rcu_dereference(). But it and the caller doesn't acquire RCU so a warning occurs. So add rcu_read_lock(). Test commands: ip netns add A ip netns exec A bash modprobe netdevsim echo "1 1" > /sys/bus/netdevsim/new_device ip link add bond0 type bond ip link set eth0 master bond0 ip link set eth0 up ip link set bond0 up ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi 0x07 mode \ transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \ 0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 \ dst 14.0.0.70/24 proto tcp offload dev bond0 dir in ip x s f Splat looks like: ============================= WARNING: suspicious RCU usage 5.13.0-rc3+ #1168 Not tainted ----------------------------- drivers/net/bonding/bond_main.c:448 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by ip/705: #0: ffff888106701780 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{3:3}, at: xfrm_netlink_rcv+0x59/0x80 [xfrm_user] #1: ffff8880075b0098 (&x->lock){+.-.}-{2:2}, at: xfrm_state_delete+0x16/0x30 stack backtrace: CPU: 6 PID: 705 Comm: ip Not tainted 5.13.0-rc3+ #1168 Call Trace: dump_stack+0xa4/0xe5 bond_ipsec_del_sa+0x16a/0x1c0 [bonding] __xfrm_state_delete+0x51f/0x730 xfrm_state_delete+0x1e/0x30 xfrm_state_flush+0x22f/0x390 xfrm_flush_sa+0xd8/0x260 [xfrm_user] ? xfrm_flush_policy+0x290/0x290 [xfrm_user] xfrm_user_rcv_msg+0x331/0x660 [xfrm_user] ? rcu_read_lock_sched_held+0x91/0xc0 ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user] ? find_held_lock+0x3a/0x1c0 ? mutex_lock_io_nested+0x1210/0x1210 ? sched_clock_cpu+0x18/0x170 netlink_rcv_skb+0x121/0x350 [ ... ] Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6ca0e55a1310cf5d512e08d2d641165a0cfc67f7 Author: Taehee Yoo Date: Mon Jul 5 15:38:09 2021 +0000 ixgbevf: use xso.real_dev instead of xso.dev in callback functions of struct xfrmdev_ops [ Upstream commit 2de7e4f67599affc97132bd07e30e3bd59d0b777 ] There are two pointers in struct xfrm_state_offload, *dev, *real_dev. These are used in callback functions of struct xfrmdev_ops. The *dev points whether bonding interface or real interface. If bonding ipsec offload is used, it points bonding interface If not, it points real interface. And real_dev always points real interface. So, ixgbevf should always use real_dev instead of dev. Of course, real_dev always not be null. Test commands: ip link add bond0 type bond #eth0 is ixgbevf interface ip link set eth0 master bond0 ip link set bond0 up ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi 0x07 mode \ transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \ 0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 \ dst 14.0.0.70/24 proto tcp offload dev bond0 dir in Splat looks like: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 6 PID: 688 Comm: ip Not tainted 5.13.0-rc3+ #1168 RIP: 0010:ixgbevf_ipsec_find_empty_idx+0x28/0x1b0 [ixgbevf] Code: 00 00 0f 1f 44 00 00 55 53 48 89 fb 48 83 ec 08 40 84 f6 0f 84 9c 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 01 0f 8e 4c 01 00 00 66 81 3b 00 04 0f RSP: 0018:ffff8880089af390 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff8880089af4f8 R08: 0000000000000003 R09: fffffbfff4287e11 R10: 0000000000000001 R11: ffff888005de8908 R12: 0000000000000000 R13: ffff88810936a000 R14: ffff88810936a000 R15: ffff888004d78040 FS: 00007fdf9883a680(0000) GS:ffff88811a400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055bc14adbf40 CR3: 000000000b87c005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ixgbevf_ipsec_add_sa+0x1bf/0x9c0 [ixgbevf] ? rcu_read_lock_sched_held+0x91/0xc0 ? ixgbevf_ipsec_parse_proto_keys.isra.9+0x280/0x280 [ixgbevf] ? lock_acquire+0x191/0x720 ? bond_ipsec_add_sa+0x48/0x350 [bonding] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0 ? rcu_read_lock_held+0x91/0xa0 ? rcu_read_lock_sched_held+0xc0/0xc0 bond_ipsec_add_sa+0x193/0x350 [bonding] xfrm_dev_state_add+0x2a9/0x770 ? memcpy+0x38/0x60 xfrm_add_sa+0x2278/0x3b10 [xfrm_user] ? xfrm_get_policy+0xaa0/0xaa0 [xfrm_user] ? register_lock_class+0x1750/0x1750 xfrm_user_rcv_msg+0x331/0x660 [xfrm_user] ? rcu_read_lock_sched_held+0x91/0xc0 ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user] ? find_held_lock+0x3a/0x1c0 ? mutex_lock_io_nested+0x1210/0x1210 ? sched_clock_cpu+0x18/0x170 netlink_rcv_skb+0x121/0x350 [ ... ] Fixes: 272c2330adc9 ("xfrm: bail early on slave pass over skb") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ba7bfcdff1ad4ea475395079add1cd7b79f81684 Author: Taehee Yoo Date: Mon Jul 5 15:38:07 2021 +0000 bonding: fix null dereference in bond_ipsec_add_sa() [ Upstream commit 105cd17a866017b45f3c45901b394c711c97bf40 ] If bond doesn't have real device, bond->curr_active_slave is null. But bond_ipsec_add_sa() dereferences bond->curr_active_slave without null checking. So, null-ptr-deref would occur. Test commands: ip link add bond0 type bond ip link set bond0 up ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi \ 0x07 mode transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \ 0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 \ dst 14.0.0.70/24 proto tcp offload dev bond0 dir in Splat looks like: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 4 PID: 680 Comm: ip Not tainted 5.13.0-rc3+ #1168 RIP: 0010:bond_ipsec_add_sa+0xc4/0x2e0 [bonding] Code: 85 21 02 00 00 4d 8b a6 48 0c 00 00 e8 75 58 44 ce 85 c0 0f 85 14 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 fc 01 00 00 48 8d bb e0 02 00 00 4d 8b 2c 24 48 RSP: 0018:ffff88810946f508 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88810b4e8040 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffffff8fe34280 RDI: ffff888115abe100 RBP: ffff88810946f528 R08: 0000000000000003 R09: fffffbfff2287e11 R10: 0000000000000001 R11: ffff888115abe0c8 R12: 0000000000000000 R13: ffffffffc0aea9a0 R14: ffff88800d7d2000 R15: ffff88810b4e8330 FS: 00007efc5552e680(0000) GS:ffff888119c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055c2530dbf40 CR3: 0000000103056004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: xfrm_dev_state_add+0x2a9/0x770 ? memcpy+0x38/0x60 xfrm_add_sa+0x2278/0x3b10 [xfrm_user] ? xfrm_get_policy+0xaa0/0xaa0 [xfrm_user] ? register_lock_class+0x1750/0x1750 xfrm_user_rcv_msg+0x331/0x660 [xfrm_user] ? rcu_read_lock_sched_held+0x91/0xc0 ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user] ? find_held_lock+0x3a/0x1c0 ? mutex_lock_io_nested+0x1210/0x1210 ? sched_clock_cpu+0x18/0x170 netlink_rcv_skb+0x121/0x350 ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user] ? netlink_ack+0x9d0/0x9d0 ? netlink_deliver_tap+0x17c/0xa50 xfrm_netlink_rcv+0x68/0x80 [xfrm_user] netlink_unicast+0x41c/0x610 ? netlink_attachskb+0x710/0x710 netlink_sendmsg+0x6b9/0xb70 [ ...] Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3ae639af362661c6566b326ad8ccf5e561cebf54 Author: Taehee Yoo Date: Mon Jul 5 15:38:06 2021 +0000 bonding: fix suspicious RCU usage in bond_ipsec_add_sa() [ Upstream commit b648eba4c69e5819880b4907e7fcb2bb576069ab ] To dereference bond->curr_active_slave, it uses rcu_dereference(). But it and the caller doesn't acquire RCU so a warning occurs. So add rcu_read_lock(). Test commands: ip link add dummy0 type dummy ip link add bond0 type bond ip link set dummy0 master bond0 ip link set dummy0 up ip link set bond0 up ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi 0x07 \ mode transport \ reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \ 0x44434241343332312423222114131211f4f3f2f1 128 sel \ src 14.0.0.52/24 dst 14.0.0.70/24 proto tcp offload \ dev bond0 dir in Splat looks like: ============================= WARNING: suspicious RCU usage 5.13.0-rc3+ #1168 Not tainted ----------------------------- drivers/net/bonding/bond_main.c:411 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/684: #0: ffffffff9a2757c0 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{3:3}, at: xfrm_netlink_rcv+0x59/0x80 [xfrm_user] 55.191733][ T684] stack backtrace: CPU: 0 PID: 684 Comm: ip Not tainted 5.13.0-rc3+ #1168 Call Trace: dump_stack+0xa4/0xe5 bond_ipsec_add_sa+0x18c/0x1f0 [bonding] xfrm_dev_state_add+0x2a9/0x770 ? memcpy+0x38/0x60 xfrm_add_sa+0x2278/0x3b10 [xfrm_user] ? xfrm_get_policy+0xaa0/0xaa0 [xfrm_user] ? register_lock_class+0x1750/0x1750 xfrm_user_rcv_msg+0x331/0x660 [xfrm_user] ? rcu_read_lock_sched_held+0x91/0xc0 ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user] ? find_held_lock+0x3a/0x1c0 ? mutex_lock_io_nested+0x1210/0x1210 ? sched_clock_cpu+0x18/0x170 netlink_rcv_skb+0x121/0x350 ? xfrm_user_state_lookup.constprop.39+0x320/0x320 [xfrm_user] ? netlink_ack+0x9d0/0x9d0 ? netlink_deliver_tap+0x17c/0xa50 xfrm_netlink_rcv+0x68/0x80 [xfrm_user] netlink_unicast+0x41c/0x610 ? netlink_attachskb+0x710/0x710 netlink_sendmsg+0x6b9/0xb70 [ ... ] Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4a31baf55f6af1cae76db61e33df345d3fbee900 Author: Aleksandr Nogikh Date: Thu Oct 29 17:36:19 2020 +0000 net: add kcov handle to skb extensions [ Upstream commit 6370cc3bbd8a0f9bf975b013781243ab147876c6 ] Remote KCOV coverage collection enables coverage-guided fuzzing of the code that is not reachable during normal system call execution. It is especially helpful for fuzzing networking subsystems, where it is common to perform packet handling in separate work queues even for the packets that originated directly from the user space. Enable coverage-guided frame injection by adding kcov remote handle to skb extensions. Default initialization in __alloc_skb and __build_skb_around ensures that no socket buffer that was generated during a system call will be missed. Code that is of interest and that performs packet processing should be annotated with kcov_remote_start()/kcov_remote_stop(). An alternative approach is to determine kcov_handle solely on the basis of the device/interface that received the specific socket buffer. However, in this case it would be impossible to distinguish between packets that originated during normal background network processes or were intentionally injected from the user space. Signed-off-by: Aleksandr Nogikh Acked-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 78e4baff950d9fc78752f028200f501897ff84a7 Author: Christophe JAILLET Date: Thu Jul 1 22:18:24 2021 +0200 gve: Fix an error handling path in 'gve_probe()' [ Upstream commit 2342ae10d1272d411a468a85a67647dd115b344f ] If the 'register_netdev() call fails, we must release the resources allocated by the previous 'gve_init_priv()' call, as already done in the remove function. Add a new label and the missing 'gve_teardown_priv_resources()' in the error handling path. Fixes: 893ce44df565 ("gve: Add basic driver framework for Compute Engine Virtual NIC") Signed-off-by: Christophe JAILLET Reviewed-by: Catherine Sullivan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 813449fb85f605fba071b6f83d1e53204effe8de Author: Jedrzej Jagielski Date: Fri Jun 11 22:42:17 2021 +0000 igb: Fix position of assignment to *ring [ Upstream commit 382a7c20d9253bcd5715789b8179528d0f3de72c ] Assignment to *ring should be done after correctness check of the argument queue. Fixes: 91db364236c8 ("igb: Refactor igb_configure_cbs()") Signed-off-by: Jedrzej Jagielski Acked-by: Vinicius Costa Gomes Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 44171801d39cb22f2e684d5d5aed049ef83738cc Author: Aleksandr Loktionov Date: Thu Apr 22 10:19:23 2021 +0000 igb: Check if num of q_vectors is smaller than max before array access [ Upstream commit 6c19d772618fea40d9681f259368f284a330fd90 ] Ensure that the adapter->q_vector[MAX_Q_VECTORS] array isn't accessed beyond its size. It was fixed by using a local variable num_q_vectors as a limit for loop index, and ensure that num_q_vectors is not bigger than MAX_Q_VECTORS. Fixes: 047e0030f1e6 ("igb: add new data structure for handling interrupts and NAPI") Signed-off-by: Aleksandr Loktionov Reviewed-by: Grzegorz Siwik Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Slawomir Laba Reviewed-by: Sylwester Dziedziuch Reviewed-by: Mateusz Palczewski Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit cb9292445d234d04bf049856d9a3f51923ff0d18 Author: Christophe JAILLET Date: Wed Jun 16 07:53:02 2021 +0200 iavf: Fix an error handling path in 'iavf_probe()' [ Upstream commit af30cbd2f4d6d66a9b6094e0aa32420bc8b20e08 ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: 5eae00c57f5e ("i40evf: main driver core") Signed-off-by: Christophe JAILLET Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit a6756d637b400bfe161b7bfe1b03fe5605723205 Author: Christophe JAILLET Date: Wed Jun 16 07:05:53 2021 +0200 e1000e: Fix an error handling path in 'e1000_probe()' [ Upstream commit 4589075608420bc49fcef6e98279324bf2bb91ae ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: 111b9dc5c981 ("e1000e: add aer support") Signed-off-by: Christophe JAILLET Acked-by: Sasha Neftin Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit dea695a2ee23f564e080c10a4b0b40d5ad9692be Author: Christophe JAILLET Date: Wed Jun 16 07:00:36 2021 +0200 fm10k: Fix an error handling path in 'fm10k_probe()' [ Upstream commit e85e14d68f517ef12a5fb8123fff65526b35b6cd ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: 19ae1b3fb99c ("fm10k: Add support for PCI power management and error handling") Signed-off-by: Christophe JAILLET Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit a099192fe7e114c8a054db674151bef7ea3a26a1 Author: Christophe JAILLET Date: Sat Jun 12 22:08:33 2021 +0200 igb: Fix an error handling path in 'igb_probe()' [ Upstream commit fea03b1cebd653cd095f2e9a58cfe1c85661c363 ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: 40a914fa72ab ("igb: Add support for pci-e Advanced Error Reporting") Signed-off-by: Christophe JAILLET Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit db4c32c1b926ee76ddeb65e382646b79119c6be3 Author: Christophe JAILLET Date: Sat Jun 12 22:00:05 2021 +0200 igc: Fix an error handling path in 'igc_probe()' [ Upstream commit c6bc9e5ce5d37cb3e6b552f41b92a193db1806ab ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: c9a11c23ceb6 ("igc: Add netdev") Signed-off-by: Christophe JAILLET Tested-by: Dvora Fuxbrumer Acked-by: Sasha Neftin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7bc9fb1f80195f28950d0898f457ae160ab66a7b Author: Christophe JAILLET Date: Sat Jun 12 15:46:09 2021 +0200 ixgbe: Fix an error handling path in 'ixgbe_probe()' [ Upstream commit dd2aefcd5e37989ae5f90afdae44bbbf3a2990da ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: 6fabd715e6d8 ("ixgbe: Implement PCIe AER support") Signed-off-by: Christophe JAILLET Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 02d1af0bee65d8746f5630b648a8778ff57b5a70 Author: Tom Rix Date: Fri May 21 12:50:19 2021 -0700 igc: change default return of igc_read_phy_reg() [ Upstream commit 05682a0a61b6cbecd97a0f37f743b2cbfd516977 ] Static analysis reports this problem igc_main.c:4944:20: warning: The left operand of '&' is a garbage value if (!(phy_data & SR_1000T_REMOTE_RX_STATUS) && ~~~~~~~~ ^ phy_data is set by the call to igc_read_phy_reg() only if there is a read_reg() op, else it is unset and a 0 is returned. Change the return to -EOPNOTSUPP. Fixes: 208983f099d9 ("igc: Add watchdog") Signed-off-by: Tom Rix Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f153664d8e70c11d0371341613651e1130e20240 Author: Vinicius Costa Gomes Date: Thu May 13 17:31:04 2021 -0700 igb: Fix use-after-free error during reset [ Upstream commit 7b292608db23ccbbfbfa50cdb155d01725d7a52e ] Cleans the next descriptor to watch (next_to_watch) when cleaning the TX ring. Failure to do so can cause invalid memory accesses. If igb_poll() runs while the controller is reset this can lead to the driver try to free a skb that was already freed. (The crash is harder to reproduce with the igb driver, but the same potential problem exists as the code is identical to igc) Fixes: 7cc6fd4c60f2 ("igb: Don't bother clearing Tx buffer_info in igb_clean_tx_ring") Signed-off-by: Vinicius Costa Gomes Reported-by: Erez Geva Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e15f629036bac005fc758b4ad17896cf2312add4 Author: Vinicius Costa Gomes Date: Thu May 13 17:31:03 2021 -0700 igc: Fix use-after-free error during reset [ Upstream commit 56ea7ed103b46970e171eb1c95916f393d64eeff ] Cleans the next descriptor to watch (next_to_watch) when cleaning the TX ring. Failure to do so can cause invalid memory accesses. If igc_poll() runs while the controller is being reset this can lead to the driver try to free a skb that was already freed. Log message: [ 101.525242] refcount_t: underflow; use-after-free. [ 101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0 [ 101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E) rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E) soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E) iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E) soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E) [ 101.525303] drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E) e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E) usbcore(E) drm(E) button(E) video(E) [ 101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G E 5.10.30-rt37-tsn1-rt-ipipe #ipipe [ 101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017 [ 101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0 [ 101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48 44 01 01 e8 d1 c6 42 00 <0f> 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3 [ 101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286 [ 101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001 [ 101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff [ 101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50 [ 101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00 [ 101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40 [ 101.525337] FS: 0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000 [ 101.525339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0 [ 101.525343] Call Trace: [ 101.525346] sock_wfree+0x9c/0xa0 [ 101.525353] unix_destruct_scm+0x7b/0xa0 [ 101.525358] skb_release_head_state+0x40/0x90 [ 101.525362] skb_release_all+0xe/0x30 [ 101.525364] napi_consume_skb+0x57/0x160 [ 101.525367] igc_poll+0xb7/0xc80 [igc] [ 101.525376] ? sched_clock+0x5/0x10 [ 101.525381] ? sched_clock_cpu+0xe/0x100 [ 101.525385] net_rx_action+0x14c/0x410 [ 101.525388] __do_softirq+0xe9/0x2f4 [ 101.525391] __local_bh_enable_ip+0xe3/0x110 [ 101.525395] ? irq_finalize_oneshot.part.47+0xe0/0xe0 [ 101.525398] irq_forced_thread_fn+0x6a/0x80 [ 101.525401] irq_thread+0xe8/0x180 [ 101.525403] ? wake_threads_waitq+0x30/0x30 [ 101.525406] ? irq_thread_check_affinity+0xd0/0xd0 [ 101.525408] kthread+0x183/0x1a0 [ 101.525412] ? kthread_park+0x80/0x80 [ 101.525415] ret_from_fork+0x22/0x30 Fixes: 13b5b7fd6a4a ("igc: Add support for Tx/Rx rings") Reported-by: Erez Geva Signed-off-by: Vinicius Costa Gomes Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 71046eac2db9aeccf10763d034a1a123911c9a81 Author: Greg Kroah-Hartman Date: Sun Jul 25 14:36:22 2021 +0200 Linux 5.10.53 Link: https://lore.kernel.org/r/20210722155624.672583740@linuxfoundation.org Link: https://lore.kernel.org/r/20210722184939.163840701@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Fox Chen Tested-by: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 6cd9bd2a2ddb63ecf0b41fe587554ea7c2a61ebe Author: Eric Dumazet Date: Wed Jun 30 09:42:44 2021 -0700 udp: annotate data races around unix_sk(sk)->gso_size commit 18a419bad63b7f68a1979e28459782518e7b6bbe upstream. Accesses to unix_sk(sk)->gso_size are lockless. Add READ_ONCE()/WRITE_ONCE() around them. BUG: KCSAN: data-race in udp_lib_setsockopt / udpv6_sendmsg write to 0xffff88812d78f47c of 2 bytes by task 10849 on cpu 1: udp_lib_setsockopt+0x3b3/0x710 net/ipv4/udp.c:2696 udpv6_setsockopt+0x63/0x90 net/ipv6/udp.c:1630 sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3265 __sys_setsockopt+0x18f/0x200 net/socket.c:2104 __do_sys_setsockopt net/socket.c:2115 [inline] __se_sys_setsockopt net/socket.c:2112 [inline] __x64_sys_setsockopt+0x62/0x70 net/socket.c:2112 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88812d78f47c of 2 bytes by task 10852 on cpu 0: udpv6_sendmsg+0x161/0x16b0 net/ipv6/udp.c:1299 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:642 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2337 ___sys_sendmsg net/socket.c:2391 [inline] __sys_sendmmsg+0x315/0x4b0 net/socket.c:2477 __do_sys_sendmmsg net/socket.c:2506 [inline] __se_sys_sendmmsg net/socket.c:2503 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2503 do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x0000 -> 0x0005 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10852 Comm: syz-executor.0 Not tainted 5.13.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: bec1f6f69736 ("udp: generate gso with UDP_SEGMENT") Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bfdb38a4268a85dcfc7510b4645213e112af0dc7 Author: Linus Walleij Date: Fri Jun 4 01:18:30 2021 +0200 drm/panel: nt35510: Do not fail if DSI read fails commit 1988e0d84161dabd99d1c27033fbd6ee439bf432 upstream. Failing to read the MTP over DSI should not bring down the system and make us bail out from using the display, it turns out that this happens when toggling the display off and on, and that write is often still working so the display output is just fine. Printing an error is enough. Tested by killing the Gnome session repeatedly on the Samsung Skomer. Fixes: 899f24ed8d3a ("drm/panel: Add driver for Novatek NT35510-based panels") Cc: Stephan Gerhold Reported-by: newbyte@disroot.org Acked-by: Stefan Hansson Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210603231830.3200040-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman commit 0d90d8492fb95c0f3d8906151c6914711db6c85b Author: Riccardo Mancini Date: Thu Jul 15 18:07:24 2021 +0200 perf test bpf: Free obj_buf commit 937654ce497fb6e977a8c52baee5f7d9616302d9 upstream. ASan reports some memory leaks when running: # perf test "42: BPF filter" The first of these leaks is caused by obj_buf never being deallocated in __test__bpf. This patch adds the missing free. Signed-off-by: Riccardo Mancini Fixes: ba1fae431e74bb42 ("perf test: Add 'perf test BPF'") Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan Link: http://lore.kernel.org/lkml/60f3ca935fe6672e7e866276ce6264c9e26e4c87.1626343282.git.rickyman7@gmail.com [ Added missing stdlib.h include ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit a9f36bf3613c65cb587c70fac655c775d911409b Author: John Fastabend Date: Wed Jul 7 15:38:47 2021 -0700 bpf: Track subprog poke descriptors correctly and fix use-after-free commit f263a81451c12da5a342d90572e317e611846f2c upstream. Subprograms are calling map_poke_track(), but on program release there is no hook to call map_poke_untrack(). However, on program release, the aux memory (and poke descriptor table) is freed even though we still have a reference to it in the element list of the map aux data. When we run map_poke_run(), we then end up accessing free'd memory, triggering KASAN in prog_array_map_poke_run(): [...] [ 402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337 [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399 [ 402.824715] Call Trace: [ 402.824719] dump_stack+0x93/0xc2 [ 402.824727] print_address_description.constprop.0+0x1a/0x140 [ 402.824736] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824744] kasan_report.cold+0x7c/0xd8 [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824757] prog_array_map_poke_run+0xc2/0x34e [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0 [...] The elements concerned are walked as follows: for (i = 0; i < elem->aux->size_poke_tab; i++) { poke = &elem->aux->poke_tab[i]; [...] The access to size_poke_tab is a 4 byte read, verified by checking offsets in the KASAN dump: [ 402.825004] The buggy address belongs to the object at ffff8881905a7800 which belongs to the cache kmalloc-1k of size 1024 [ 402.825008] The buggy address is located 320 bytes inside of 1024-byte region [ffff8881905a7800, ffff8881905a7c00) The pahole output of bpf_prog_aux: struct bpf_prog_aux { [...] /* --- cacheline 5 boundary (320 bytes) --- */ u32 size_poke_tab; /* 320 4 */ [...] In general, subprograms do not necessarily manage their own data structures. For example, BTF func_info and linfo are just pointers to the main program structure. This allows reference counting and cleanup to be done on the latter which simplifies their management a bit. The aux->poke_tab struct, however, did not follow this logic. The initial proposed fix for this use-after-free bug further embedded poke data tracking into the subprogram with proper reference counting. However, Daniel and Alexei questioned why we were treating these objects special; I agree, its unnecessary. The fix here removes the per subprogram poke table allocation and map tracking and instead simply points the aux->poke_tab pointer at the main programs poke table. This way, map tracking is simplified to the main program and we do not need to manage them per subprogram. This also means, bpf_prog_free_deferred(), which unwinds the program reference counting and kfrees objects, needs to ensure that we don't try to double free the poke_tab when free'ing the subprog structures. This is easily solved by NULL'ing the poke_tab pointer. The second detail is to ensure that per subprogram JIT logic only does fixups on poke_tab[] entries it owns. To do this, we add a pointer in the poke structure to point at the subprogram value so JITs can easily check while walking the poke_tab structure if the current entry belongs to the current program. The aux pointer is stable and therefore suitable for such comparison. On the jit_subprogs() error path, we omit cleaning up the poke->aux field because these are only ever referenced from the JIT side, but on error we will never make it to the JIT, so its fine to leave them dangling. Removing these pointers would complicate the error path for no reason. However, we do need to untrack all poke descriptors from the main program as otherwise they could race with the freeing of JIT memory from the subprograms. Lastly, a748c6975dea3 ("bpf: propagate poke descriptors to subprograms") had an off-by-one on the subprogram instruction index range check as it was testing 'insn_idx >= subprog_start && insn_idx <= subprog_end'. However, subprog_end is the next subprogram's start instruction. Fixes: a748c6975dea3 ("bpf: propagate poke descriptors to subprograms") Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Co-developed-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210707223848.14580-2-john.fastabend@gmail.com Signed-off-by: Greg Kroah-Hartman commit 782d71e29b2960b0027aca046cd0077998cb54d9 Author: Gu Shengxian Date: Mon Jul 5 18:35:43 2021 -0700 bpftool: Properly close va_list 'ap' by va_end() on error commit bc832065b60f973771ff3e657214bb21b559833c upstream. va_list 'ap' was opened but not closed by va_end() in error case. It should be closed by va_end() before the return. Fixes: aa52bcbe0e72 ("tools: bpftool: Fix json dump crash on powerpc") Signed-off-by: Gu Shengxian Signed-off-by: Daniel Borkmann Cc: Jiri Olsa Link: https://lore.kernel.org/bpf/20210706013543.671114-1-gushengxian507419@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2381b8e882d067b81560fe368913a4da950698f2 Author: Wei Li Date: Mon Jun 28 11:04:09 2021 +0800 tools: bpf: Fix error in 'make -C tools/ bpf_install' commit 1d719254c139fb62fb8056fb496b6fd007e71550 upstream. make[2]: *** No rule to make target 'install'. Stop. make[1]: *** [Makefile:122: runqslower_install] Error 2 make: *** [Makefile:116: bpf_install] Error 2 There is no rule for target 'install' in tools/bpf/runqslower/Makefile, and there is no need to install it, so just remove 'runqslower_install'. Fixes: 9c01546d26d2 ("tools/bpf: Add runqslower tool to tools/bpf") Signed-off-by: Wei Li Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210628030409.3459095-1-liwei391@huawei.com Signed-off-by: Greg Kroah-Hartman commit 638632997c3173e41a7e5fb22d802d9bc0522fbf Author: Talal Ahmad Date: Fri Jul 9 11:43:06 2021 -0400 tcp: call sk_wmem_schedule before sk_mem_charge in zerocopy path commit 358ed624207012f03318235017ac6fb41f8af592 upstream. sk_wmem_schedule makes sure that sk_forward_alloc has enough bytes for charging that is going to be done by sk_mem_charge. In the transmit zerocopy path, there is sk_mem_charge but there was no call to sk_wmem_schedule. This change adds that call. Without this call to sk_wmem_schedule, sk_forward_alloc can go negetive which is a bug because sk_forward_alloc is a per-socket space that has been forward charged so this can't be negative. Fixes: f214f915e7db ("tcp: enable MSG_ZEROCOPY") Signed-off-by: Talal Ahmad Reviewed-by: Willem de Bruijn Reviewed-by: Wei Wang Reviewed-by: Soheil Hassas Yeganeh Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2fee3cf4c97b8913c0c907dd7bb1988baa8faa01 Author: Eric Dumazet Date: Thu Jul 8 00:21:09 2021 -0700 ipv6: tcp: drop silly ICMPv6 packet too big messages commit c7bb4b89033b764eb07db4e060548a6311d801ee upstream. While TCP stack scales reasonably well, there is still one part that can be used to DDOS it. IPv6 Packet too big messages have to lookup/insert a new route, and if abused by attackers, can easily put hosts under high stress, with many cpus contending on a spinlock while one is stuck in fib6_run_gc() ip6_protocol_deliver_rcu() icmpv6_rcv() icmpv6_notify() tcp_v6_err() tcp_v6_mtu_reduced() inet6_csk_update_pmtu() ip6_rt_update_pmtu() __ip6_rt_update_pmtu() ip6_rt_cache_alloc() ip6_dst_alloc() dst_alloc() ip6_dst_gc() fib6_run_gc() spin_lock_bh() ... Some of our servers have been hit by malicious ICMPv6 packets trying to _increase_ the MTU/MSS of TCP flows. We believe these ICMPv6 packets are a result of a bug in one ISP stack, since they were blindly sent back for _every_ (small) packet sent to them. These packets are for one TCP flow: 09:24:36.266491 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.266509 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.316688 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.316704 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.608151 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 TCP stack can filter some silly requests : 1) MTU below IPV6_MIN_MTU can be filtered early in tcp_v6_err() 2) tcp_v6_mtu_reduced() can drop requests trying to increase current MSS. This tests happen before the IPv6 routing stack is entered, thus removing the potential contention and route exhaustion. Note that IPv6 stack was performing these checks, but too late (ie : after the route has been added, and after the potential garbage collect war) v2: fix typo caught by Martin, thanks ! v3: exports tcp_mtu_to_mss(), caught by David, thanks ! Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Maciej Żenczykowski Cc: Martin KaFai Lau Acked-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ad4ba3404931745a5977ad12db4f0c34080e52f7 Author: Nguyen Dinh Phi Date: Tue Jul 6 07:19:12 2021 +0800 tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized commit be5d1b61a2ad28c7e57fe8bfa277373e8ecffcdc upstream. This commit fixes a bug (found by syzkaller) that could cause spurious double-initializations for congestion control modules, which could cause memory leaks or other problems for congestion control modules (like CDG) that allocate memory in their init functions. The buggy scenario constructed by syzkaller was something like: (1) create a TCP socket (2) initiate a TFO connect via sendto() (3) while socket is in TCP_SYN_SENT, call setsockopt(TCP_CONGESTION), which calls: tcp_set_congestion_control() -> tcp_reinit_congestion_control() -> tcp_init_congestion_control() (4) receive ACK, connection is established, call tcp_init_transfer(), set icsk_ca_initialized=0 (without first calling cc->release()), call tcp_init_congestion_control() again. Note that in this sequence tcp_init_congestion_control() is called twice without a cc->release() call in between. Thus, for CC modules that allocate memory in their init() function, e.g, CDG, a memory leak may occur. The syzkaller tool managed to find a reproducer that triggered such a leak in CDG. The bug was introduced when that commit 8919a9b31eb4 ("tcp: Only init congestion control if not initialized already") introduced icsk_ca_initialized and set icsk_ca_initialized to 0 in tcp_init_transfer(), missing the possibility for a sequence like the one above, where a process could call setsockopt(TCP_CONGESTION) in state TCP_SYN_SENT (i.e. after the connect() or TFO open sendmsg()), which would call tcp_init_congestion_control(). It did not intend to reset any initialization that the user had already explicitly made; it just missed the possibility of that particular sequence (which syzkaller managed to find). Fixes: 8919a9b31eb4 ("tcp: Only init congestion control if not initialized already") Reported-by: syzbot+f1e24a0594d4e3a895d3@syzkaller.appspotmail.com Signed-off-by: Nguyen Dinh Phi Acked-by: Neal Cardwell Tested-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d60f07bcb76f0f2f0c786a669260d31d74d6a9ba Author: Eric Dumazet Date: Fri Jul 2 13:09:03 2021 -0700 tcp: annotate data races around tp->mtu_info commit 561022acb1ce62e50f7a8258687a21b84282a4cb upstream. While tp->mtu_info is read while socket is owned, the write sides happen from err handlers (tcp_v[46]_mtu_reduced) which only own the socket spinlock. Fixes: 563d34d05786 ("tcp: dont drop MTU reduction indications") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ea66fcb296058e0d41afa770f6900b335f8738a5 Author: Paolo Abeni Date: Wed Jun 30 13:42:13 2021 +0200 tcp: consistently disable header prediction for mptcp commit 71158bb1f2d2da61385c58fc1114e1a1c19984ba upstream. The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e82e2ea ("net: mptcp: improve fallback to TCP"), when an MPTCP socket falls back to TCP, it can hit the TCP receive fast-path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/200 Fixes: e1ff9e82e2ea ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c28c747e37dbf7a60ccb8e1bd8333e85ef50c8dc Author: Andrew Jeffery Date: Fri Jun 25 15:40:17 2021 +0930 ARM: dts: tacoma: Add phase corrections for eMMC commit 2d6608b57c50c54c3e46649110e8ea5a40959c30 upstream. The degree values were reversed out from the magic tap values of 7 (in) and 15 + inversion (out) initially suggested by Aspeed. With the patch tacoma survives several gigabytes of reads and writes using dd while without it locks up randomly during the boot process. Signed-off-by: Andrew Jeffery Link: https://lore.kernel.org/r/20210625061017.1149942-1-andrew@aj.id.au Fixes: 2fc88f92359d ("mmc: sdhci-of-aspeed: Expose clock phase controls") Fixes: 961216c135a8 ("ARM: dts: aspeed: Add Rainier system") Signed-off-by: Joel Stanley Signed-off-by: Greg Kroah-Hartman commit e55160537d76da8f9053cd3841ace475bdac647a Author: Joel Stanley Date: Thu Jun 24 18:37:42 2021 +0930 ARM: dts: aspeed: Fix AST2600 machines line names commit ca46ad2214473df1a6a9496be17156d65ba89b9f upstream. Tacoma and Rainier both have a line-names array that is too long: gpio gpiochip0: gpio-line-names is length 232 but should be at most length 208 This was probably copied from an AST2500 device tree that did have more GPIOs on the controller. Fixes: e9b24b55ca4f ("ARM: dts: aspeed: rainier: Add gpio line names") Fixes: 2f68e4e7df67 ("ARM: dts: aspeed: tacoma: Add gpio line names") Link: https://lore.kernel.org/r/20210624090742.56640-1-joel@jms.id.au Signed-off-by: Joel Stanley Signed-off-by: Greg Kroah-Hartman commit ff4b8f35c96c56a9029f58036e4f80eca59cddd0 Author: Masahiro Yamada Date: Wed Jul 14 13:23:49 2021 +0900 kbuild: do not suppress Kconfig prompts for silent build commit d952cfaf0cffdbbb0433c67206b645131f17ca5f upstream. When a new CONFIG option is available, Kbuild shows a prompt to get the user input. $ make [ snip ] Core Scheduling for SMT (SCHED_CORE) [N/y/?] (NEW) This is the only interactive place in the build process. Commit 174a1dcc9642 ("kbuild: sink stdout from cmd for silent build") suppressed Kconfig prompts as well because syncconfig is invoked by the 'cmd' macro. You cannot notice the fact that Kconfig is waiting for the user input. Use 'kecho' to show the equivalent short log without suppressing stdout from sub-make. Fixes: 174a1dcc9642 ("kbuild: sink stdout from cmd for silent build") Reported-by: Tetsuo Handa Signed-off-by: Masahiro Yamada Tested-by: Tetsuo Handa Signed-off-by: Greg Kroah-Hartman commit 0d514185ae792d3a1903c8e1a83899aa996705ce Author: Jason Ekstrand Date: Thu Jun 24 12:47:32 2021 -0500 dma-buf/sync_file: Don't leak fences on merge failure commit ffe000217c5068c5da07ccb1c0f8cce7ad767435 upstream. Each add_fence() call does a dma_fence_get() on the relevant fence. In the error path, we weren't calling dma_fence_put() so all those fences got leaked. Also, in the krealloc_array failure case, we weren't freeing the fences array. Instead, ensure that i and fences are always zero-initialized and dma_fence_put() all the fences and kfree(fences) on every error path. Signed-off-by: Jason Ekstrand Reviewed-by: Christian König Fixes: a02b9dc90d84 ("dma-buf/sync_file: refactor fence storage in struct sync_file") Cc: Gustavo Padovan Cc: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210624174732.1754546-1-jason@jlekstrand.net Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit f33605908a9b6063525e9f68e62d739948c5fccf Author: Pavel Skripkin Date: Tue Jul 13 13:58:53 2021 +0300 net: fddi: fix UAF in fza_probe commit deb7178eb940e2c5caca1b1db084a69b2e59b4c9 upstream. fp is netdev private data and it cannot be used after free_netdev() call. Using fp after free_netdev() can cause UAF bug. Fix it by moving free_netdev() after error message. Fixes: 61414f5ec983 ("FDDI: defza: Add support for DEC FDDIcontroller 700 TURBOchannel adapter") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 66c73f187d1ecfd8ac24802f5edbc1f994f9a97c Author: Vladimir Oltean Date: Tue Jul 13 12:40:21 2021 +0300 net: dsa: properly check for the bridge_leave methods in dsa_switch_bridge_leave() commit bcb9928a155444dbd212473e60241ca0a7f641e1 upstream. This was not caught because there is no switch driver which implements the .port_bridge_join but not .port_bridge_leave method, but it should nonetheless be fixed, as in certain conditions (driver development) it might lead to NULL pointer dereference. Fixes: f66a6a69f97a ("net: dsa: permit cross-chip bridging between all trees in the system") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7d7d0e84ac0d80815abfb7db3ba3e683830b310d Author: Greg Kroah-Hartman Date: Thu Jul 22 15:46:08 2021 +0200 Revert "mm/shmem: fix shmem_swapin() race with swapoff" This reverts commit a533a21b692fc15a6aadfa827b29c7d9989109ca which is commit 2efa33fc7f6ec94a3a538c1a264273c889be2b36 upstream. It should not have been added to the stable trees, sorry about that. Link: https://lore.kernel.org/r/YPVgaY6uw59Fqg5x@casper.infradead.org Reported-by: From: Matthew Wilcox Cc: Miaohe Lin Cc: Ying Huang Cc: Alex Shi Cc: David Hildenbrand Cc: Dennis Zhou Cc: Hugh Dickins Cc: Johannes Weiner Cc: Joonsoo Kim Cc: Matthew Wilcox Cc: Michal Hocko Cc: Minchan Kim Cc: Tim Chen Cc: Wei Yang Cc: Yang Shi Cc: Yu Zhao Cc: Andrew Morton Cc: Linus Torvalds Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2179d96ec702cc33ead02a9ce40ece599b8538c5 Author: Taehee Yoo Date: Fri Jul 9 17:35:18 2021 +0000 net: validate lwtstate->data before returning from skb_tunnel_info() commit 67a9c94317402b826fc3db32afc8f39336803d97 upstream. skb_tunnel_info() returns pointer of lwtstate->data as ip_tunnel_info type without validation. lwtstate->data can have various types such as mpls_iptunnel_encap, etc and these are not compatible. So skb_tunnel_info() should validate before returning that pointer. Splat looks like: BUG: KASAN: slab-out-of-bounds in vxlan_get_route+0x418/0x4b0 [vxlan] Read of size 2 at addr ffff888106ec2698 by task ping/811 CPU: 1 PID: 811 Comm: ping Not tainted 5.13.0+ #1195 Call Trace: dump_stack_lvl+0x56/0x7b print_address_description.constprop.8.cold.13+0x13/0x2ee ? vxlan_get_route+0x418/0x4b0 [vxlan] ? vxlan_get_route+0x418/0x4b0 [vxlan] kasan_report.cold.14+0x83/0xdf ? vxlan_get_route+0x418/0x4b0 [vxlan] vxlan_get_route+0x418/0x4b0 [vxlan] [ ... ] vxlan_xmit_one+0x148b/0x32b0 [vxlan] [ ... ] vxlan_xmit+0x25c5/0x4780 [vxlan] [ ... ] dev_hard_start_xmit+0x1ae/0x6e0 __dev_queue_xmit+0x1f39/0x31a0 [ ... ] neigh_xmit+0x2f9/0x940 mpls_xmit+0x911/0x1600 [mpls_iptunnel] lwtunnel_xmit+0x18f/0x450 ip_finish_output2+0x867/0x2040 [ ... ] Fixes: 61adedf3e3f1 ("route: move lwtunnel state to dst_entry") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b61d8814c4779f7810c96fa1d1d9e68fbd9d91df Author: Alexander Ovechkin Date: Fri Jul 9 18:28:23 2021 +0300 net: send SYNACK packet with accepted fwmark commit 43b90bfad34bcb81b8a5bc7dc650800f4be1787e upstream. commit e05a90ec9e16 ("net: reflect mark on tcp syn ack packets") fixed IPv4 only. This part is for the IPv6 side. Fixes: e05a90ec9e16 ("net: reflect mark on tcp syn ack packets") Signed-off-by: Alexander Ovechkin Acked-by: Dmitry Yakunin Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f2a062fcfe1d6f1b0a86fa76ae21c277d65f4405 Author: Pavel Skripkin Date: Fri Jul 9 17:58:29 2021 +0300 net: ti: fix UAF in tlan_remove_one commit 0336f8ffece62f882ab3012820965a786a983f70 upstream. priv is netdev private data and it cannot be used after free_netdev() call. Using priv after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. Fixes: 1e0a8b13d355 ("tlan: cancel work at remove path") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b560521eca03d0a2db6093a5a632cbdd0a0cf833 Author: Pavel Skripkin Date: Fri Jul 9 17:24:18 2021 +0300 net: qcom/emac: fix UAF in emac_remove commit ad297cd2db8953e2202970e9504cab247b6c7cb4 upstream. adpt is netdev private data and it cannot be used after free_netdev() call. Using adpt after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. Fixes: 54e19bc74f33 ("net: qcom/emac: do not use devm on internal phy pdev") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dbbf5b957bd9042d2a71d9ddb9b3d09092548276 Author: Pavel Skripkin Date: Fri Jul 9 17:09:53 2021 +0300 net: moxa: fix UAF in moxart_mac_probe commit c78eaeebe855fd93f2e77142ffd0404a54070d84 upstream. In case of netdev registration failure the code path will jump to init_fail label: init_fail: netdev_err(ndev, "init failed\n"); moxart_mac_free_memory(ndev); irq_map_fail: free_netdev(ndev); return ret; So, there is no need to call free_netdev() before jumping to error handling path, since it can cause UAF or double-free bug. Fixes: 6c821bd9edc9 ("net: Add MOXA ART SoCs ethernet driver") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 88ff9ec9c67ac0056d1df7d3301a14989383d2e3 Author: Hangbin Liu Date: Fri Jul 9 11:45:02 2021 +0800 net: ip_tunnel: fix mtu calculation for ETHER tunnel devices commit 9992a078b1771da354ac1f9737e1e639b687caa2 upstream. Commit 28e104d00281 ("net: ip_tunnel: fix mtu calculation") removed dev->hard_header_len subtraction when calculate MTU for tunnel devices as there is an overhead for device that has header_ops. But there are ETHER tunnel devices, like gre_tap or erspan, which don't have header_ops but set dev->hard_header_len during setup. This makes pkts greater than (MTU - ETH_HLEN) could not be xmited. Fix it by subtracting the ETHER tunnel devices' dev->hard_header_len for MTU calculation. Fixes: 28e104d00281 ("net: ip_tunnel: fix mtu calculation") Reported-by: Jianlin Shi Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 846829e75db53248ac923b8ec4258a2eddb01c76 Author: Florian Fainelli Date: Thu Jul 8 18:55:32 2021 -0700 net: bcmgenet: Ensure all TX/RX queues DMAs are disabled commit 2b452550a203d88112eaf0ba9fc4b750a000b496 upstream. Make sure that we disable each of the TX and RX queues in the TDMA and RDMA control registers. This is a correctness change to be symmetrical with the code that enables the TX and RX queues. Tested-by: Maxime Ripard Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b9fa66072fee264b09e7e0fc764b5d91c08a1b25 Author: Taehee Yoo Date: Mon Jul 5 15:38:08 2021 +0000 net: netdevsim: use xso.real_dev instead of xso.dev in callback functions of struct xfrmdev_ops commit 09adf7566d436322ced595b166dea48b06852efe upstream. There are two pointers in struct xfrm_state_offload, *dev, *real_dev. These are used in callback functions of struct xfrmdev_ops. The *dev points whether bonding interface or real interface. If bonding ipsec offload is used, it points bonding interface If not, it points real interface. And real_dev always points real interface. So, netdevsim should always use real_dev instead of dev. Of course, real_dev always not be null. Test commands: ip netns add A ip netns exec A bash modprobe netdevsim echo "1 1" > /sys/bus/netdevsim/new_device ip link add bond0 type bond mode active-backup ip link set eth0 master bond0 ip link set eth0 up ip link set bond0 up ip x s add proto esp dst 14.1.1.1 src 15.1.1.1 spi 0x07 mode \ transport reqid 0x07 replay-window 32 aead 'rfc4106(gcm(aes))' \ 0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 \ dst 14.0.0.70/24 proto tcp offload dev bond0 dir in Splat looks like: BUG: spinlock bad magic on CPU#5, kworker/5:1/53 lock: 0xffff8881068c2cc8, .magic: 11121314, .owner: /-1, .owner_cpu: -235736076 CPU: 5 PID: 53 Comm: kworker/5:1 Not tainted 5.13.0-rc3+ #1168 Workqueue: events linkwatch_event Call Trace: dump_stack+0xa4/0xe5 do_raw_spin_lock+0x20b/0x270 ? rwlock_bug.part.1+0x90/0x90 _raw_spin_lock_nested+0x5f/0x70 bond_get_stats+0xe4/0x4c0 [bonding] ? rcu_read_lock_sched_held+0xc0/0xc0 ? bond_neigh_init+0x2c0/0x2c0 [bonding] ? dev_get_alias+0xe2/0x190 ? dev_get_port_parent_id+0x14a/0x360 ? rtnl_unregister+0x190/0x190 ? dev_get_phys_port_name+0xa0/0xa0 ? memset+0x1f/0x40 ? memcpy+0x38/0x60 ? rtnl_phys_switch_id_fill+0x91/0x100 dev_get_stats+0x8c/0x270 rtnl_fill_stats+0x44/0xbe0 ? nla_put+0xbe/0x140 rtnl_fill_ifinfo+0x1054/0x3ad0 [ ... ] Fixes: 272c2330adc9 ("xfrm: bail early on slave pass over skb") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 59070cc43d1de8a2ecf26200197e28abc9a55ea4 Author: Wolfgang Bumiller Date: Fri Jul 2 14:07:36 2021 +0200 net: bridge: sync fdb to new unicast-filtering ports commit a019abd8022061b917da767cd1a66ed823724eab upstream. Since commit 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.") bridges with `vlan_filtering 1` and only 1 auto-port don't set IFF_PROMISC for unicast-filtering-capable ports. Normally on port changes `br_manage_promisc` is called to update the promisc flags and unicast filters if necessary, but it cannot distinguish between *new* ports and ones losing their promisc flag, and new ports end up not receiving the MAC address list. Fix this by calling `br_fdb_sync_static` in `br_add_if` after the port promisc flags are updated and the unicast filter was supposed to have been filled. Fixes: 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.") Signed-off-by: Wolfgang Bumiller Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7b5a2910e782f29f26558c0dde87af6052031469 Author: Louis Peens Date: Fri Jul 2 11:21:38 2021 +0200 net/sched: act_ct: remove and free nf_table callbacks commit 77ac5e40c44eb78333fbc38482d61fc2af7dda0a upstream. When cleaning up the nf_table in tcf_ct_flow_table_cleanup_work there is no guarantee that the callback list, added to by nf_flow_table_offload_add_cb, is empty. This means that it is possible that the flow_block_cb memory allocated will be lost. Fix this by iterating the list and freeing the flow_block_cb entries before freeing the nf_table entry (via freeing ct_ft). Fixes: 978703f42549 ("netfilter: flowtable: Add API for registering to flow table events") Signed-off-by: Louis Peens Signed-off-by: Yinjun Zhang Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6d4476236f798ba17de5fc7257c253dae41e7abd Author: Ronak Doshi Date: Thu Jul 1 23:44:27 2021 -0700 vmxnet3: fix cksum offload issues for tunnels with non-default udp ports commit b22580233d473dbf7bbfa4f6549c09e2c80e9e64 upstream. Commit dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support") added support for encapsulation offload. However, the inner offload capability is to be restricted to UDP tunnels with default Vxlan and Geneve ports. This patch fixes the issue for tunnels with non-default ports using features check capability and filtering appropriate features for such tunnels. Fixes: dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support") Signed-off-by: Ronak Doshi Acked-by: Guolin Yang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c3bc9ce7d400718b8341aab0f4fe86d2cf6a3715 Author: wenxu Date: Fri Jul 2 11:34:31 2021 +0800 net/sched: act_ct: fix err check for nf_conntrack_confirm commit 8955b90c3cdad199137809aac8ccbbb585355913 upstream. The confirm operation should be checked. If there are any failed, the packet should be dropped like in ovs and netfilter. Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Signed-off-by: wenxu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fc40fdefd94aa833cb1065ababa1d2349fa72d69 Author: Vasily Averin Date: Thu Jul 1 08:02:49 2021 +0300 netfilter: ctnetlink: suspicious RCU usage in ctnetlink_dump_helpinfo commit c23a9fd209bc6f8c1fa6ee303fdf037d784a1627 upstream. Two patches listed below removed ctnetlink_dump_helpinfo call from under rcu_read_lock. Now its rcu_dereference generates following warning: ============================= WARNING: suspicious RCU usage 5.13.0+ #5 Not tainted ----------------------------- net/netfilter/nf_conntrack_netlink.c:221 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 stack backtrace: CPU: 1 PID: 2251 Comm: conntrack Not tainted 5.13.0+ #5 Call Trace: dump_stack+0x7f/0xa1 ctnetlink_dump_helpinfo+0x134/0x150 [nf_conntrack_netlink] ctnetlink_fill_info+0x2c2/0x390 [nf_conntrack_netlink] ctnetlink_dump_table+0x13f/0x370 [nf_conntrack_netlink] netlink_dump+0x10c/0x370 __netlink_dump_start+0x1a7/0x260 ctnetlink_get_conntrack+0x1e5/0x250 [nf_conntrack_netlink] nfnetlink_rcv_msg+0x613/0x993 [nfnetlink] netlink_rcv_skb+0x50/0x100 nfnetlink_rcv+0x55/0x120 [nfnetlink] netlink_unicast+0x181/0x260 netlink_sendmsg+0x23f/0x460 sock_sendmsg+0x5b/0x60 __sys_sendto+0xf1/0x160 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x36/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 49ca022bccc5 ("netfilter: ctnetlink: don't dump ct extensions of unconfirmed conntracks") Fixes: 0b35f6031a00 ("netfilter: Remove duplicated rcu_read_lock.") Signed-off-by: Vasily Averin Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 34365de50806e47183b4a9fa2247939c93758405 Author: Vadim Fedorenko Date: Fri Jul 2 02:47:00 2021 +0300 net: ipv6: fix return value of ip6_skb_dst_mtu commit 40fc3054b45820c28ea3c65e2c86d041dc244a8a upstream. Commit 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE") introduced ip6_skb_dst_mtu with return value of signed int which is inconsistent with actually returned values. Also 2 users of this function actually assign its value to unsigned int variable and only __xfrm6_output assigns result of this function to signed variable but actually uses as unsigned in further comparisons and calls. Change this function to return unsigned int value. Fixes: 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE") Reviewed-by: David Ahern Signed-off-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 73146745ff28088cda545b473e72b9c2b56eafcd Author: Marek Behún Date: Thu Jul 1 00:22:29 2021 +0200 net: dsa: mv88e6xxx: enable devlink ATU hash param for Topaz commit c07fff3492acae41cedbabea395b644dd5872b8c upstream. Commit 23e8b470c7788 ("net: dsa: mv88e6xxx: Add devlink param for ATU hash algorithm.") introduced ATU hash algorithm access via devlink, but did not enable it for Topaz. Enable this feature also for Topaz. Signed-off-by: Marek Behún Fixes: 23e8b470c7788 ("net: dsa: mv88e6xxx: Add devlink param for ATU hash algorithm.") Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a8c7ba3687482a6e3773c880508054194eb444bf Author: Marek Behún Date: Thu Jul 1 00:22:28 2021 +0200 net: dsa: mv88e6xxx: enable .rmu_disable() on Topaz commit 3709488790022c85720f991bff50d48ed5a36e6a upstream. Commit 9e5baf9b36367 ("net: dsa: mv88e6xxx: add RMU disable op") introduced .rmu_disable() method with implementation for several models, but forgot to add Topaz, which can use the Peridot implementation. Use the Peridot implementation of .rmu_disable() on Topaz. Signed-off-by: Marek Behún Fixes: 9e5baf9b36367 ("net: dsa: mv88e6xxx: add RMU disable op") Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 14cd8ce80ad718bc215d98c8b5e6741ae18feec9 Author: Marek Behún Date: Thu Jul 1 00:22:27 2021 +0200 net: dsa: mv88e6xxx: use correct .stats_set_histogram() on Topaz commit 11527f3c4725640e6c40a2b7654e303f45e82a6c upstream. Commit 40cff8fca9e3 ("net: dsa: mv88e6xxx: Fix stats histogram mode") introduced wrong .stats_set_histogram() method for Topaz family. The Peridot method should be used instead. Signed-off-by: Marek Behún Fixes: 40cff8fca9e3 ("net: dsa: mv88e6xxx: Fix stats histogram mode") Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c657413dcddf75f769d0b2e3e5acff6c90fcbe4a Author: Marek Behún Date: Thu Jul 1 00:22:26 2021 +0200 net: dsa: mv88e6xxx: enable .port_set_policy() on Topaz commit 7da467d82d1ed4fb317aff836f99709169e73f10 upstream. Commit f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") introduced .port_set_policy() method with implementation for several models, but forgot to add Topaz, which can use the 6352 implementation. Use the 6352 implementation of .port_set_policy() on Topaz. Signed-off-by: Marek Behún Fixes: f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fcb970edc0bea80fe75b33e7f59ec453d92e8045 Author: Doug Berger Date: Tue Jun 29 17:14:19 2021 -0700 net: bcmgenet: ensure EXT_ENERGY_DET_MASK is clear commit 5a3c680aa2c12c90c44af383fe6882a39875ab81 upstream. Setting the EXT_ENERGY_DET_MASK bit allows the port energy detection logic of the internal PHY to prevent the system from sleeping. Some internal PHYs will report that energy is detected when the network interface is closed which can prevent the system from going to sleep if WoL is enabled when the interface is brought down. Since the driver does not support waking the system on this logic, this commit clears the bit whenever the internal PHY is powered up and the other logic for manipulating the bit is removed since it serves no useful function. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4e275a4aca687794d61b4eb004d007163258ead3 Author: Sanket Parmar Date: Mon May 17 17:05:12 2021 +0200 usb: cdns3: Enable TDL_CHK only for OUT ep commit d6eef886903c4bb5af41b9a31d4ba11dc7a6f8e8 upstream. ZLP gets stuck if TDL_CHK bit is set and TDL_FROM_TRB is used as TDL source for IN endpoints. To fix it, TDL_CHK is only enabled for OUT endpoints. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Reported-by: Aswath Govindraju Signed-off-by: Sanket Parmar Link: https://lore.kernel.org/r/1621263912-13175-1-git-send-email-sparmar@cadence.com Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman commit ce6ee46e0f39ed97e23ebf7b5a565e0266a8a1a3 Author: Mike Rapoport Date: Mon Jun 28 19:33:26 2021 -0700 mm/page_alloc: fix memory map initialization for descending nodes commit 122e093c1734361dedb64f65c99b93e28e4624f4 upstream. On systems with memory nodes sorted in descending order, for instance Dell Precision WorkStation T5500, the struct pages for higher PFNs and respectively lower nodes, could be overwritten by the initialization of struct pages corresponding to the holes in the memory sections. For example for the below memory layout [ 0.245624] Early memory node ranges [ 0.248496] node 1: [mem 0x0000000000001000-0x0000000000090fff] [ 0.251376] node 1: [mem 0x0000000000100000-0x00000000dbdf8fff] [ 0.254256] node 1: [mem 0x0000000100000000-0x0000001423ffffff] [ 0.257144] node 0: [mem 0x0000001424000000-0x0000002023ffffff] the range 0x1424000000 - 0x1428000000 in the beginning of node 0 starts in the middle of a section and will be considered as a hole during the initialization of the last section in node 1. The wrong initialization of the memory map causes panic on boot when CONFIG_DEBUG_VM is enabled. Reorder loop order of the memory map initialization so that the outer loop will always iterate over populated memory regions in the ascending order and the inner loop will select the zone corresponding to the PFN range. This way initialization of the struct pages for the memory holes will be always done for the ranges that are actually not populated. [akpm@linux-foundation.org: coding style fixes] Link: https://lkml.kernel.org/r/YNXlMqBbL+tBG7yq@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=213073 Link: https://lkml.kernel.org/r/20210624062305.10940-1-rppt@kernel.org Fixes: 0740a50b9baa ("mm/page_alloc.c: refactor initialization of struct page for holes in memory layout") Signed-off-by: Mike Rapoport Cc: Boris Petkov Cc: Robert Shteynfeld Cc: Baoquan He Cc: Vlastimil Babka Cc: David Hildenbrand Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [rppt: tweak for compatibility with IA64's override of memmap_init] Signed-off-by: Mike Rapoport Signed-off-by: Greg Kroah-Hartman commit 9e1cf2d1ed37c934c9935f2c0b2f8b15d9355654 Author: Peter Xu Date: Wed Jun 30 18:49:02 2021 -0700 mm/userfaultfd: fix uffd-wp special cases for fork() commit 8f34f1eac3820fc2722e5159acceb22545b30b0d upstream. We tried to do something similar in b569a1760782 ("userfaultfd: wp: drop _PAGE_UFFD_WP properly when fork") previously, but it's not doing it all right.. A few fixes around the code path: 1. We were referencing VM_UFFD_WP vm_flags on the _old_ vma rather than the new vma. That's overlooked in b569a1760782, so it won't work as expected. Thanks to the recent rework on fork code (7a4830c380f3a8b3), we can easily get the new vma now, so switch the checks to that. 2. Dropping the uffd-wp bit in copy_huge_pmd() could be wrong if the huge pmd is a migration huge pmd. When it happens, instead of using pmd_uffd_wp(), we should use pmd_swp_uffd_wp(). The fix is simply to handle them separately. 3. Forget to carry over uffd-wp bit for a write migration huge pmd entry. This also happens in copy_huge_pmd(), where we converted a write huge migration entry into a read one. 4. In copy_nonpresent_pte(), drop uffd-wp if necessary for swap ptes. 5. In copy_present_page() when COW is enforced when fork(), we also need to pass over the uffd-wp bit if VM_UFFD_WP is armed on the new vma, and when the pte to be copied has uffd-wp bit set. Remove the comment in copy_present_pte() about this. It won't help a huge lot to only comment there, but comment everywhere would be an overkill. Let's assume the commit messages would help. [peterx@redhat.com: fix a few thp pmd missing uffd-wp bit] Link: https://lkml.kernel.org/r/20210428225030.9708-4-peterx@redhat.com Link: https://lkml.kernel.org/r/20210428225030.9708-3-peterx@redhat.com Fixes: b569a1760782f ("userfaultfd: wp: drop _PAGE_UFFD_WP properly when fork") Signed-off-by: Peter Xu Cc: Jerome Glisse Cc: Mike Rapoport Cc: Alexander Viro Cc: Andrea Arcangeli Cc: Axel Rasmussen Cc: Brian Geffon Cc: "Dr . David Alan Gilbert" Cc: Hugh Dickins Cc: Joe Perches Cc: Kirill A. Shutemov Cc: Lokesh Gidra Cc: Mike Kravetz Cc: Mina Almasry Cc: Oliver Upton Cc: Shaohua Li Cc: Shuah Khan Cc: Stephen Rothwell Cc: Wang Qing Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 84ff5f66c3f62e1934637af7d980117b4fb2d3b3 Author: Peter Xu Date: Wed Jun 30 18:48:59 2021 -0700 mm/thp: simplify copying of huge zero page pmd when fork commit 5fc7a5f6fd04bc18f309d9f979b32ef7d1d0a997 upstream. Patch series "mm/uffd: Misc fix for uffd-wp and one more test". This series tries to fix some corner case bugs for uffd-wp on either thp or fork(). Then it introduced a new test with pagemap/pageout. Patch layout: Patch 1: cleanup for THP, it'll slightly simplify the follow up patches Patch 2-4: misc fixes for uffd-wp here and there; please refer to each patch Patch 5: add pagemap support for uffd-wp Patch 6: add pagemap/pageout test for uffd-wp The last test introduced can also verify some of the fixes in previous patches, as the test will fail without the fixes. However it's not easy to verify all the changes in patch 2-4, but hopefully they can still be properly reviewed. Note that if considering the ongoing uffd-wp shmem & hugetlbfs work, patch 5 will be incomplete as it's missing e.g. hugetlbfs part or the special swap pte detection. However that's not needed in this series, and since that series is still during review, this series does not depend on that one (the last test only runs with anonymous memory, not file-backed). So this series can be merged even before that series. This patch (of 6): Huge zero page is handled in a special path in copy_huge_pmd(), however it should share most codes with a normal thp page. Trying to share more code with it by removing the special path. The only leftover so far is the huge zero page refcounting (mm_get_huge_zero_page()), because that's separately done with a global counter. This prepares for a future patch to modify the huge pmd to be installed, so that we don't need to duplicate it explicitly into huge zero page case too. Link: https://lkml.kernel.org/r/20210428225030.9708-1-peterx@redhat.com Link: https://lkml.kernel.org/r/20210428225030.9708-2-peterx@redhat.com Signed-off-by: Peter Xu Cc: Kirill A. Shutemov Cc: Mike Kravetz , peterx@redhat.com Cc: Mike Rapoport Cc: Axel Rasmussen Cc: Andrea Arcangeli Cc: Hugh Dickins Cc: Jerome Glisse Cc: Alexander Viro Cc: Brian Geffon Cc: "Dr . David Alan Gilbert" Cc: Joe Perches Cc: Lokesh Gidra Cc: Mina Almasry Cc: Oliver Upton Cc: Shaohua Li Cc: Shuah Khan Cc: Stephen Rothwell Cc: Wang Qing Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a62177b35730650c54339c3eb581a1c84f7387da Author: Daniel Rosenberg Date: Thu Jun 3 09:50:37 2021 +0000 f2fs: Show casefolding support only when supported commit 39307f8ee3539478c28e71b4909b5b028cce14b1 upstream. The casefolding feature is only supported when CONFIG_UNICODE is set. This modifies the feature list f2fs presents under sysfs accordingly. Fixes: 5aba54302a46 ("f2fs: include charset encoding information in the superblock") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Daniel Rosenberg Reviewed-by: Eric Biggers Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 277b311ae170b90fcc30551d1a30d17fceb113a4 Author: Greg Kroah-Hartman Date: Thu Jul 22 15:43:47 2021 +0200 Revert "swap: fix do_swap_page() race with swapoff" This reverts commit 8e4af3917bfc5e82f8010417c12b755ef256fa5e which is commit 2799e77529c2a25492a4395db93996e3dacd762d upstream. It should not have been added to the stable trees, sorry about that. Link: https://lore.kernel.org/r/YPVgaY6uw59Fqg5x@casper.infradead.org Reported-by: From: Matthew Wilcox Cc: Miaohe Lin Cc: Ying Huang Cc: Alex Shi Cc: David Hildenbrand Cc: Dennis Zhou Cc: Hugh Dickins Cc: Johannes Weiner Cc: Joonsoo Kim Cc: Matthew Wilcox Cc: Michal Hocko Cc: Minchan Kim Cc: Tim Chen Cc: Wei Yang Cc: Yang Shi Cc: Yu Zhao Cc: Andrew Morton Cc: Linus Torvalds Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d92aa22f24199e55a3d5a1854498a756c6f60449 Author: Pali Rohár Date: Thu May 20 13:38:44 2021 +0200 arm64: dts: marvell: armada-37xx: move firmware node to generic dtsi file [ Upstream commit 3a52a48973b355b3aac5add92ef50650ae37c2bd ] Move the turris-mox-rwtm firmware node from Turris MOX' device tree into the generic armada-37xx.dtsi file and use the generic compatible string 'marvell,armada-3700-rwtm-firmware' instead of the current one. Turris MOX DTS file contains also old compatible string for backward compatibility. The Turris MOX rWTM firmware can be used on any Armada 37xx device, giving them access to the rWTM hardware random number generator, which is otherwise unavailable. This change allows Linux to load the turris-mox-rwtm.ko module on these boards. Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails to probe, while with CZ.NIC's firmware it registers the HW random number generator. Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 0e67c76384e9461dc343fed5f36106b78a7bffba Author: Pali Rohár Date: Thu May 20 13:38:43 2021 +0200 firmware: turris-mox-rwtm: add marvell,armada-3700-rwtm-firmware compatible string [ Upstream commit 90ae47215de3fec862aeb1a0f0e28bb505ab1351 ] Add more generic compatible string 'marvell,armada-3700-rwtm-firmware' for this driver, since it can also be used on other Armada 3720 devices. Current compatible string 'cznic,turris-mox-rwtm' is kept for backward compatibility. Signed-off-by: Pali Rohár Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit e58c162789becede894d3e94c0ce6695a2ef5796 Author: Paulo Alcantara Date: Fri Jul 2 11:50:54 2021 -0300 cifs: prevent NULL deref in cifs_compose_mount_options() [ Upstream commit 03313d1c3a2f086bb60920607ab79ac8f8578306 ] The optional @ref parameter might contain an NULL node_name, so prevent dereferencing it in cifs_compose_mount_options(). Addresses-Coverity: 1476408 ("Explicit null dereferenced") Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit faa3e7da487abbde93cd6f04f84f82717cc1077b Author: Heiko Carstens Date: Mon Jul 5 20:16:10 2021 +0200 s390: introduce proper type handling call_on_stack() macro [ Upstream commit 41d71fe59cce41237f24f3b7bdc1b414069a34ed ] The existing CALL_ON_STACK() macro allows for subtle bugs: - There is no type checking of the function that is being called. That is: missing or too many arguments do not cause any compile error or warning. The same is true if the return type of the called function changes. This can lead to quite random bugs. - Sign and zero extension of arguments is missing. Given that the s390 C ABI requires that the caller of a function performs proper sign and zero extension this can also lead to subtle bugs. - If arguments to the CALL_ON_STACK() macros contain functions calls register corruption can happen due to register asm constructs being used. Therefore introduce a new call_on_stack() macro which is supposed to fix all these problems. Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit be10fff3a4612c21e92405bce52132bad39c093a Author: Ilya Leoshkevich Date: Fri Jul 2 15:54:55 2021 +0200 s390/traps: do not test MONITOR CALL without CONFIG_BUG [ Upstream commit b8e9cc20b808e26329090c19ff80b7f5098e98ff ] tinyconfig fails to boot, because without CONFIG_BUG report_bug() always returns BUG_TRAP_TYPE_BUG, which causes mc 0,0 in test_monitor_call() to panic. Fix by skipping the test without CONFIG_BUG. Signed-off-by: Ilya Leoshkevich Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 9beba1469996b5d8d610633c76514a4997bdc763 Author: Dmitry Osipenko Date: Wed Jun 16 22:04:13 2021 +0300 thermal/core/thermal_of: Stop zone device before unregistering it [ Upstream commit 5e5c9f9a75fc4532980c2e699caf8a36070a3a2e ] Zone device is enabled after thermal_zone_of_sensor_register() completion, but it's not disabled before senor is unregistered, leaving temperature polling active. This results in accessing a disabled zone device and produces a warning about this problem. Stop zone device before unregistering it in order to fix this "use-after-free" problem. Signed-off-by: Dmitry Osipenko Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210616190417.32214-3-digetx@gmail.com Signed-off-by: Sasha Levin commit 7412c988fe123a064d67778611a5e40fd50bfd20 Author: Kan Liang Date: Thu Jun 24 11:17:57 2021 -0700 perf/x86/intel/uncore: Clean up error handling path of iio mapping [ Upstream commit d4ba0b06306a70c99a43f9d452886a86e2d3bd26 ] The error handling path of iio mapping looks fragile. We already fixed one issue caused by it, commit f797f05d917f ("perf/x86/intel/uncore: Fix for iio mapping on Skylake Server"). Clean up the error handling path and make the code robust. Reported-by: gushengxian Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/40e66cf9-398b-20d7-ce4d-433be6e08921@linux.intel.com Signed-off-by: Sasha Levin commit 892387e7619ecb339dd43c4ab916256d6c4c0001 Author: Odin Ugedal Date: Tue Jun 29 14:14:52 2021 +0200 sched/fair: Fix CFS bandwidth hrtimer expiry type [ Upstream commit 72d0ad7cb5bad265adb2014dbe46c4ccb11afaba ] The time remaining until expiry of the refresh_timer can be negative. Casting the type to an unsigned 64-bit value will cause integer underflow, making the runtime_refresh_within return false instead of true. These situations are rare, but they do happen. This does not cause user-facing issues or errors; other than possibly unthrottling cfs_rq's using runtime from the previous period(s), making the CFS bandwidth enforcement less strict in those (special) situations. Signed-off-by: Odin Ugedal Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ben Segall Link: https://lore.kernel.org/r/20210629121452.18429-1-odin@uged.al Signed-off-by: Sasha Levin commit eb859b043c2e3780cf9cdd2a9ab4e73694dacf1e Author: Javed Hasan Date: Thu Jun 24 10:18:02 2021 -0700 scsi: qedf: Add check to synchronize abort and flush [ Upstream commit df99446d5c2a63dc6e6920c8090da0e9da6539d5 ] A race condition was observed between qedf_cleanup_fcport() and qedf_process_error_detect()->qedf_initiate_abts(): [2069091.203145] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 [2069091.213100] IP: [] qedf_process_error_detect+0x96/0x130 [qedf] [2069091.223391] PGD 1943049067 PUD 194304e067 PMD 0 [2069091.233420] Oops: 0000 [#1] SMP [2069091.361820] CPU: 1 PID: 14751 Comm: kworker/1:46 Kdump: loaded Tainted: P OE ------------ 3.10.0-1160.25.1.el7.x86_64 #1 [2069091.388474] Hardware name: HPE Synergy 480 Gen10/Synergy 480 Gen10 Compute Module, BIOS I42 04/08/2020 [2069091.402148] Workqueue: qedf_io_wq qedf_fp_io_handler [qedf] [2069091.415780] task: ffff9bb9f5190000 ti: ffff9bacaef9c000 task.ti: ffff9bacaef9c000 [2069091.429590] RIP: 0010:[] [] qedf_process_error_detect+0x96/0x130 [qedf] [2069091.443666] RSP: 0018:ffff9bacaef9fdb8 EFLAGS: 00010246 [2069091.457692] RAX: 0000000000000000 RBX: ffff9bbbbbfb18a0 RCX: ffffffffc0672310 [2069091.471997] RDX: 00000000000005de RSI: ffffffffc066e7f0 RDI: ffff9beb3f4538d8 [2069091.486130] RBP: ffff9bacaef9fdd8 R08: 0000000000006000 R09: 0000000000006000 [2069091.500321] R10: 0000000000001551 R11: ffffb582996ffff8 R12: ffffb5829b39cc18 [2069091.514779] R13: ffff9badab380c28 R14: ffffd5827f643900 R15: 0000000000000040 [2069091.529472] FS: 0000000000000000(0000) GS:ffff9beb3f440000(0000) knlGS:0000000000000000 [2069091.543926] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2069091.558942] CR2: 0000000000000030 CR3: 000000193b9a2000 CR4: 00000000007607e0 [2069091.573424] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [2069091.587876] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2069091.602007] PKRU: 00000000 [2069091.616010] Call Trace: [2069091.629902] [] qedf_process_cqe+0x109/0x2e0 [qedf] [2069091.643941] [] qedf_fp_io_handler+0x26/0x60 [qedf] [2069091.657948] [] process_one_work+0x17f/0x440 [2069091.672111] [] worker_thread+0x126/0x3c0 [2069091.686057] [] ? manage_workers.isra.26+0x2a0/0x2a0 [2069091.700033] [] kthread+0xd1/0xe0 [2069091.713891] [] ? insert_kthread_work+0x40/0x40 Add check in qedf_process_error_detect(). When flush is active, let the cmds be completed from the cleanup contex. Link: https://lore.kernel.org/r/20210624171802.598-1-jhasan@marvell.com Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a4a54c54af2516caa9c145015844543cfc84316a Author: Javed Hasan Date: Tue Jun 15 09:59:39 2021 -0700 scsi: libfc: Fix array index out of bound exception [ Upstream commit b27c4577557045f1ab3cdfeabfc7f3cd24aca1fe ] Fix array index out of bound exception in fc_rport_prli_resp(). Link: https://lore.kernel.org/r/20210615165939.24327-1-jhasan@marvell.com Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0d7596a954f1f230b4c6fc14b0b6b3a853c6b741 Author: Yufen Yu Date: Tue Jun 22 11:40:37 2021 +0800 scsi: libsas: Add LUN number check in .slave_alloc callback [ Upstream commit 49da96d77938db21864dae6b7736b71e96c1d203 ] Offlining a SATA device connected to a hisi SAS controller and then scanning the host will result in detecting 255 non-existent devices: # lsscsi [2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda [2:0:1:0] disk ATA WDC WD2003FYYS-3 1D01 /dev/sdb [2:0:2:0] disk SEAGATE ST600MM0006 B001 /dev/sdc # echo "offline" > /sys/block/sdb/device/state # echo "- - -" > /sys/class/scsi_host/host2/scan # lsscsi [2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda [2:0:1:0] disk ATA WDC WD2003FYYS-3 1D01 /dev/sdb [2:0:1:1] disk ATA WDC WD2003FYYS-3 1D01 /dev/sdh ... [2:0:1:255] disk ATA WDC WD2003FYYS-3 1D01 /dev/sdjb After a REPORT LUN command issued to the offline device fails, the SCSI midlayer tries to do a sequential scan of all devices whose LUN number is not 0. However, SATA does not support LUN numbers at all. Introduce a generic sas_slave_alloc() handler which will return -ENXIO for SATA devices if the requested LUN number is larger than 0 and make libsas drivers use this function as their .slave_alloc callback. Link: https://lore.kernel.org/r/20210622034037.1467088-1-yuyufen@huawei.com Reported-by: Wu Bo Suggested-by: John Garry Reviewed-by: John Garry Reviewed-by: Jason Yan Signed-off-by: Yufen Yu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2f8df6332eb2178b86748a0f7ff340ccd320e8e4 Author: Colin Ian King Date: Mon Jun 21 16:17:27 2021 +0100 scsi: aic7xxx: Fix unintentional sign extension issue on left shift of u8 [ Upstream commit 332a9dd1d86f1e7203fc7f0fd7e82f0b304200fe ] The shifting of the u8 integer returned fom ahc_inb(ahc, port+3) by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that the top bit of the u8 is set then all then all the upper 32 bits of the u64 end up as also being set because of the sign-extension. Fix this by casting the u8 values to a u64 before the 24 bit left shift. [ This dates back to 2002, I found the offending commit from the git history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git, commit f58eb66c0b0a ("Update aic7xxx driver to 6.2.10...") ] Link: https://lore.kernel.org/r/20210621151727.20667-1-colin.king@canonical.com Signed-off-by: Colin Ian King Signed-off-by: Martin K. Petersen Addresses-Coverity: ("Unintended sign extension") Signed-off-by: Sasha Levin commit cdb995a6cbb5315e2d0bfba92ac1e08bfa25cfdb Author: Krzysztof Kozlowski Date: Wed May 26 13:20:34 2021 -0400 rtc: max77686: Do not enforce (incorrect) interrupt trigger type [ Upstream commit 742b0d7e15c333303daad4856de0764f4bc83601 ] Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge falling - but instead rely on Devicetree to configure it. The Maxim 77686 datasheet describes the interrupt line as active low with a requirement of acknowledge from the CPU therefore the edge falling is not correct. The interrupt line is shared between PMIC and RTC driver, so using level sensitive interrupt is here especially important to avoid races. With an edge configuration in case if first PMIC signals interrupt followed shortly after by the RTC, the interrupt might not be yet cleared/acked thus the second one would not be noticed. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210526172036.183223-6-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit d3ba15fb04014f56221084e9791cfcd719b8d6f8 Author: Konstantin Porotchkin Date: Tue Feb 9 15:46:07 2021 +0200 arch/arm64/boot/dts/marvell: fix NAND partitioning scheme [ Upstream commit e3850467bf8c82de4a052619136839fe8054b774 ] Eliminate 1MB gap between Linux and filesystem partitions. Signed-off-by: Konstantin Porotchkin Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit e378db118925f2fb144e0235334f3e12bd617606 Author: Matthias Maennich Date: Sat Jun 12 15:18:38 2021 +0100 kbuild: mkcompile_h: consider timestamp if KBUILD_BUILD_TIMESTAMP is set [ Upstream commit a979522a1a88556e42a22ce61bccc58e304cb361 ] To avoid unnecessary recompilations, mkcompile_h does not regenerate compile.h if just the timestamp changed. Though, if KBUILD_BUILD_TIMESTAMP is set, an explicit timestamp for the build was requested, in which case we should not ignore it. If a user follows the documentation for reproducible builds [1] and defines KBUILD_BUILD_TIMESTAMP as the git commit timestamp, a clean build will have the correct timestamp. A subsequent cherry-pick (or amend) changes the commit timestamp and if an incremental build is done with a different KBUILD_BUILD_TIMESTAMP now, that new value is not taken into consideration. But it should for reproducibility. Hence, whenever KBUILD_BUILD_TIMESTAMP is explicitly set, do not ignore UTS_VERSION when making a decision about whether the regenerated version of compile.h should be moved into place. [1] https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html Signed-off-by: Matthias Maennich Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 8c12a3a68d4f89b0cc4f58603a2e43cae8c9748c Author: Krzysztof Kozlowski Date: Mon Jun 14 21:22:30 2021 +0200 thermal/drivers/sprd: Add missing of_node_put for loop iteration [ Upstream commit d8ac5bb4ae653e092d7429a7587b73f1662d6ad7 ] Early exits from for_each_available_child_of_node() should decrement the node reference counter. Reported by Coccinelle: drivers/thermal/sprd_thermal.c:387:1-23: WARNING: Function "for_each_child_of_node" should have of_node_put() before goto around lines 391. Signed-off-by: Krzysztof Kozlowski Acked-by: Chunyan Zhang Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210614192230.19248-2-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit 20babcd830922e3aa233c95515cd2052bd6da71f Author: Krzysztof Kozlowski Date: Mon Jun 14 21:22:29 2021 +0200 thermal/drivers/imx_sc: Add missing of_node_put for loop iteration [ Upstream commit 3da97620e8d60da4a7eaae46e03e0a494780642d ] Early exits from for_each_available_child_of_node() should decrement the node reference counter. Reported by Coccinelle: drivers/thermal/imx_sc_thermal.c:93:1-33: WARNING: Function "for_each_available_child_of_node" should have of_node_put() before return around line 97. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Jacky Bai Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210614192230.19248-1-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit 469951ce4bb09fb610020dd9df657c76ac122752 Author: Geert Uytterhoeven Date: Mon Jun 7 16:41:20 2021 +0200 thermal/drivers/rcar_gen3_thermal: Do not shadow rcar_gen3_ths_tj_1 [ Upstream commit 3ae5950db617d1cc3eb4eb55750fa9d138529b49 ] With -Wshadow: drivers/thermal/rcar_gen3_thermal.c: In function ‘rcar_gen3_thermal_probe’: drivers/thermal/rcar_gen3_thermal.c:310:13: warning: declaration of ‘rcar_gen3_ths_tj_1’ shadows a global declaration [-Wshadow] 310 | const int *rcar_gen3_ths_tj_1 = of_device_get_match_data(dev); | ^~~~~~~~~~~~~~~~~~ drivers/thermal/rcar_gen3_thermal.c:246:18: note: shadowed declaration is here 246 | static const int rcar_gen3_ths_tj_1 = 126; | ^~~~~~~~~~~~~~~~~~ To add to the confusion, the local variable has a different type. Fix the shadowing by renaming the local variable to ths_tj_1. Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/9ea7e65d0331daba96f9a7925cb3d12d2170efb1.1623076804.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit bd40e2da3ae509a7045e29f38b2defd8cb8bce53 Author: Yang Yingliang Date: Mon May 17 13:10:20 2021 +0800 thermal/core: Correct function name thermal_zone_device_unregister() [ Upstream commit a052b5118f13febac1bd901fe0b7a807b9d6b51c ] Fix the following make W=1 kernel build warning: drivers/thermal/thermal_core.c:1376: warning: expecting prototype for thermal_device_unregister(). Prototype was for thermal_zone_device_unregister() instead Signed-off-by: Yang Yingliang Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210517051020.3463536-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 6c099d595fd79ac3b4ef3d57a73767ed1c9339a1 Author: Lucas Stach Date: Sat May 8 00:12:13 2021 +0200 arm64: dts: imx8mq: assign PCIe clocks [ Upstream commit 15a5261e4d052bf85c7fba24dbe0e9a7c8c05925 ] This fixes multiple issues with the current non-existent PCIe clock setup: The controller can run at up to 250MHz, so use a parent that provides this clock. The PHY needs an exact 100MHz reference clock to function if the PCIe refclock is not fed in via the refclock pads. While this mode is not supported (yet) in the driver it doesn't hurt to make sure we are providing a clock with the right rate. The AUX clock is specified to have a maximum clock rate of 10MHz. So the current setup, which drives it straight from the 25MHz oscillator is actually overclocking the AUX input. Signed-off-by: Lucas Stach Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 24c41aa9d01b0f23fd2a024218da41c27845dd42 Author: Mian Yousaf Kaukab Date: Wed Apr 28 14:58:07 2021 +0200 arm64: dts: ls208xa: remove bus-num from dspi node [ Upstream commit 8240c972c1798ea013cbb407722295fc826b3584 ] On LS2088A-RDB board, if the spi-fsl-dspi driver is built as module then its probe fails with the following warning: [ 10.471363] couldn't get idr [ 10.471381] WARNING: CPU: 4 PID: 488 at drivers/spi/spi.c:2689 spi_register_controller+0x73c/0x8d0 ... [ 10.471651] fsl-dspi 2100000.spi: Problem registering DSPI ctlr [ 10.471708] fsl-dspi: probe of 2100000.spi failed with error -16 Reason for the failure is that bus-num property is set for dspi node. However, bus-num property is not set for the qspi node. If probe for spi-fsl-qspi happens first then id 0 is dynamically allocated to it. Call to spi_register_controller() from spi-fsl-dspi driver then fails. Since commit 29d2daf2c33c ("spi: spi-fsl-dspi: Make bus-num property optional") bus-num property is optional. Remove bus-num property from dspi node to fix the issue. Signed-off-by: Mian Yousaf Kaukab Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 7e3f5739cccbf9cc8fd59d74e4f48055ca8ef531 Author: Thierry Reding Date: Tue Apr 13 14:23:35 2021 +0200 firmware: tegra: bpmp: Fix Tegra234-only builds [ Upstream commit bd778b893963d67d7eb01f49d84ffcd3eaf229dd ] The tegra186_bpmp_ops symbol is used on Tegra234, so make sure it's available. Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 7c03982fa134abe554d067206d0bdb5fe58a9930 Author: Thierry Reding Date: Tue Apr 13 14:20:57 2021 +0200 soc/tegra: fuse: Fix Tegra234-only builds [ Upstream commit e2d0ee225e49a5553986f3138dd2803852a31fd5 ] The tegra30_fuse_read() symbol is used on Tegra234, so make sure it's available. Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit ffa6f08be14acc511a8bdfaf70c66cfe3019edd3 Author: Tony Lindgren Date: Tue May 25 12:33:11 2021 +0300 ARM: OMAP2+: Block suspend for am3 and am4 if PM is not configured [ Upstream commit 093a474ce10d8ea3db3ef2922aca5a38f34bab1b ] If the PM related modules are not loaded and PM firmware not configured, the system suspend fails to resume. Let's fix this by adding initial platform_suspend_ops to block suspend and warn about missing modules. When pm33xx and wkup_m3_ipc have been loaded and m3 coprocessor booted with it's firmware, pm33xx sets up working platform_suspend_ops. Note that we need to configure at least PM_SUSPEND_STANDBY to have suspend_set_ops(). Cc: Dave Gerlach Cc: Suman Anna Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit f40a7c9b8ee19843cb1473f9de822733d21e73c5 Author: Alexandre Torgue Date: Thu Apr 15 12:10:33 2021 +0200 ARM: dts: stm32: fix stpmic node for stm32mp1 boards [ Upstream commit 4bf4abe19089245b7b12f35e5cafb5477b3e2c48 ] On some STM32 MP15 boards, stpmic node is not correct which generates warnings running "make dtbs_check W=1" command. Issues are: -"regulator-active-discharge" is not a boolean but an uint32. -"regulator-over-current-protection" is not a valid entry for vref_ddr. -LDO4 has a fixed voltage (3v3) so min/max entries are not allowed. Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 2670d3d1ef47cd15fb70d769dadc2dda81a681c2 Author: Marek Vasut Date: Thu Jun 10 02:25:52 2021 +0200 ARM: dts: stm32: Rename spi-flash/mx66l51235l@N to flash@N on DHCOM SoM [ Upstream commit 9b8a9b389d8464e1ca5a4e92c6a4422844ad4ef3 ] Fix the following dtbs_check warning: spi-flash@0: $nodename:0: 'spi-flash@0' does not match '^flash(@.*)?$' Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: kernel@dh-electronics.com Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 26cd441c529d0b3482b2358d39d3ed583d211fd3 Author: Marek Vasut Date: Thu Jun 10 02:25:50 2021 +0200 ARM: dts: stm32: Drop unused linux,wakeup from touchscreen node on DHCOM SoM [ Upstream commit 5247a50c8b53ca214a488da648e1bb35c35c2597 ] Fix the following dtbs_check warning: touchscreen@38: 'linux,wakeup' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: kernel@dh-electronics.com Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit a5bc2a2d838e81862f0f50f28e90288c322e9a22 Author: Grzegorz Szymaszek Date: Thu Jun 3 17:40:48 2021 +0200 ARM: dts: stm32: fix the Odyssey SoM eMMC VQMMC supply [ Upstream commit f493162319788802b6a49634f7268e691b4c10ec ] The Seeed SoM-STM32MP157C device tree had the eMMC’s (SDMMC2) VQMMC supply set to v3v3 (buck4), the same as the VMMC supply. That was incorrect, as on the SoM, the VQMMC supply is provided from vdd (buck3) instead. Signed-off-by: Grzegorz Szymaszek Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit e27052f21a2fd93868852d7982277b6c826d509e Author: Alexandre Torgue Date: Thu Apr 15 12:10:31 2021 +0200 ARM: dts: stm32: move stmmac axi config in ethernet node on stm32mp15 [ Upstream commit fb1406335c067be074eab38206cf9abfdce2fb0b ] It fixes the following warning seen running "make dtbs_check W=1" Warning (simple_bus_reg): /soc/stmmac-axi-config: missing or empty reg/ranges property Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 6a7af634781088be5ce9b673af487f2337f0cb90 Author: Alexandre Torgue Date: Thu Apr 15 12:10:30 2021 +0200 ARM: dts: stm32: fix i2c node name on stm32f746 to prevent warnings [ Upstream commit ad0ed10ba5792064fc3accbf8f0341152a57eecb ] Replace upper case by lower case in i2c nodes name. Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 160c92d728f3586ce61de8a3bf872222fdd085ae Author: Johan Jonker Date: Sun Jun 6 20:16:32 2021 +0200 ARM: dts: rockchip: fix supply properties in io-domains nodes [ Upstream commit f07edc41220b14ce057a4e6d7161b30688ddb8a2 ] A test with rockchip-io-domain.yaml gives notifications for supply properties in io-domains nodes. Fix them all into ".*-supply$" format. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210606181632.13371-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit d671fae046481abda92fe6af4a1d3bee7c585441 Author: Sudeep Holla Date: Tue Jun 8 15:51:33 2021 +0100 arm64: dts: juno: Update SCPI nodes as per the YAML schema [ Upstream commit 70010556b158a0fefe43415fb0c58347dcce7da0 ] The SCPI YAML schema expects standard node names for clocks and power domain controllers. Fix those as per the schema for Juno platforms. Link: https://lore.kernel.org/r/20210608145133.2088631-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit fc71d8df58070018fc013b091ed60cc464fd6313 Author: Stefan Wahren Date: Sun Jun 6 14:16:15 2021 +0200 ARM: dts: bcm283x: Fix up GPIO LED node names [ Upstream commit 5f30dacf37bc93308e91e4d0fc94681ca73f0f91 ] Fix the node names for the GPIO LEDs to conform to the standard node name led-.. Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/1622981777-5023-6-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Sasha Levin commit 4bc03e321f2a6ee45c07b477245e480f8b6d9756 Author: Stefan Wahren Date: Sun Jun 6 14:16:11 2021 +0200 ARM: dts: bcm283x: Fix up MMC node names [ Upstream commit f230c32349eb0a43a012a81c08a7f13859b86cbb ] Fix the node names for the MMC/SD card controller to conform to the standard node name mmc@.. Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/1622981777-5023-2-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Sasha Levin commit 15d727c044d588d1498ae31a071c065e0ce51e71 Author: Sudeep Holla Date: Thu Jun 3 08:26:31 2021 +0100 firmware: arm_scmi: Fix the build when CONFIG_MAILBOX is not selected [ Upstream commit ab7766b72855e6a68109b915d071181b93086e29 ] 0day CI kernel test robot reported following build error with randconfig aarch64-linux-ld: drivers/firmware/arm_scmi/driver.o:(.rodata+0x1e0): undefined reference to `scmi_mailbox_desc' Fix the error by adding CONFIG_MAILBOX dependency for scmi_mailbox_desc. Link: https://lore.kernel.org/r/20210603072631.1660963-1-sudeep.holla@arm.com Cc: Etienne Carriere Cc: Cristian Marussi Reviewed-by: Etienne Carriere Reviewed-by: Cristian Marussi Tested-by: Cristian Marussi Reported-by: kernel test robot Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit b4009ea92f291e4f88cd07bd1ddfb5f203d0e56b Author: Etienne Carriere Date: Fri May 21 15:40:51 2021 +0200 firmware: arm_scmi: Add SMCCC discovery dependency in Kconfig [ Upstream commit c05b07963e965ae34e75ee8c33af1095350cd87e ] ARM_SCMI_PROTOCOL depends on either MAILBOX or HAVE_ARM_SMCCC_DISCOVERY, not MAILBOX alone. Fix the depedency in Kconfig file and driver to reflect the same. Link: https://lore.kernel.org/r/20210521134055.24271-1-etienne.carriere@linaro.org Reviewed-by: Cristian Marussi Signed-off-by: Etienne Carriere [sudeep.holla: Minor tweaks to subject and change log] Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 41e2bcca23f1833402d1ec570519aa3486ea30fe Author: Dmitry Osipenko Date: Tue Jun 1 05:31:12 2021 +0300 memory: tegra: Fix compilation warnings on 64bit platforms [ Upstream commit e0740fb869730110b36a4afcf05ad1b9d6f5fb6d ] Fix compilation warning on 64bit platforms caused by implicit promotion of 32bit signed integer to a 64bit unsigned value which happens after enabling compile-testing of the EMC drivers. Reported-by: kernel test robot Reviewed-by: Nathan Chancellor Reviewed-by: Krzysztof Kozlowski Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 7ad965c8a723f68d44894cc00cfe7cb90ee2830d Author: Alexandre Torgue Date: Thu Apr 15 12:10:27 2021 +0200 ARM: dts: stm32: fix timer nodes on STM32 MCU to prevent warnings [ Upstream commit 2388f14d8747f8304e26ee870790e188c9431efd ] Prevent warning seen with "make dtbs_check W=1" command: Warning (avoid_unnecessary_addr_size): /soc/timers@40001c00: unnecessary address-cells/size-cells without "ranges" or child "reg" property Reviewed-by: Fabrice Gasnier Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit ccec32f771440c73955f2a5c41dbd352bf06a8db Author: Alexandre Torgue Date: Thu Apr 15 12:10:26 2021 +0200 ARM: dts: stm32: fix RCC node name on stm32f429 MCU [ Upstream commit e4b948415a89a219d13e454011cdcf9e63ecc529 ] This prevent warning observed with "make dtbs_check W=1" Warning (simple_bus_reg): /soc/rcc@40023810: simple-bus unit address format error, expected "40023800" Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit bfbc4b482078071abbb0515d8a0ba51255ebc414 Author: Alexandre Torgue Date: Thu Apr 15 12:10:25 2021 +0200 ARM: dts: stm32: fix gpio-keys node on STM32 MCU boards [ Upstream commit bf24b91f4baf7e421c770a1d9c7d381b10206ac9 ] Fix following warning observed with "make dtbs_check W=1" command. It concerns f429 eval and disco boards, f769 disco board. Warning (unit_address_vs_reg): /gpio_keys/button@0: node has a unit name, but no reg or ranges property Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 34ec6702a2a19edb29247ead712c7a7dfe2873c2 Author: Grzegorz Szymaszek Date: Sat Apr 10 21:35:21 2021 +0200 ARM: dts: stm32: fix stm32mp157c-odyssey card detect pin [ Upstream commit 0171b07373cc8c2815ca5fa79a7308fdefa54ca4 ] The microSD card detect pin is physically connected to the MPU pin PI3. The Device Tree configuration of the card detect pin was wrong—it was set to pin PB7 instead. If such configuration was used, the kernel would hang on “Waiting for root device” when booting from a microSD card. Signed-off-by: Grzegorz Szymaszek Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 44f4e344f4f06cd2d9bffc566557a72927b6e9f0 Author: Marek Vasut Date: Mon Apr 26 17:00:13 2021 +0200 ARM: dts: stm32: Fix touchscreen node on dhcom-pdk2 [ Upstream commit 4b5fadef3fc2ab8863ffdf31eed6a745b1bf6e61 ] Fix make dtbs_check warning: arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml:0:0: /soc/i2c@40015000/polytouch@38: failed to match any schema with compatible: ['edt,edt-ft5x06'] Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 3534a4b2d05940ca0f361ed3ec356b54c9bd0c9e Author: Marek Vasut Date: Mon Apr 26 17:00:12 2021 +0200 ARM: dts: stm32: Remove extra size-cells on dhcom-pdk2 [ Upstream commit 28b9a4679d8074512f12967497c161b992eb3b75 ] Fix make dtbs_check warning: arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: gpio-keys-polled: '#address-cells' is a dependency of '#size-cells' arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: gpio-keys: '#address-cells' is a dependency of '#size-cells' Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Marek Vasut Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 8da771b5527c51c04a9d00d4d3a577ef4b330807 Author: Sujit Kautkar Date: Fri May 14 11:34:34 2021 -0700 arm64: dts: qcom: sc7180: Move rmtfs memory region [ Upstream commit d4282fb4f8f9683711ae6c076da16aa8e675fdbd ] Move rmtfs memory region so that it does not overlap with system RAM (kernel data) when KAsan is enabled. This puts rmtfs right after mba_mem which is not supposed to increase beyond 0x94600000 Reviewed-by: Sibi Sankar Signed-off-by: Sujit Kautkar Link: https://lore.kernel.org/r/20210514113430.1.Ic2d032cd80424af229bb95e2c67dd4de1a70cb0c@changeid Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a74d3bbe055335ed1b0be384bcbd6abc75c5836b Author: Dmitry Osipenko Date: Mon May 10 23:26:00 2021 +0300 ARM: tegra: nexus7: Correct 3v3 regulator GPIO of PM269 variant [ Upstream commit c4dd6066bc304649e3159f1c7a08ece25d537e00 ] The 3v3 regulator GPIO is GP6 and not GP7, which is the DDR regulator. Both regulators are always-on, nevertheless the DT model needs to be corrected, fix it. Reported-by: Svyatoslav Ryhel Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit e89f4098d5283d7ea35a4532cfb0a98e74784cfd Author: Dmitry Osipenko Date: Mon May 10 23:25:55 2021 +0300 ARM: tegra: wm8903: Fix polarity of headphones-detection GPIO in device-trees [ Upstream commit 5f45da704de425d74abd75feaa928fc8a3df03ba ] All Tegra boards which use WM8903 audio codec are specifying a wrong polarity for the headphones detection GPIO. The kernel driver hardcodes the polarity to active-low, which is the correct polarity, so we can fix the device-trees safely. Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit c8815d6fee79cbcee942e18698d426bca7ea2797 Author: Grygorii Strashko Date: Wed May 26 16:20:41 2021 +0300 arm64: dts: ti: k3-am654x/j721e/j7200-common-proc-board: Fix MCU_RGMII1_TXC direction [ Upstream commit 69db725cdb2b803af67897a08ea54467d11f6020 ] The MCU RGMII MCU_RGMII1_TXC pin is defined as input by mistake, although this does not make any difference functionality wise it's better to update to avoid confusion. Hence fix MCU RGMII MCU_RGMII1_TXC pin pinmux definitions to be an output in K3 am654x/j721e/j7200 board files. Signed-off-by: Grygorii Strashko Reviewed-by: Vignesh Raghavendra Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20210526132041.6104-1-grygorii.strashko@ti.com Signed-off-by: Sasha Levin commit 28d2ae98154e470ab9bd0e36d556d02e8119b1ad Author: Suman Anna Date: Tue May 18 12:36:45 2021 -0500 ARM: dts: OMAP2+: Replace underscores in sub-mailbox node names [ Upstream commit 9e7f5ee1137397def6580461e27e5efcb68183ee ] A number of sub-mailbox node names in various OMAP2+ dts files are currently using underscores. This is not adhering to the node name convention, fix all of these to use hiphens. These nodes are already using the prefix mbox, so they will be in compliance with the sub-mailbox node name convention being added in the OMAP Mailbox YAML binding as well. Signed-off-by: Suman Anna Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit a73a22a69f6a2d377fa75362ec3b57e2ca265479 Author: Grygorii Strashko Date: Sat May 22 01:24:11 2021 +0300 ARM: dts: am335x: fix ti,no-reset-on-init flag for gpios [ Upstream commit d7d30b8fcd111e9feb171023c0e0c8d855582dcb ] The ti,no-reset-on-init flag need to be at the interconnect target module level for the modules that have it defined. The ti-sysc driver handles this case, but produces warning, not a critical issue. Signed-off-by: Grygorii Strashko Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit ddf2d14894d0fe99a5245f5131a6326222905eb0 Author: Grygorii Strashko Date: Sat May 22 01:24:10 2021 +0300 ARM: dts: am437x-gp-evm: fix ti,no-reset-on-init flag for gpios [ Upstream commit 2566d5b8c1670f7d7a44cc1426d254147ec5c421 ] The ti,no-reset-on-init flag need to be at the interconnect target module level for the modules that have it defined. The ti-sysc driver handles this case, but produces warning, not a critical issue. Signed-off-by: Grygorii Strashko Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit a09b4c444941f6f91de9bce453b16ea0c9bc93b2 Author: Grygorii Strashko Date: Sat May 22 01:24:09 2021 +0300 ARM: dts: am57xx-cl-som-am57x: fix ti,no-reset-on-init flag for gpios [ Upstream commit b644c5e01c870056e13a096e14b9a92075c8f682 ] The ti,no-reset-on-init flag need to be at the interconnect target module level for the modules that have it defined. The ti-sysc driver handles this case, but produces warning, not a critical issue. Signed-off-by: Grygorii Strashko Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 3f0948569997a6e561799d60ee71a40fdbb725da Author: Masahiro Yamada Date: Mon May 17 16:03:13 2021 +0900 kbuild: sink stdout from cmd for silent build [ Upstream commit 174a1dcc96429efce4ef7eb2f5c4506480da2182 ] When building with 'make -s', no output to stdout should be printed. As Arnd Bergmann reported [1], mkimage shows the detailed information of the generated images. I think this should be suppressed by the 'cmd' macro instead of by individual scripts. Insert 'exec >/dev/null;' in order to redirect stdout to /dev/null for silent builds. [Note about this implementation] 'exec >/dev/null;' may look somewhat tricky, but this has a reason. Appending '>/dev/null' at the end of command line is a common way for redirection, so I first tried this: cmd = @set -e; $(echo-cmd) $(cmd_$(1)) >/dev/null ... but it would not work if $(cmd_$(1)) itself contains a redirection. For example, cmd_wrap in scripts/Makefile.asm-generic redirects the output from the 'echo' command into the target file. It would be expanded into: echo "#include " > $@ >/dev/null Then, the target file gets empty because the string will go to /dev/null instead of $@. Next, I tried this: cmd = @set -e; $(echo-cmd) { $(cmd_$(1)); } >/dev/null The form above would be expanded into: { echo "#include " > $@; } >/dev/null This works as expected. However, it would be a syntax error if $(cmd_$(1)) is empty. When CONFIG_TRIM_UNUSED_KSYMS is disabled, $(call cmd,gen_ksymdeps) in scripts/Makefile.build would be expanded into: set -e; { ; } >/dev/null ..., which causes an syntax error. I also tried this: cmd = @set -e; $(echo-cmd) ( $(cmd_$(1)) ) >/dev/null ... but this causes a syntax error for the same reason. So, finally I adopted: cmd = @set -e; $(echo-cmd) exec >/dev/null; $(cmd_$(1)) [1]: https://lore.kernel.org/lkml/20210514135752.2910387-1-arnd@kernel.org/ Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 27582c9fa2946e63f292ab94d157681647f979c0 Author: Bixuan Cui Date: Sat May 8 11:15:09 2021 +0800 rtc: mxc_v2: add missing MODULE_DEVICE_TABLE [ Upstream commit 206e04ec7539e7bfdde9aa79a7cde656c9eb308e ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Bixuan Cui Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210508031509.53735-1-cuibixuan@huawei.com Signed-off-by: Sasha Levin commit 6f5891a560dff4b3695a8533c02eeedd39b3ccb9 Author: Oleksij Rempel Date: Tue May 11 06:30:39 2021 +0200 ARM: dts: imx6dl-riotboard: configure PHY clock and set proper EEE value [ Upstream commit 723de6a4126b2474a8106e943749e1554012dad6 ] Without SoC specific PHY fixups the network interface on this board will fail to work. Provide missing DT properties to make it work again. Signed-off-by: Oleksij Rempel Reviewed-by: Andrew Lunn Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5190a6604a106e2ad9831d7662bec4ab1492a3a2 Author: Linus Walleij Date: Sat May 15 02:02:34 2021 +0200 ARM: dts: ux500: Fix orientation of accelerometer [ Upstream commit 4beba4011995a2c44ee27e1d358dc32e6b9211b3 ] This adds a mounting matrix to the accelerometer on the TVK1281618 R3. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 61fda04276bb08d4a74fba2d7d68639f2a282fe6 Author: Sebastian Reichel Date: Tue Apr 13 01:03:17 2021 +0200 ARM: dts: ux500: Rename gpio-controller node [ Upstream commit 4917b702818872fdf2a9973705af3aa7d3d1f19e ] Rename the AB8500 gpio controller node from ab8500-gpio to ab8500-gpiocontroller, since -gpio is a common suffix for gpio consumers. Signed-off-by: Sebastian Reichel Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 985947c53555bfbba4a66c18826186398c9e1361 Author: Sebastian Reichel Date: Tue Apr 13 01:03:16 2021 +0200 ARM: dts: ux500: Fix interrupt cells [ Upstream commit e4ff0112a03c2e353c8457cd33c88feb89dfec41 ] Fix interrupt cells in DT AB8500/AB8505 source files. The compiled DTB files will stay the same. Signed-off-by: Sebastian Reichel Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ff9ef21bb6fb9ce4c17a1035048fa01db8bc0abf Author: Johan Jonker Date: Mon May 10 23:58:40 2021 +0200 arm64: dts: rockchip: fix regulator-gpio states array [ Upstream commit b82f8e2992534aab0fa762a37376be30df263701 ] A test with the command below gives this error: /arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml: sdmmcio-regulator: states:0: [1800000, 1, 3300000, 0] is too long dtbs_check expects regulator-gpio states in a format of 2 per item, so fix them all. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ regulator/gpio-regulator.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210510215840.16270-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 31e1b8c07d358da3b0cf6b55c18caa7cc89bcc6c Author: Jonathan Neuschäfer Date: Sat Apr 24 14:37:28 2021 +0200 ARM: imx: pm-imx5: Fix references to imx5_cpu_suspend_info [ Upstream commit 89b759469d525f4d5f9c29cd3b1f490311c67f85 ] The name of the struct, as defined in arch/arm/mach-imx/pm-imx5.c, is imx5_cpu_suspend_info. Signed-off-by: Jonathan Neuschäfer Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit d05ebeffca1d42734e012ede2fef5c5a76677224 Author: Primoz Fiser Date: Mon Apr 12 08:24:50 2021 +0200 ARM: dts: imx6: phyFLEX: Fix UART hardware flow control [ Upstream commit 14cdc1f243d79e0b46be150502b7dba9c5a6bdfd ] Serial interface uart3 on phyFLEX board is capable of 5-wire connection including signals RTS and CTS for hardware flow control. Fix signals UART3_CTS_B and UART3_RTS_B padmux assignments and add missing property "uart-has-rtscts" to allow serial interface to be configured and used with the hardware flow control. Signed-off-by: Primoz Fiser Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 249d8e4ea168ad979cc418b280e7d1ae0a5f618a Author: Rafał Miłecki Date: Fri Apr 16 15:37:53 2021 +0200 ARM: dts: Hurricane 2: Fix NAND nodes names [ Upstream commit a4528d9029e2eda16e4fc9b9da1de1fbec10ab26 ] This matches nand-controller.yaml requirements. Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit f6541401dbd6db1e93d72df3dd6337011b8012a6 Author: Rafał Miłecki Date: Fri Apr 16 15:37:52 2021 +0200 ARM: dts: BCM63xx: Fix NAND nodes names [ Upstream commit 75e2f012f6e34b93124d1d86eaa8f27df48e9ea0 ] This matches nand-controller.yaml requirements. Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit b5fc6b9ab427839fef07a427fe4a8af7067ebfcd Author: Rafał Miłecki Date: Fri Apr 16 15:37:51 2021 +0200 ARM: NSP: dts: fix NAND nodes names [ Upstream commit 0484594be733d5cdf976f55a2d4e8d887f351b69 ] This matches nand-controller.yaml requirements. Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 5f844007eb915c18ee3b15f4bca805625cd78709 Author: Rafał Miłecki Date: Fri Apr 16 15:37:50 2021 +0200 ARM: Cygnus: dts: fix NAND nodes names [ Upstream commit e256b48a3b07ee1ae4bfa60abbf509ba8e386862 ] This matches nand-controller.yaml requirements. Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 9525d58c5af89400a7129f204fe7ab8ad1a153c1 Author: Rafał Miłecki Date: Fri Apr 16 15:37:49 2021 +0200 ARM: brcmstb: dts: fix NAND nodes names [ Upstream commit 9a800ce1aada6e0f56b78e4713f4858c8990c1f7 ] This matches nand-controller.yaml requirements. Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 4e8eb51ae633d14544b212675717dc6e2850ee6a Author: Philipp Zabel Date: Thu Mar 4 17:01:39 2021 +0100 reset: ti-syscon: fix to_ti_syscon_reset_data macro [ Upstream commit 05cf8fffcdeb47aef1203c08cbec5224fd3a0e1c ] The to_ti_syscon_reset_data macro currently only works if the parameter passed into it is called 'rcdev'. Fixes a checkpatch --strict issue: CHECK: Macro argument reuse 'rcdev' - possible side-effects? #53: FILE: drivers/reset/reset-ti-syscon.c:53: +#define to_ti_syscon_reset_data(rcdev) \ + container_of(rcdev, struct ti_syscon_reset_data, rcdev) Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit cabcb576fc3e915669feff9c1976b6f545d4cccc Author: Elaine Zhang Date: Sat Apr 17 13:29:44 2021 +0200 arm64: dts: rockchip: Fix power-controller node names for rk3399 [ Upstream commit 148bbe29f9108812c6fedd8a228f9e1ed6b422f7 ] Use more generic names (as recommended in the device tree specification or the binding documentation) Signed-off-by: Elaine Zhang Reviewed-by: Enric Balletbo i Serra Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210417112952.8516-8-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 81ea23d988f9cfebfd501418b68391b6774d93d0 Author: Elaine Zhang Date: Sat Apr 17 13:29:43 2021 +0200 arm64: dts: rockchip: Fix power-controller node names for rk3328 [ Upstream commit 6e6a282b49c6db408d27231e3c709fbdf25e3c1b ] Use more generic names (as recommended in the device tree specification or the binding documentation) Signed-off-by: Elaine Zhang Reviewed-by: Enric Balletbo i Serra Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210417112952.8516-7-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e4f97b740d6a5e866ae48d065445f5a74fead056 Author: Elaine Zhang Date: Sat Apr 17 13:29:42 2021 +0200 arm64: dts: rockchip: Fix power-controller node names for px30 [ Upstream commit d5de0d688ac6e0202674577b05d0726b8a6af401 ] Use more generic names (as recommended in the device tree specification or the binding documentation) Signed-off-by: Elaine Zhang Reviewed-by: Enric Balletbo i Serra Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210417112952.8516-6-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 95b64be2e7414e42a59a4fa9239c92e96210b399 Author: Elaine Zhang Date: Sat Apr 17 13:29:40 2021 +0200 ARM: dts: rockchip: Fix power-controller node names for rk3288 [ Upstream commit 970cdc53cb1afa73602028c103dbfb6a230080be ] Use more generic names (as recommended in the device tree specification or the binding documentation) Signed-off-by: Elaine Zhang Reviewed-by: Enric Balletbo i Serra Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210417112952.8516-4-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 5881af8d692bfe710ff3e86257cef4a017a35b7d Author: Elaine Zhang Date: Sat Apr 17 13:29:39 2021 +0200 ARM: dts: rockchip: Fix power-controller node names for rk3188 [ Upstream commit d3bcbcd396175ac26aa54919c0b31c7d2878fc24 ] Use more generic names (as recommended in the device tree specification or the binding documentation) Signed-off-by: Elaine Zhang Reviewed-by: Enric Balletbo i Serra Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210417112952.8516-3-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 70abb828312aa374f3da08ed0954ff562f8cf1ae Author: Elaine Zhang Date: Sat Apr 17 13:29:38 2021 +0200 ARM: dts: rockchip: Fix power-controller node names for rk3066a [ Upstream commit f2948781a72f0d8cf2adf31758c357f2f35e6c79 ] Use more generic names (as recommended in the device tree specification or the binding documentation) Signed-off-by: Elaine Zhang Reviewed-by: Enric Balletbo i Serra Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210417112952.8516-2-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit fc01549d7b8732b06c4394e003ac0586aec72090 Author: Benjamin Gaignard Date: Fri May 7 11:02:29 2021 +0200 ARM: dts: rockchip: Fix IOMMU nodes properties on rk322x [ Upstream commit 6b023929666f0be5df75f5e0278d1b70effadf42 ] Add '#" to iommu-cells properties. Remove useless interrupt-names properties Signed-off-by: Benjamin Gaignard Link: https://lore.kernel.org/r/20210507090232.233049-4-benjamin.gaignard@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 55014c38e73d00e88d152e9deb0fc8c01e755c9a Author: Ezequiel Garcia Date: Thu May 6 08:11:35 2021 -0300 ARM: dts: rockchip: Fix the timer clocks order [ Upstream commit 7b46d674ac000b101fdad92cf16cc11d90b72f86 ] Fixed order is the device-tree convention. The timer driver currently gets clocks by name, so no changes are needed there. Signed-off-by: Ezequiel Garcia Link: https://lore.kernel.org/r/20210506111136.3941-3-ezequiel@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 2e1f681b680c8086cfda715987201541f500afc1 Author: Johan Jonker Date: Tue Jan 26 12:02:21 2021 +0100 arm64: dts: rockchip: fix pinctrl sleep nodename for rk3399.dtsi [ Upstream commit a7ecfad495f8af63a5cb332c91f60ab2018897f5 ] A test with the command below aimed at powerpc generates notifications in the Rockchip arm64 tree. Fix pinctrl "sleep" nodename by renaming it to "suspend" for rk3399.dtsi make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/powerpc/sleep.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210126110221.10815-2-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 7d3408c723364320c1552e034a8e808ec50e7e08 Author: Johan Jonker Date: Tue Jan 26 12:02:20 2021 +0100 ARM: dts: rockchip: fix pinctrl sleep nodename for rk3036-kylin and rk3288 [ Upstream commit dfbfb86a43f9a5bbd166d88bca9e07ee4e1bff31 ] A test with the command below aimed at powerpc generates notifications in the Rockchip ARM tree. Fix pinctrl "sleep" nodename by renaming it to "suspend" for rk3036-kylin and rk3288 make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/powerpc/sleep.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20210126110221.10815-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e2d1e44161749bcbcc6d6c01a77af8340071b8f8 Author: Ezequiel Garcia Date: Thu May 6 14:55:11 2021 -0300 ARM: dts: rockchip: Fix thermal sensor cells o rk322x [ Upstream commit d5c24e20daf09587cbc221d40be1ba92673e8d94 ] The number of cells to be used with a thermal sensor specifier must be "1". Fix this. Signed-off-by: Ezequiel Garcia Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20210506175514.168365-2-ezequiel@collabora.com Signed-off-by: Sasha Levin commit c8f0cef75dd799a89cae0e050c1c9013673d5e33 Author: Corentin Labbe Date: Mon May 3 18:52:28 2021 +0000 ARM: dts: gemini: add device_type on pci [ Upstream commit 483f3645b3f7acfd1c78a19d51b80c0656161974 ] Fixes DT warning on pci node by adding the missing device_type. Signed-off-by: Corentin Labbe Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 191523dcfa68cdaefec341f5e1d6f1013be1d44b Author: Corentin Labbe Date: Wed Apr 28 17:48:30 2021 +0000 ARM: dts: gemini: rename mdio to the right name [ Upstream commit fc5b59b945b546e27977e99a5ca6fe61179ff0d2 ] ethernet-phy is not the right name for mdio, fix it. Signed-off-by: Corentin Labbe Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin