aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-08-10Revert "net: usb: ax88179_178a needs FLAG_SEND_ZLP"Jose Alonso1-13/+13
This reverts commit 36a15e1cb134c0395261ba1940762703f778438c. The usage of FLAG_SEND_ZLP causes problems to other firmware/hardware versions that have no issues. The FLAG_SEND_ZLP is not safe to use in this context. See: https://patchwork.ozlabs.org/project/netdev/patch/1270599787.8900.8.camel@Linuxdev4-laptop/#118378 The original problem needs another way to solve. Fixes: 36a15e1cb134 ("net: usb: ax88179_178a needs FLAG_SEND_ZLP") Cc: [email protected] Reported-by: Ronald Wahl <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216327 Link: https://bugs.archlinux.org/task/75491 Signed-off-by: Jose Alonso <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-08-10netlabel: fix typo in commentTopi Miettinen1-1/+1
'IPv4 and IPv4' should be 'IPv4 and IPv6'. Signed-off-by: Topi Miettinen <[email protected]> Acked-by: Paul Moore <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-08-10Merge tag 'linux-can-fixes-for-6.0-20220810' of ↵David S. Miller4-6/+27
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== this is a pull request of 4 patches for net/master, with the whitespace issue fixed. Fedor Pchelkin contributes 2 fixes for the j1939 CAN protocol. A patch by me for the ems_usb driver fixes an unaligned access warning. Sebastian Würl's patch for the mcp251x driver fixes a race condition in the receive interrupt. ==================== Signed-off-by: David S. Miller <[email protected]>
2022-08-10hwmon: (lm90) Fix error return value from detect functionGuenter Roeck1-1/+1
lm90_detect_nuvoton() is supposed to return NULL if it can not detect a chip, or a pointer to the chip name if it does. Under some circumstances it returns an error pointer instead. Some versions of gcc interpret an ERR_PTR as region of size 0 and generate an error message. In function ‘__fortify_strlen’, inlined from ‘strlcpy’ at ./include/linux/fortify-string.h:159:10, inlined from ‘lm90_detect’ at drivers/hwmon/lm90.c:2550:2: ./include/linux/fortify-string.h:50:33: error: ‘__builtin_strlen’ reading 1 or more bytes from a region of size 0 50 | #define __underlying_strlen __builtin_strlen | ^ ./include/linux/fortify-string.h:141:24: note: in expansion of macro ‘__underlying_strlen’ 141 | return __underlying_strlen(p); | ^~~~~~~~~~~~~~~~~~~ Returning NULL instead of ERR_PTR() fixes the problem. Fixes: c7cebce984a2 ("hwmon: (lm90) Rework detect function") Reported-by: Ingo Molnar <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Kees Cook <[email protected]> Tested-by: Ingo Molnar <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2022-08-10powerpc/kexec: Fix build failure from uninitialised variableRussell Currey1-5/+5
clang 14 won't build because ret is uninitialised and can be returned if both prop and fdtprop are NULL. Drop the ret variable and return an error in that failure case. Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window") Suggested-by: Christophe Leroy <[email protected]> Signed-off-by: Russell Currey <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-08-10powerpc/ppc-opcode: Fix PPC_RAW_TW()Christophe Leroy1-1/+1
PPC_RAW_TW() is erroneously defined with base code 0x7f000008 instead of 0x7c000008. That's invisible because its only user is PPC_RAW_TRAP() which is 0x7fe00008, but fix it anyway to avoid any risk of future bug. Fixes: d00d762daf12 ("powerpc/ppc-opcode: Define and use PPC_RAW_TRAP() and PPC_RAW_TW()") Reported-by: Naveen N. Rao <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Reviewed-by: Naveen N. Rao <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/eca9251f1e1f82c4c46ec6380ddb28356ab3fdfe.1659527244.git.christophe.leroy@csgroup.eu
2022-08-10powerpc64/ftrace: Fix ftrace for clang buildsNaveen N. Rao1-4/+4
Clang doesn't support -mprofile-kernel ABI, so guard the checks against CONFIG_DYNAMIC_FTRACE_WITH_REGS, rather than the elf ABI version. Fixes: 23b44fc248f4 ("powerpc/ftrace: Make __ftrace_make_{nop/call}() common to PPC32 and PPC64") Cc: [email protected] # v5.19+ Reported-by: Nick Desaulniers <[email protected]> Reported-by: Ondrej Mosnacek <[email protected]> Signed-off-by: Naveen N. Rao <[email protected]> Tested-by: Ondrej Mosnacek <[email protected]> Acked-by: Nick Desaulniers <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://github.com/llvm/llvm-project/issues/57031 Link: https://github.com/ClangBuiltLinux/linux/issues/1682 Link: https://lore.kernel.org/r/[email protected]
2022-08-10powerpc: Make eh value more explicit when using lwarxChristophe Leroy1-2/+3
Just like the first patch of this series, define a local 'eh' in order to make the code clearer. And IS_ENABLED() returns either 1 or 0 so no need to do IS_ENABLED(CONFIG_PPC64) ? 1 : 0. Signed-off-by: Christophe Leroy <[email protected]> [mpe: Use symbolic names, use 'n' constraint per Segher] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/629befaa2d05e2922346e58a383886510d6af55a.1659430931.git.christophe.leroy@csgroup.eu
2022-08-10powerpc: Don't hide eh field of lwarx behind a macroChristophe Leroy2-12/+3
The eh field must remain 0 for PPC32 and is only used by PPC64. Don't hide that behind a macro, just leave the responsibility to the user. At the time being, the only users of PPC_RAW_L{WDQ}ARX are setting the eh field to 0, so the special handling of __PPC_EH is useless. Just take the value given by the caller. Same for DEFINE_TESTOP(), don't do special handling in that macro, ensure the caller hands over the proper eh value. Signed-off-by: Christophe Leroy <[email protected]> [mpe: Use 'n' constraint per Segher] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/8b9c8a1a14f9143552a85fcbf96698224a8c2469.1659430931.git.christophe.leroy@csgroup.eu
2022-08-10powerpc: Fix eh field when calling lwarx on PPC32Christophe Leroy1-6/+9
Commit 9401f4e46cf6 ("powerpc: Use lwarx/ldarx directly instead of PPC_LWARX/LDARX macros") properly handled the eh field of lwarx in asm/bitops.h but failed to clear it for PPC32 in asm/simple_spinlock.h So, do as in arch_atomic_try_cmpxchg_lock(), set it to 1 if PPC64 but set it to 0 if PPC32. For that use IS_ENABLED(CONFIG_PPC64) which returns 1 when CONFIG_PPC64 is set and 0 otherwise. Fixes: 9401f4e46cf6 ("powerpc: Use lwarx/ldarx directly instead of PPC_LWARX/LDARX macros") Cc: [email protected] # v5.15+ Reported-by: Pali Rohár <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Tested-by: Pali Rohár <[email protected]> Reviewed-by: Segher Boessenkool <[email protected]> [mpe: Use symbolic names, use 'n' constraint per Segher] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/a1176e19e627dd6a1b8d24c6c457a8ab874b7d12.1659430931.git.christophe.leroy@csgroup.eu
2022-08-09Merge branch 'do-not-use-rt_tos-for-ipv6-flowlabel'Jakub Kicinski4-7/+5
Matthias May says: ==================== Do not use RT_TOS for IPv6 flowlabel According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09ipv6: do not use RT_TOS for IPv6 flowlabelMatthias May1-2/+1
According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Acked-by: Guillaume Nault <[email protected]> Signed-off-by: Matthias May <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09mlx5: do not use RT_TOS for IPv6 flowlabelMatthias May1-2/+2
According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: ce99f6b97fcd ("net/mlx5e: Support SRIOV TC encapsulation offloads for IPv6 tunnels") Acked-by: Guillaume Nault <[email protected]> Signed-off-by: Matthias May <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09vxlan: do not use RT_TOS for IPv6 flowlabelMatthias May1-1/+1
According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class") Acked-by: Guillaume Nault <[email protected]> Signed-off-by: Matthias May <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09geneve: do not use RT_TOS for IPv6 flowlabelMatthias May1-2/+1
According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 3a56f86f1be6 ("geneve: handle ipv6 priority like ipv4 tos") Acked-by: Guillaume Nault <[email protected]> Signed-off-by: Matthias May <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09geneve: fix TOS inheriting for ipv4Matthias May1-4/+8
The current code retrieves the TOS field after the lookup on the ipv4 routing table. The routing process currently only allows routing based on the original 3 TOS bits, and not on the full 6 DSCP bits. As a result the retrieved TOS is cut to the 3 bits. However for inheriting purposes the full 6 bits should be used. Extract the full 6 bits before the route lookup and use that instead of the cut off 3 TOS bits. Fixes: e305ac6cf5a1 ("geneve: Add support to collect tunnel metadata.") Signed-off-by: Matthias May <[email protected]> Acked-by: Guillaume Nault <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09net: atlantic: fix aq_vec index out of range errorChia-Lin Kao (AceLan)1-13/+8
The final update statement of the for loop exceeds the array range, the dereference of self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of coding style in other for loop. [ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2 [ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022 [ 97.937611] Workqueue: events_unbound async_run_entry_fn [ 97.937616] Call Trace: [ 97.937617] <TASK> [ 97.937619] dump_stack_lvl+0x49/0x63 [ 97.937624] dump_stack+0x10/0x16 [ 97.937626] ubsan_epilogue+0x9/0x3f [ 97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 97.937629] ? __scm_send+0x348/0x440 [ 97.937632] ? aq_vec_stop+0x72/0x80 [atlantic] [ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic] [ 97.937644] aq_suspend_common+0x88/0x90 [atlantic] [ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic] [ 97.937653] pci_pm_suspend+0x7e/0x1a0 [ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0 [ 97.937657] dpm_run_callback+0x54/0x190 [ 97.937660] __device_suspend+0x14c/0x4d0 [ 97.937661] async_suspend+0x23/0x70 [ 97.937663] async_run_entry_fn+0x33/0x120 [ 97.937664] process_one_work+0x21f/0x3f0 [ 97.937666] worker_thread+0x4a/0x3c0 [ 97.937668] ? process_one_work+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [ 97.937671] ? kthread_complete_and_exit+0x20/0x20 [ 97.937672] ret_from_fork+0x22/0x30 [ 97.937676] </TASK> v2. fixed "warning: variable 'aq_vec' set but not used" v3. simplified a for loop Fixes: 97bde5c4f909 ("net: ethernet: aquantia: Support for NIC-specific code") Signed-off-by: Chia-Lin Kao (AceLan) <[email protected]> Acked-by: Sudarsana Reddy Kalluru <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09ax88796: Fix some typo in a commentChristophe JAILLET1-2/+2
s/by caused/be caused/ s/ax88786/ax88796/ Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/7db4b622d2c3e5af58c1d1f32b81836f4af71f18.1659801746.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nfJakub Kicinski8-138/+222
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Harden set element field checks to avoid out-of-bound memory access, this patch also fixes the type of issue described in 7e6bc1f6cabc ("netfilter: nf_tables: stricter validation of element data") in a broader way. 2) Patches to restrict the chain, set, and rule id lookup in the transaction to the corresponding top-level table, patches from Thadeu Lima de Souza Cascardo. 3) Fix incorrect comment in ip6t_LOG.h 4) nft_data_init() performs upfront validation of the expected data. struct nft_data_desc is used to describe the expected data to be received from userspace. The .size field represents the maximum size that can be stored, for bound checks. Then, .len is an input/output field which stores the expected length as input (this is optional, to restrict the checks), as output it stores the real length received from userspace (if it was not specified as input). This patch comes in response to 7e6bc1f6cabc ("netfilter: nf_tables: stricter validation of element data") to address this type of issue in a more generic way by avoid opencoded data validation. Next patch requires this as a dependency. 5) Disallow jump to implicit chain from set element, this configuration is invalid. Only allow jump to chain via immediate expression is supported at this stage. 6) Fix possible null-pointer derefence in the error path of table updates, if memory allocation of the transaction fails. From Florian Westphal. * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: fix null deref due to zeroed list head netfilter: nf_tables: disallow jump to implicit chain from set element netfilter: nf_tables: upfront validation of data via nft_data_init() netfilter: ip6t_LOG: Fix a typo in a comment netfilter: nf_tables: do not allow RULE_ID to refer to another chain netfilter: nf_tables: do not allow CHAIN_ID to refer to another table netfilter: nf_tables: do not allow SET_ID to refer to another table netfilter: nf_tables: validate variable length element extension ==================== Link: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09Merge branch 'Don't reinit map value in prealloc_lru_pop'Alexei Starovoitov4-5/+72
Kumar Kartikeya Dwivedi says: ==================== Fix for a bug in prealloc_lru_pop spotted while reading the code, then a test + example that checks whether it is fixed. Changelog: ---------- v2 -> v3: v2: https://lore.kernel.org/bpf/[email protected] * Switch test to use kptr instead of kptr_ref to stabilize test runs * Fix missing lru_bug__destroy (Yonghong) * Collect Acks v1 -> v2: v1: https://lore.kernel.org/bpf/[email protected] * Expand commit log to include summary of the discussion with Yonghong * Make lru_bug selftest serial to not mess up refcount for map_kptr test ==================== Signed-off-by: Alexei Starovoitov <[email protected]>
2022-08-09selftests/bpf: Add test for prealloc_lru_pop bugKumar Kartikeya Dwivedi2-0/+70
Add a regression test to check against invalid check_and_init_map_value call inside prealloc_lru_pop. The kptr should not be reset to NULL once we set it after deleting the map element. Hence, we trigger a program that updates the element causing its reuse, and checks whether the unref kptr is reset or not. If it is, prealloc_lru_pop does an incorrect check_and_init_map_value call and the test fails. Acked-by: Yonghong Song <[email protected]> Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2022-08-09bpf: Don't reinit map value in prealloc_lru_popKumar Kartikeya Dwivedi1-5/+1
The LRU map that is preallocated may have its elements reused while another program holds a pointer to it from bpf_map_lookup_elem. Hence, only check_and_free_fields is appropriate when the element is being deleted, as it ensures proper synchronization against concurrent access of the map value. After that, we cannot call check_and_init_map_value again as it may rewrite bpf_spin_lock, bpf_timer, and kptr fields while they can be concurrently accessed from a BPF program. This is safe to do as when the map entry is deleted, concurrent access is protected against by check_and_free_fields, i.e. an existing timer would be freed, and any existing kptr will be released by it. The program can create further timers and kptrs after check_and_free_fields, but they will eventually be released once the preallocated items are freed on map destruction, even if the item is never reused again. Hence, the deleted item sitting in the free list can still have resources attached to it, and they would never leak. With spin_lock, we never touch the field at all on delete or update, as we may end up modifying the state of the lock. Since the verifier ensures that a bpf_spin_lock call is always paired with bpf_spin_unlock call, the program will eventually release the lock so that on reuse the new user of the value can take the lock. Essentially, for the preallocated case, we must assume that the map value may always be in use by the program, even when it is sitting in the freelist, and handle things accordingly, i.e. use proper synchronization inside check_and_free_fields, and never reinitialize the special fields when it is reused on update. Fixes: 68134668c17f ("bpf: Add map side support for bpf timers.") Acked-by: Yonghong Song <[email protected]> Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2022-08-09bpf: Allow calling bpf_prog_test kfuncs in tracing programsKumar Kartikeya Dwivedi1-0/+1
In addition to TC hook, enable these in tracing programs so that they can be used in selftests. Acked-by: Yonghong Song <[email protected]> Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2022-08-09dt-bindings: mfd: convert to yaml Qualcomm SPMI PMICDavid Heidelberg2-94/+190
Convert Qualcomm SPMI PMIC binding to yaml format. Additional changes: - filled many missing compatibles Co-developed-by: Caleb Connolly <[email protected]> Signed-off-by: David Heidelberg <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-08-09dm writecache: fix smatch warning about invalid return from writecache_mapMikulas Patocka1-1/+2
There's a smatch warning "inconsistent returns '&wc->lock'" in dm-writecache. The reason for the warning is that writecache_map() doesn't drop the lock on the impossible path. Fix this warning by adding wc_unlock() after the BUG statement (so that it will be compiled-away anyway). Fixes: df699cc16ea5e ("dm writecache: report invalid return from writecache_map helpers") Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2022-08-09dm verity: fix verity_parse_opt_args parsingMike Snitzer1-1/+11
Commit df326e7a0699 ("dm verity: allow optional args to alter primary args handling") introduced a bug where verity_parse_opt_args() wouldn't properly shift past an optional argument's additional params (by ignoring them). Fix this by avoiding returning with error if an unknown argument is encountered when @only_modifier_opts=true is passed to verity_parse_opt_args(). In practice this regressed the cryptsetup testsuite's FEC testing because unknown optional arguments were encountered, wherey short-circuiting ever testing FEC mode. With this fix all of the cryptsetup testsuite's verity FEC tests pass. Fixes: df326e7a0699 ("dm verity: allow optional args to alter primary args handling") Reported-by: Milan Broz <[email protected]>> Signed-off-by: Mike Snitzer <[email protected]>
2022-08-09dm verity: fix DM_VERITY_OPTS_MAX value yet againMike Snitzer1-1/+1
Must account for the possibility that "try_verify_in_tasklet" is used. This is the same issue that was fixed with commit 160f99db94322 -- it is far too easy to miss that additional a new argument(s) require bumping DM_VERITY_OPTS_MAX accordingly. Fixes: 5721d4e5a9cd ("dm verity: Add optional "try_verify_in_tasklet" feature") Signed-off-by: Mike Snitzer <[email protected]>
2022-08-09dm bufio: simplify DM_BUFIO_CLIENT_NO_SLEEP lockingMike Snitzer1-6/+4
Historically none of the bufio code runs in interrupt context but with the use of DM_BUFIO_CLIENT_NO_SLEEP a bufio client can, see: commit 5721d4e5a9cd ("dm verity: Add optional "try_verify_in_tasklet" feature") That said, the new tasklet usecase still doesn't require interrupts be disabled by bufio (let alone conditionally restore them). Yet with PREEMPT_RT, and falling back from tasklet to workqueue, care must be taken to properly synchronize between softirq and process context, otherwise ABBA deadlock may occur. While it is unnecessary to disable bottom-half preemption within a tasklet, we must consistently do so in process context to ensure locking is in the proper order. Fix these issues by switching from spin_lock_irq{save,restore} to using spin_{lock,unlock}_bh instead. Also remove the 'spinlock_flags' member in dm_bufio_client struct (that can be used unsafely if bufio must recurse on behalf of some caller, e.g. block layer's submit_bio). Fixes: 5721d4e5a9cd ("dm verity: Add optional "try_verify_in_tasklet" feature") Reported-by: Jens Axboe <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2022-08-09add barriers to buffer_uptodate and set_buffer_uptodateMikulas Patocka1-1/+24
Let's have a look at this piece of code in __bread_slow: get_bh(bh); bh->b_end_io = end_buffer_read_sync; submit_bh(REQ_OP_READ, 0, bh); wait_on_buffer(bh); if (buffer_uptodate(bh)) return bh; Neither wait_on_buffer nor buffer_uptodate contain any memory barrier. Consequently, if someone calls sb_bread and then reads the buffer data, the read of buffer data may be executed before wait_on_buffer(bh) on architectures with weak memory ordering and it may return invalid data. Fix this bug by adding a memory barrier to set_buffer_uptodate and an acquire barrier to buffer_uptodate (in a similar way as folio_test_uptodate and folio_mark_uptodate). Signed-off-by: Mikulas Patocka <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
2022-08-09Merge tag 'nfsd-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linuxLinus Torvalds33-945/+1426
Pull nfsd updates from Chuck Lever: "Work on 'courteous server', which was introduced in 5.19, continues apace. This release introduces a more flexible limit on the number of NFSv4 clients that NFSD allows, now that NFSv4 clients can remain in courtesy state long after the lease expiration timeout. The client limit is adjusted based on the physical memory size of the server. The NFSD filecache is a cache of files held open by NFSv4 clients or recently touched by NFSv2 or NFSv3 clients. This cache had some significant scalability constraints that have been relieved in this release. Thanks to all who contributed to this work. A data corruption bug found during the most recent NFS bake-a-thon that involves NFSv3 and NFSv4 clients writing the same file has been addressed in this release. This release includes several improvements in CPU scalability for NFSv4 operations. In addition, Neil Brown provided patches that simplify locking during file lookup, creation, rename, and removal that enables subsequent work on making these operations more scalable. We expect to see that work materialize in the next release. There are also numerous single-patch fixes, clean-ups, and the usual improvements in observability" * tag 'nfsd-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: (78 commits) lockd: detect and reject lock arguments that overflow NFSD: discard fh_locked flag and fh_lock/fh_unlock NFSD: use (un)lock_inode instead of fh_(un)lock for file operations NFSD: use explicit lock/unlock for directory ops NFSD: reduce locking in nfsd_lookup() NFSD: only call fh_unlock() once in nfsd_link() NFSD: always drop directory lock in nfsd_unlink() NFSD: change nfsd_create()/nfsd_symlink() to unlock directory before returning. NFSD: add posix ACLs to struct nfsd_attrs NFSD: add security label to struct nfsd_attrs NFSD: set attributes when creating symlinks NFSD: introduce struct nfsd_attrs NFSD: verify the opened dentry after setting a delegation NFSD: drop fh argument from alloc_init_deleg NFSD: Move copy offload callback arguments into a separate structure NFSD: Add nfsd4_send_cb_offload() NFSD: Remove kmalloc from nfsd4_do_async_copy() NFSD: Refactor nfsd4_do_copy() NFSD: Refactor nfsd4_cleanup_inter_ssc() (2/2) NFSD: Refactor nfsd4_cleanup_inter_ssc() (1/2) ...
2022-08-09NTB: EPF: Tidy up some bounds checksDan Carpenter1-2/+9
This sscanf() is reading from the filename which was set by the kernel so it should be trust worthy. Although the data is likely trust worthy there is some bounds checking but unfortunately, it is not complete or consistent. Additionally, the Smatch static checker marks everything that comes from sscanf() as tainted and so Smatch complains that this code can lead to an out of bounds issue. Let's clean things up and make Smatch happy. The first problem is that there is no bounds checking in the _show() functions. The _store() and _show() functions are very similar so make the bounds checking the same in both. The second issue is that if "win_no" is zero it leads to an array underflow so add an if (win_no <= 0) check for that. Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Souptick Joarder (HPE) <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09NTB: EPF: Fix error code in epf_ntb_bind()Dan Carpenter1-1/+2
Return an error code if pci_register_driver() fails. Don't return success. Fixes: da51fd247424 ("NTB: EPF: support NTB transfer between PCI RC and EP connection") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Souptick Joarder (HPE) <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09PCI: endpoint: pci-epf-vntb: reduce several globals to staticsTom Rix1-3/+3
sparse reports drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: symbol 'pci_read' was not declared. Should it be static? drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: symbol 'pci_write' was not declared. Should it be static? drivers/pci/endpoint/functions/pci-epf-vntb.c:989:16: warning: symbol 'vpci_ops' was not declared. Should it be static? These functions and variables are only used in pci-epf-vntb.c, so their storage class specifiers should be static. Fixes: ff32fac00d97 ("NTB: EPF: support NTB transfer between PCI RC and EP connection") Signed-off-by: Tom Rix <[email protected]> Acked-by: Frank Li <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09PCI: endpoint: pci-epf-vntb: fix error handle in epf_ntb_mw_bar_init()Yang Yingliang1-5/+15
In error case of epf_ntb_mw_bar_init(), memory window BARs should be cleared, so add 'num_mws' parameter in epf_ntb_mw_bar_clear() and calling it in error path to clear the BARs. Also add missing error code when pci_epc_mem_alloc_addr() fails. Fixes: ff32fac00d97 ("NTB: EPF: support NTB transfer between PCI RC and EP connection") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09PCI: endpoint: Fix Kconfig dependencyRen Zhijie1-0/+1
If CONFIG_NTB is not set and CONFIG_PCI_EPF_VNTB is y. make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu-, will be failed, like this: drivers/pci/endpoint/functions/pci-epf-vntb.o: In function `epf_ntb_cmd_handler': pci-epf-vntb.c:(.text+0x95e): undefined reference to `ntb_db_event' pci-epf-vntb.c:(.text+0xa1f): undefined reference to `ntb_link_event' pci-epf-vntb.c:(.text+0xa42): undefined reference to `ntb_link_event' drivers/pci/endpoint/functions/pci-epf-vntb.o: In function `pci_vntb_probe': pci-epf-vntb.c:(.text+0x1250): undefined reference to `ntb_register_device' The functions ntb_*() are defined in drivers/ntb/core.c, which need CONFIG_NTB setting y to be build-in. To fix this build error, add depends on NTB. Reported-by: Hulk Robot <[email protected]> Fixes: ff32fac00d97("NTB: EPF: support NTB transfer between PCI RC and EP connection") Signed-off-by: Ren Zhijie <[email protected]> Acked-by: Frank Li <[email protected]> Acked-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]> # build-tested Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09NTB: EPF: set pointer addr to null using NULL rather than 0Colin Ian King1-1/+1
The pointer addr is being set to null using 0. Use NULL instead. Cleans up sparse warning: warning: Using plain integer as NULL pointer Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09Documentation: PCI: extend subheading underline for "lspci output" sectionBagas Sanjaya1-1/+1
The underline syntax for "lspci output..." section is off-by-one less than the section heading's length, hence triggers the warning: Documentation/PCI/endpoint/pci-vntb-howto.rst:131: WARNING: Title underline too short. Extend the underline by one to match the heading length. Link: https://lore.kernel.org/linux-next/[email protected]/ Fixes: 0c4b285d9636cc ("Documentation: PCI: Add specification for the PCI vNTB function device") Reported-by: Stephen Rothwell <[email protected]> Cc: Kishon Vijay Abraham I <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: "Krzysztof Wilczyński" <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Frank Li <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Bagas Sanjaya <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09Documentation: PCI: Use code-block block for scratchpad registers diagramBagas Sanjaya1-1/+4
The diagram in "Scratchpad Registers" isn't formatted inside code block, hence triggers indentation warning: Documentation/PCI/endpoint/pci-vntb-function.rst:82: WARNING: Unexpected indentation. Fix the warning by using code-block directive to format the diagram inside code block, as in other diagrams in Documentation/. While at it, unindent the preceeding text. Link: https://lore.kernel.org/linux-next/[email protected]/ Fixes: 0c4b285d9636cc ("Documentation: PCI: Add specification for the PCI vNTB function device") Reported-by: Stephen Rothwell <[email protected]> Cc: Kishon Vijay Abraham I <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: "Krzysztof Wilczyński" <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Frank Li <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Bagas Sanjaya <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09Documentation: PCI: Add specification for the PCI vNTB function deviceFrank Li3-0/+295
Add specification for the PCI vNTB function device. The endpoint function driver and the host PCI driver should be created based on this specification. Signed-off-by: Frank Li <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09PCI: endpoint: Support NTB transfer between RC and EPFrank Li3-0/+1436
Add NTB function driver and virtual PCI Bus and Virtual NTB driver to implement communication between PCIe Root Port and PCIe EP devices ┌────────────┐ ┌─────────────────────────────────────┐ │ │ │ │ ├────────────┤ │ ┌──────────────┤ │ NTB │ │ │ NTB │ │ NetDev │ │ │ NetDev │ ├────────────┤ │ ├──────────────┤ │ NTB │ │ │ NTB │ │ Transfer │ │ │ Transfer │ ├────────────┤ │ ├──────────────┤ │ │ │ │ │ │ PCI NTB │ │ │ │ │ EPF │ │ │ │ │ Driver │ │ │ PCI Virtual │ │ │ ├───────────────┐ │ NTB Driver │ │ │ │ PCI EP NTB │◄────►│ │ │ │ │ FN Driver │ │ │ ├────────────┤ ├───────────────┤ ├──────────────┤ │ │ │ │ │ │ │ PCI Bus │ ◄─────► │ PCI EP Bus │ │ Virtual PCI │ │ │ PCI │ │ │ Bus │ └────────────┘ └───────────────┴──────┴──────────────┘ PCIe Root Port PCI EP This driver includes 3 parts: 1 PCI EP NTB function driver 2 Virtual PCI bus 3 PCI virtual NTB driver, which is loaded only by above virtual PCI bus Signed-off-by: Frank Li <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09NTB: epf: Allow more flexibility in the memory BAR map methodFrank Li1-13/+35
Support the below BAR configuration methods for epf NTB. BAR 0: config and scratchpad BAR 2: doorbell BAR 4: memory map windows Set difference BAR number information into struct ntb_epf_data. So difference VID/PID can choose different BAR configurations. There are difference BAR map method between epf NTB and epf vNTB Endpoint function. Signed-off-by: Frank Li <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09PCI: designware-ep: Allow pci_epc_set_bar() update inbound map addressFrank Li1-1/+9
ntb_mw_set_trans() will set memory map window after endpoint function driver bind. The inbound map address need be updated dynamically when using NTB by PCIe Root Port and PCIe Endpoint connection. Checking if iatu already assigned to the BAR, if yes, using assigned iatu number to update inbound address map and skip set BAR's register. Signed-off-by: Frank Li <[email protected]> Signed-off-by: Jon Mason <[email protected]>
2022-08-09dt-bindings: soc: qcom: smd-rpm: extend exampleKrzysztof Kozlowski1-6/+27
Replace existing limited example with proper code for Qualcomm Resource Power Manager (RPM) over SMD based on MSM8916. This also fixes the example's indentation. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-08-09dt-bindings: soc: qcom: smd: reference SMD edge schemaKrzysztof Kozlowski1-1/+1
The child node of smd is an SMD edge representing remote subsystem. Bring back missing reference from previously sent patch (disappeared when applying). Link: https://lore.kernel.org/r/[email protected] Fixes: 385fad1303af ("dt-bindings: remoteproc: qcom,smd-edge: define re-usable schema for smd-edge") Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-08-09dt-bindings: mmc: sdhci-msm: Fix 'operating-points-v2 was unexpected' issueBhupesh Sharma1-0/+2
As Rob reported in [1], there is one more issue present in the 'sdhci-msm' dt-binding which shows up when a fix for 'unevaluatedProperties' handling is applied: Documentation/devicetree/bindings/mmc/sdhci-msm.example.dtb: mmc@8804000: Unevaluated properties are not allowed ('operating-points-v2' was unexpected) Fix the same. [1]. https://lore.kernel.org/lkml/[email protected]/ Cc: Bjorn Andersson <[email protected]> Cc: Rob Herring <[email protected]> Cc: Ulf Hansson <[email protected]> Signed-off-by: Bhupesh Sharma <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-08-09dt-bindings: display: simple-framebuffer: Drop Bartlomiej ZolnierkiewiczKrzysztof Kozlowski1-1/+0
Bartlomiej's Samsung email address is not working since around last year and there was no follow up patch take over of the drivers, so drop the email from maintainers. Cc: Bartlomiej Zolnierkiewicz <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-08-09can: mcp251x: Fix race condition on receive interruptSebastian Würl1-3/+15
The mcp251x driver uses both receiving mailboxes of the CAN controller chips. For retrieving the CAN frames from the controller via SPI, it checks once per interrupt which mailboxes have been filled and will retrieve the messages accordingly. This introduces a race condition, as another CAN frame can enter mailbox 1 while mailbox 0 is emptied. If now another CAN frame enters mailbox 0 until the interrupt handler is called next, mailbox 0 is emptied before mailbox 1, leading to out-of-order CAN frames in the network device. This is fixed by checking the interrupt flags once again after freeing mailbox 0, to correctly also empty mailbox 1 before leaving the handler. For reproducing the bug I created the following setup: - Two CAN devices, one Raspberry Pi with MCP2515, the other can be any. - Setup CAN to 1 MHz - Spam bursts of 5 CAN-messages with increasing CAN-ids - Continue sending the bursts while sleeping a second between the bursts - Check on the RPi whether the received messages have increasing CAN-ids - Without this patch, every burst of messages will contain a flipped pair v3: https://lore.kernel.org/all/[email protected] v2: https://lore.kernel.org/all/[email protected] v1: https://lore.kernel.org/all/[email protected] Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: Sebastian Würl <[email protected]> Link: https://lore.kernel.org/all/[email protected] [mkl: reduce scope of intf1, eflag1] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-08-09plip: avoid rcu debug splatFlorian Westphal1-1/+1
WARNING: suspicious RCU usage 5.2.0-rc2-00605-g2638eb8b50cfc #1 Not tainted drivers/net/plip/plip.c:1110 suspicious rcu_dereference_check() usage! plip_open is called with RTNL held, switch to the correct helper. Fixes: 2638eb8b50cf ("net: ipv4: provide __rcu annotation for ifa_list") Reported-by: kernel test robot <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09net: bgmac: Fix a BUG triggered by wrong bytes_complSandor Bodo-Merle1-1/+1
On one of our machines we got: kernel BUG at lib/dynamic_queue_limits.c:27! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G W O 4.14.275-rt132 #1 Hardware name: BRCM XGS iProc task: ee3415c0 task.stack: ee32a000 PC is at dql_completed+0x168/0x178 LR is at bgmac_poll+0x18c/0x6d8 pc : [<c03b9430>] lr : [<c04b5a18>] psr: 800a0313 sp : ee32be14 ip : 000005ea fp : 00000bd4 r10: ee558500 r9 : c0116298 r8 : 00000002 r7 : 00000000 r6 : ef128810 r5 : 01993267 r4 : 01993851 r3 : ee558000 r2 : 000070e1 r1 : 00000bd4 r0 : ee52c180 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 12c5387d Table: 8e88c04a DAC: 00000051 Process irq/41-bgmac (pid: 1166, stack limit = 0xee32a210) Stack: (0xee32be14 to 0xee32c000) be00: ee558520 ee52c100 ef128810 be20: 00000000 00000002 c0116298 c04b5a18 00000000 c0a0c8c4 c0951780 00000040 be40: c0701780 ee558500 ee55d520 ef05b340 ef6f9780 ee558520 00000001 00000040 be60: ffffe000 c0a56878 ef6fa040 c0952040 0000012c c0528744 ef6f97b0 fffcfb6a be80: c0a04104 2eda8000 c0a0c4ec c0a0d368 ee32bf44 c0153534 ee32be98 ee32be98 bea0: ee32bea0 ee32bea0 ee32bea8 ee32bea8 00000000 c01462e4 ffffe000 ef6f22a8 bec0: ffffe000 00000008 ee32bee4 c0147430 ffffe000 c094a2a8 00000003 ffffe000 bee0: c0a54528 00208040 0000000c c0a0c8c4 c0a65980 c0124d3c 00000008 ee558520 bf00: c094a23c c0a02080 00000000 c07a9910 ef136970 ef136970 ee30a440 ef136900 bf20: ee30a440 00000001 ef136900 ee30a440 c016d990 00000000 c0108db0 c012500c bf40: ef136900 c016da14 ee30a464 ffffe000 00000001 c016dd14 00000000 c016db28 bf60: ffffe000 ee21a080 ee30a400 00000000 ee32a000 ee30a440 c016dbfc ee25fd70 bf80: ee21a09c c013edcc ee32a000 ee30a400 c013ec7c 00000000 00000000 00000000 bfa0: 00000000 00000000 00000000 c0108470 00000000 00000000 00000000 00000000 bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<c03b9430>] (dql_completed) from [<c04b5a18>] (bgmac_poll+0x18c/0x6d8) [<c04b5a18>] (bgmac_poll) from [<c0528744>] (net_rx_action+0x1c4/0x494) [<c0528744>] (net_rx_action) from [<c0124d3c>] (do_current_softirqs+0x1ec/0x43c) [<c0124d3c>] (do_current_softirqs) from [<c012500c>] (__local_bh_enable+0x80/0x98) [<c012500c>] (__local_bh_enable) from [<c016da14>] (irq_forced_thread_fn+0x84/0x98) [<c016da14>] (irq_forced_thread_fn) from [<c016dd14>] (irq_thread+0x118/0x1c0) [<c016dd14>] (irq_thread) from [<c013edcc>] (kthread+0x150/0x158) [<c013edcc>] (kthread) from [<c0108470>] (ret_from_fork+0x14/0x24) Code: a83f15e0 0200001a 0630a0e1 c3ffffea (f201f0e7) The issue seems similar to commit 90b3b339364c ("net: hisilicon: Fix a BUG trigered by wrong bytes_compl") and potentially introduced by commit b38c83dd0866 ("bgmac: simplify tx ring index handling"). If there is an RX interrupt between setting ring->end and netdev_sent_queue() we can hit the BUG_ON as bgmac_dma_tx_free() can miscalculate the queue size while called from bgmac_poll(). The machine which triggered the BUG runs a v4.14 RT kernel - but the issue seems present in mainline too. Fixes: b38c83dd0866 ("bgmac: simplify tx ring index handling") Signed-off-by: Sandor Bodo-Merle <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-08-09net: dsa: felix: suppress non-changes to the tagging protocolVladimir Oltean1-0/+3
The way in which dsa_tree_change_tag_proto() works is that when dsa_tree_notify() fails, it doesn't know whether the operation failed mid way in a multi-switch tree, or it failed for a single-switch tree. So even though drivers need to fail cleanly in ds->ops->change_tag_protocol(), DSA will still call dsa_tree_notify() again, to restore the old tag protocol for potential switches in the tree where the change did succeeed (before failing for others). This means for the felix driver that if we report an error in felix_change_tag_protocol(), we'll get another call where proto_ops == old_proto_ops. If we proceed to act upon that, we may do unexpected things. For example, we will call dsa_tag_8021q_register() twice in a row, without any dsa_tag_8021q_unregister() in between. Then we will actually call dsa_tag_8021q_unregister() via old_proto_ops->teardown, which (if it manages to run at all, after walking through corrupted data structures) will leave the ports inoperational anyway. The bug can be readily reproduced if we force an error while in tag_8021q mode; this crashes the kernel. echo ocelot-8021q > /sys/class/net/eno2/dsa/tagging echo edsa > /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014 Call trace: vcap_entry_get+0x24/0x124 ocelot_vcap_filter_del+0x198/0x270 felix_tag_8021q_vlan_del+0xd4/0x21c dsa_switch_tag_8021q_vlan_del+0x168/0x2cc dsa_switch_event+0x68/0x1170 dsa_tree_notify+0x14/0x34 dsa_port_tag_8021q_vlan_del+0x84/0x110 dsa_tag_8021q_unregister+0x15c/0x1c0 felix_tag_8021q_teardown+0x16c/0x180 felix_change_tag_protocol+0x1bc/0x230 dsa_switch_event+0x14c/0x1170 dsa_tree_change_tag_proto+0x118/0x1c0 Fixes: 7a29d220f4c0 ("net: dsa: felix: reimplement tagging protocol change with function pointers") Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.