summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-12-23selftests: mlxsw: Add VxLAN FDB veto test for IPv6Amit Cohen
Add test to verify FDB vetos of VxLAN with IPv6 underlay. Use the existing test which checks IPv4. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-23selftests: mlxsw: vxlan_fdb_veto: Make the test more flexible for future useAmit Cohen
vxlan_fdb_veto.sh cases are dedicated to test VxLAN with IPv4 underlay. The main changes to test IPv6 underlay are IP addresses and some flags. Add variables to define all the values which supposed to be different for IPv6 testing, set them to use the existing values by default. The next patch will define the new added variables in a separated file, so the same tests can be used for IPv6 also. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-23selftests: mlxsw: Add VxLAN configuration test for IPv6Amit Cohen
Add test to verify configuration of VxLAN with IPv6 underlay. Use the existing test which checks IPv4. Add separated test cases for learning which is not supported for IPv6 and for UDP checksum flags which are different from IPv4 flags. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-23selftests: mlxsw: vxlan: Make the test more flexible for future useAmit Cohen
vxlan.sh cases are dedicated to test VxLAN with IPv4 underlay. The main changes to test IPv6 underlay are IP addresses and some flags. Add variables to define all the values which supposed to be different for IPv6 testing, set them to use the existing values by default. The next patch will define the new added variables in a separated file, so the same tests can be used for IPv6 also. Rename some functions to include "ipv4", so the next patch will add equivalent functions for IPv6. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-23wwan: Replace kernel.h with the necessary inclusionsAndy Shevchenko
When kernel.h is used in the headers it adds a lot into dependency hell, especially when there are circular dependencies are involved. Replace kernel.h inclusion with the list of what is really being used. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-23net: stmmac: add tc flower filter for EtherType matchingOng Boon Leong
This patch adds basic support for EtherType RX frame steering for LLDP and PTP using the hardware offload capabilities. Example steps for setting up RX frame steering for LLDP and PTP: $ IFDEVNAME=eth0 $ tc qdisc add dev $IFDEVNAME ingress $ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 For LLDP $ tc filter add dev $IFDEVNAME parent ffff: protocol 0x88cc \ flower hw_tc 5 OR $ tc filter add dev $IFDEVNAME parent ffff: protocol LLDP \ flower hw_tc 5 For PTP $ tc filter add dev $IFDEVNAME parent ffff: protocol 0x88f7 \ flower hw_tc 6 Show tc ingress filter $ tc filter show dev $IFDEVNAME ingress v1->v2: Thanks to Kurt's and Sebastian's suggestion. - change from __be16 to u16 etype - change ETHER_TYPE_FULL_MASK to use cpu_to_be16() macro Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-23net: lan966x: Add support for multiple bridge flagsHoratiu Vultur
This patch series extends the current supported bridge flags with the following flags: BR_FLOOD, BR_BCAST_FLOOD and BR_LEARNING. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-23flow_offload: fix suspicious RCU usage when offloading tc actionBaowen Zheng
Fix suspicious rcu_dereference_protected() usage when offloading tc action. We should hold tcfa_lock to offload tc action in action initiation. Without these changes, the following warning will be observed: WARNING: suspicious RCU usage 5.16.0-rc5-net-next-01504-g7d1f236dcffa-dirty #50 Tainted: G I ----------------------------- include/net/tc_act/tc_tunnel_key.h:33 suspicious rcu_dereference_protected() usage! 1 lock held by tc/12108: CPU: 4 PID: 12108 Comm: tc Tainted: G Hardware name: Dell Inc. PowerEdge R740/07WCGN, BIOS 1.6.11 11/20/2018 Call Trace: <TASK> dump_stack_lvl+0x49/0x5e dump_stack+0x10/0x12 lockdep_rcu_suspicious+0xed/0xf8 tcf_tunnel_key_offload_act_setup+0x1de/0x300 [act_tunnel_key] tcf_action_offload_add_ex+0xc0/0x1f0 tcf_action_init+0x26a/0x2f0 tcf_action_add+0xa9/0x1f0 tc_ctl_action+0xfb/0x170 rtnetlink_rcv_msg+0x169/0x510 ? sched_clock+0x9/0x10 ? rtnl_newlink+0x70/0x70 netlink_rcv_skb+0x55/0x100 rtnetlink_rcv+0x15/0x20 netlink_unicast+0x1a8/0x270 netlink_sendmsg+0x245/0x490 sock_sendmsg+0x65/0x70 ____sys_sendmsg+0x219/0x260 ? __import_iovec+0x2c/0x150 ___sys_sendmsg+0xb7/0x100 ? __lock_acquire+0x3d5/0x1f40 ? __this_cpu_preempt_check+0x13/0x20 ? lock_is_held_type+0xe4/0x140 ? sched_clock+0x9/0x10 ? ktime_get_coarse_real_ts64+0xbe/0xd0 ? __this_cpu_preempt_check+0x13/0x20 ? lockdep_hardirqs_on+0x7e/0x100 ? ktime_get_coarse_real_ts64+0xbe/0xd0 ? trace_hardirqs_on+0x2a/0xf0 __sys_sendmsg+0x5a/0xa0 ? syscall_trace_enter.constprop.0+0x1dd/0x220 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f4db7bb7a60 Fixes: 8cbfe939abe9 ("flow_offload: allow user to offload tc action to net device") Reported-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Baowen Zheng <baowen.zheng@corigine.com> Signed-off-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-23sctp: move hlist_node and hashent out of sctp_ep_commonXin Long
Struct sctp_ep_common is included in both asoc and ep, but hlist_node and hashent are only needed by ep after asoc_hashtable was dropped by Commit b5eff7128366 ("sctp: drop the old assoc hashtable of sctp"). So it is better to move hlist_node and hashent from sctp_ep_common to sctp_endpoint, and it saves some space for each asoc. Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-23x86/boot/compressed: Move CLANG_FLAGS to beginning of KBUILD_CFLAGSNathan Chancellor
When cross compiling i386_defconfig on an arm64 host with clang, there are a few instances of '-Waddress-of-packed-member' and '-Wgnu-variable-sized-type-not-at-end' in arch/x86/boot/compressed/, which should both be disabled with the cc-disable-warning calls in that directory's Makefile, which indicates that cc-disable-warning is failing at the point of testing these flags. The cc-disable-warning calls fail because at the point that the flags are tested, KBUILD_CFLAGS has '-march=i386' without $(CLANG_FLAGS), which has the '--target=' flag to tell clang what architecture it is targeting. Without the '--target=' flag, the host architecture (arm64) is used and i386 is not a valid value for '-march=' in that case. This error can be seen by adding some logging to try-run: clang-14: error: the clang compiler does not support '-march=i386' Invoking the compiler has to succeed prior to calling cc-option or cc-disable-warning in order to accurately test whether or not the flag is supported; if it doesn't, the requested flag can never be added to the compiler flags. Move $(CLANG_FLAGS) to the beginning of KBUILD_FLAGS so that any new flags that might be added in the future can be accurately tested. Fixes: d5cbd80e302d ("x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20211222163040.1961481-1-nathan@kernel.org
2021-12-23xfrm: rate limit SA mapping change message to user spaceAntony Antony
Kernel generates mapping change message, XFRM_MSG_MAPPING, when a source port chage is detected on a input state with UDP encapsulation set. Kernel generates a message for each IPsec packet with new source port. For a high speed flow per packet mapping change message can be excessive, and can overload the user space listener. Introduce rate limiting for XFRM_MSG_MAPPING message to the user space. The rate limiting is configurable via netlink, when adding a new SA or updating it. Use the new attribute XFRMA_MTIMER_THRESH in seconds. v1->v2 change: update xfrm_sa_len() v2->v3 changes: use u32 insted unsigned long to reduce size of struct xfrm_state fix xfrm_ompat size Reported-by: kernel test robot <lkp@intel.com> accept XFRM_MSG_MAPPING only when XFRMA_ENCAP is present Co-developed-by: Thomas Egerer <thomas.egerer@secunet.com> Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com> Signed-off-by: Antony Antony <antony.antony@secunet.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2021-12-23xfrm: Add support for SM4 symmetric cipher algorithmXu Jia
This patch adds SM4 encryption algorithm entry to ealg_list. Signed-off-by: Xu Jia <xujia39@huawei.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2021-12-23xfrm: Add support for SM3 secure hashXu Jia
This patch allows IPsec to use SM3 HMAC authentication algorithm. Signed-off-by: Xu Jia <xujia39@huawei.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2021-12-23xfrm: update SA curlft.use_timeAntony Antony
SA use_time was only updated once, for the first packet. with this fix update the use_time for every packet. Signed-off-by: Antony Antony <antony.antony@secunet.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2021-12-22net/mlx5: Fix some error handling paths in 'mlx5e_tc_add_fdb_flow()'Christophe JAILLET
All the error handling paths of 'mlx5e_tc_add_fdb_flow()' end to 'err_out' where 'flow_flag_set(flow, FAILED);' is called. All but the new error handling paths added by the commits given in the Fixes tag below. Fix these error handling paths and branch to 'err_out'. Fixes: 166f431ec6be ("net/mlx5e: Add indirect tc offload of ovs internal port") Fixes: b16eb3c81fe2 ("net/mlx5: Support internal port as decap route device") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> (cherry picked from commit 31108d142f3632970f6f3e0224bd1c6781c9f87d)
2021-12-22net/mlx5e: Delete forward rule for ct or sample actionChris Mi
When there is ct or sample action, the ct or sample rule will be deleted and return. But if there is an extra mirror action, the forward rule can't be deleted because of the return. Fix it by removing the return. Fixes: 69e2916ebce4 ("net/mlx5: CT: Add support for mirroring") Fixes: f94d6389f6a8 ("net/mlx5e: TC, Add support to offload sample action") Signed-off-by: Chris Mi <cmi@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5e: Fix ICOSQ recovery flow for XSKMaxim Mikityanskiy
There are two ICOSQs per channel: one is needed for RX, and the other for async operations (XSK TX, kTLS offload). Currently, the recovery flow for both is the same, and async ICOSQ is mistakenly treated like the regular ICOSQ. This patch prevents running the regular ICOSQ recovery on async ICOSQ. The purpose of async ICOSQ is to handle XSK wakeup requests and post kTLS offload RX parameters, it has nothing to do with RQ and XSKRQ UMRs, so the regular recovery sequence is not applicable here. Fixes: be5323c8379f ("net/mlx5e: Report and recover from CQE error on ICOSQ") Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5e: Fix interoperability between XSK and ICOSQ recovery flowMaxim Mikityanskiy
Both regular RQ and XSKRQ use the same ICOSQ for UMRs. When doing recovery for the ICOSQ, don't forget to deactivate XSKRQ. XSK can be opened and closed while channels are active, so a new mutex prevents the ICOSQ recovery from running at the same time. The ICOSQ recovery deactivates and reactivates XSKRQ, so any parallel change in XSK state would break consistency. As the regular RQ is running, it's not enough to just flush the recovery work, because it can be rescheduled. Fixes: be5323c8379f ("net/mlx5e: Report and recover from CQE error on ICOSQ") Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5e: Fix skb memory leak when TC classifier action offloads are disabledGal Pressman
When TC classifier action offloads are disabled (CONFIG_MLX5_CLS_ACT in Kconfig), the mlx5e_rep_tc_receive() function which is responsible for passing the skb to the stack (or freeing it) is defined as a nop, and results in leaking the skb memory. Replace the nop with a call to napi_gro_receive() to resolve the leak. Fixes: 28e7606fa8f1 ("net/mlx5e: Refactor rx handler of represetor device") Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Ariel Levkovich <lariel@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5e: Wrap the tx reporter dump callback to extract the sqAmir Tzin
Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually of type struct mlx5e_tx_timeout_ctx *. mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected mlx5_core 0000:08:00.1 enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last trans: 21565000 BUG: stack guard page was hit at 0000000093f1a2de (stack is 00000000b66ea0dc..000000004d932dae) kernel stack overflow (page fault): 0000 [#1] SMP NOPTI CPU: 5 PID: 95 Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e mlx5e_tx_timeout_work [mlx5_core] RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 [mlx5_core] Call Trace: mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core] devlink_health_do_dump.part.91+0x71/0xd0 devlink_health_report+0x157/0x1b0 mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core] ? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0 [mlx5_core] ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core] ? update_load_avg+0x19b/0x550 ? set_next_entity+0x72/0x80 ? pick_next_task_fair+0x227/0x340 ? finish_task_switch+0xa2/0x280 mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core] process_one_work+0x1de/0x3a0 worker_thread+0x2d/0x3c0 ? process_one_work+0x3a0/0x3a0 kthread+0x115/0x130 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 --[ end trace 51ccabea504edaff ]--- RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled end Kernel panic - not syncing: Fatal exception To fix this bug add a wrapper for mlx5e_tx_reporter_dump_sq() which extracts the sq from struct mlx5e_tx_timeout_ctx and set it as the TX-timeout-recovery flow dump callback. Fixes: 5f29458b77d5 ("net/mlx5e: Support dump callback in TX reporter") Signed-off-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Amir Tzin <amirtz@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5: Fix tc max supported prio for nic modeChris Mi
Only prio 1 is supported if firmware doesn't support ignore flow level for nic mode. The offending commit removed the check wrongly. Add it back. Fixes: 9a99c8f1253a ("net/mlx5e: E-Switch, Offload all chain 0 priorities when modify header and forward action is not supported") Signed-off-by: Chris Mi <cmi@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5: Fix SF health recovery flowMoshe Shemesh
SF do not directly control the PCI device. During recovery flow SF should not be allowed to do pci disable or pci reset, its PF will do it. It fixes the following kernel trace: mlx5_core.sf mlx5_core.sf.25: mlx5_health_try_recover:387:(pid 40948): starting health recovery flow mlx5_core 0000:03:00.0: mlx5_pci_slot_reset was called mlx5_core 0000:03:00.0: wait vital counter value 0xab175 after 1 iterations mlx5_core.sf mlx5_core.sf.25: firmware version: 24.32.532 mlx5_core.sf mlx5_core.sf.23: mlx5_health_try_recover:387:(pid 40946): starting health recovery flow mlx5_core 0000:03:00.0: mlx5_pci_slot_reset was called mlx5_core 0000:03:00.0: wait vital counter value 0xab193 after 1 iterations mlx5_core.sf mlx5_core.sf.23: firmware version: 24.32.532 mlx5_core.sf mlx5_core.sf.25: mlx5_cmd_check:813:(pid 40948): ENABLE_HCA(0x104) op_mod(0x0) failed, status bad resource state(0x9), syndrome (0x658908) mlx5_core.sf mlx5_core.sf.25: mlx5_function_setup:1292:(pid 40948): enable hca failed mlx5_core.sf mlx5_core.sf.25: mlx5_health_try_recover:389:(pid 40948): health recovery failed Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver") Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5: Fix error print in case of IRQ request failedShay Drory
In case IRQ layer failed to find or to request irq, the driver is printing the first cpu of the provided affinity as part of the error print. Empty affinity is a valid input for the IRQ layer, and it is an error to call cpumask_first() on empty affinity. Remove the first cpu print from the error message. Fixes: c36326d38d93 ("net/mlx5: Round-Robin EQs over IRQs") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5: Use first online CPU instead of hard coded CPUShay Drory
Hard coded CPU (0 in our case) might be offline. Hence, use the first online CPU instead. Fixes: f891b7cdbdcd ("net/mlx5: Enable single IRQ for PCI Function") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5: DR, Fix querying eswitch manager vport for ECPFYevgeny Kliteynik
On BlueField the E-Switch manager is the ECPF (vport 0xFFFE), but when querying capabilities of ECPF eswitch manager, need to query vport 0 with other_vport = 0. Fixes: 9091b821aaa4 ("net/mlx5: DR, Handle eswitch manager and uplink vports separately") Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22net/mlx5: DR, Fix NULL vs IS_ERR checking in dr_domain_init_resourcesMiaoqian Lin
The mlx5_get_uars_page() function returns error pointers. Using IS_ERR() to check the return value to fix this. Fixes: 4ec9e7b02697 ("net/mlx5: DR, Expose steering domain functionality") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-12-22scsi: vmw_pvscsi: Set residual data length conditionallyAlexey Makhalov
The PVSCSI implementation in the VMware hypervisor under specific configuration ("SCSI Bus Sharing" set to "Physical") returns zero dataLen in the completion descriptor for READ CAPACITY(16). As a result, the kernel can not detect proper disk geometry. This can be recognized by the kernel message: [ 0.776588] sd 1:0:0:0: [sdb] Sector size 0 reported, assuming 512. The PVSCSI implementation in QEMU does not set dataLen at all, keeping it zeroed. This leads to a boot hang as was reported by Shmulik Ladkani. It is likely that the controller returns the garbage at the end of the buffer. Residual length should be set by the driver in that case. The SCSI layer will erase corresponding data. See commit bdb2b8cab439 ("[SCSI] erase invalid data returned by device") for details. Commit e662502b3a78 ("scsi: vmw_pvscsi: Set correct residual data length") introduced the issue by setting residual length unconditionally, causing the SCSI layer to erase the useful payload beyond dataLen when this value is returned as 0. As a result, considering existing issues in implementations of PVSCSI controllers, we do not want to call scsi_set_resid() when dataLen == 0. Calling scsi_set_resid() has no effect if dataLen equals buffer length. Link: https://lore.kernel.org/lkml/20210824120028.30d9c071@blondie/ Link: https://lore.kernel.org/r/20211220190514.55935-1-amakhalov@vmware.com Fixes: e662502b3a78 ("scsi: vmw_pvscsi: Set correct residual data length") Cc: Matt Wang <wwentao@vmware.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Vishal Bhakta <vbhakta@vmware.com> Cc: VMware PV-Drivers <pv-drivers@vmware.com> Cc: James E.J. Bottomley <jejb@linux.ibm.com> Cc: linux-scsi@vger.kernel.org Cc: stable@vger.kernel.org Reported-and-suggested-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: Alexey Makhalov <amakhalov@vmware.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-12-22scsi: libiscsi: Fix UAF in iscsi_conn_get_param()/iscsi_conn_teardown()Lixiaokeng
|- iscsi_if_destroy_conn |-dev_attr_show |-iscsi_conn_teardown |-spin_lock_bh |-iscsi_sw_tcp_conn_get_param |-kfree(conn->persistent_address) |-iscsi_conn_get_param |-kfree(conn->local_ipaddr) ==>|-read persistent_address ==>|-read local_ipaddr |-spin_unlock_bh When iscsi_conn_teardown() and iscsi_conn_get_param() happen in parallel, a UAF may be triggered. Link: https://lore.kernel.org/r/046ec8a0-ce95-d3fc-3235-666a7c65b224@huawei.com Reported-by: Lu Tixiong <lutianxiong@huawei.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Reviewed-by: Lee Duncan <lduncan@suse.com> Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com> Signed-off-by: Linfeilong <linfeilong@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-12-22io_uring: zero iocb->ki_pos for stream file typesJens Axboe
io_uring supports using offset == -1 for using the current file position, and we read that in as part of read/write command setup. For the non-iter read/write types we pass in NULL for the position pointer, but for the iter types we should not be passing any anything but 0 for the position for a stream. Clear kiocb->ki_pos if the file is a stream, don't leave it as -1. If we do, then the request will error with -ESPIPE. Fixes: ba04291eb66e ("io_uring: allow use of offset == -1 to mean file position") Link: https://github.com/axboe/liburing/discussions/501 Reported-by: Samuel Williams <samuel.williams@oriontransfer.co.nz> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-12-22drm/amdgpu: fix runpm documentationAlex Deucher
It's not only supported by HG/PX laptops. It's supported by all dGPUs which supports BOCO/BACO functionality (runtime D3). BOCO - Bus Off, Chip Off. The entire chip is powered off. This is controlled by ACPI. BACO - Bus Active, Chip Off. The chip still shows up on the PCI bus, but the device itself is powered down. v2: fix missed HG/PX reference Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-12-23Merge tag 'exynos-drm-next-for-v5.17' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Four cleanups - Replacing lagacy gpio interface of dsi driver with gpiod one. - Implementing a generic GEM object mmap and use it instead of exynos specific one. - Dropping the use of label from dsi driver. Which also fixes a build warning. - Just trivial cleanup by dropping unnecessay code. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222035345.26595-1-inki.dae@samsung.com
2021-12-23Merge tag 'drm/tegra/for-5.17-rc1' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/tegra into drm-next drm/tegra: Changes for v5.17-rc1 This contains a fairly large rework that makes the buffer objects behave more according to what the DMA-BUF infrastructure expects. A buffer object cache is implemented on top of that to make certain operations such as page-flipping more efficient by avoiding needless map/unmap operations. This in turn is useful to implement asynchronous commits to support legacy cursor updates. Another fairly big addition is the NVDEC driver. This uses the updated UABI introduced in v5.15-rc1 to provide access to the video decode engines found on Tegra210 and later. This also includes some power management improvements that are useful on older devices in particular because they, together with a bunch of other changes across the kernel, allow the system to scale down frequency and voltages when mostly idle and prevent these devices from becoming excessively hot. The remainder of these changes is an assortment of cleanups and minor fixes. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217142912.558095-1-thierry.reding@gmail.com
2021-12-23Merge tag 'amd-drm-next-5.17-2021-12-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amdgpu: - Add some display debugfs entries - RAS fixes - SR-IOV fixes - W=1 fixes - Documentation fixes - IH timestamp fix - Misc power fixes - IP discovery fixes - Large driver documentation updates - Multi-GPU memory use reductions - Misc display fixes and cleanups - Add new SMU debug option amdkfd: - SVM fixes radeon: - Fix typo in comment From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211216202731.5900-1-alexander.deucher@amd.com
2021-12-23Merge tag 'drm-intel-fixes-2021-12-22' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v5.16-rc7: - Fix fallout from guc submission locking rework Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87wnjwydhs.fsf@intel.com
2021-12-22Merge branch 'add-tests-for-vxlan-with-ipv6-underlay'Jakub Kicinski
Amit Cohen says: ==================== Add tests for VxLAN with IPv6 underlay mlxsw driver lately added support for VxLAN with IPv6 underlay. This set adds the relevant tests for IPv6, most of them are same to IPv4 tests with the required changes. Patch set overview: Patch #1 relaxes requirements for offloading TC filters that match on 802.1q fields. The following selftests make use of these newly-relaxed filters. Patch #2 adds preparation as part of selftests API, which will be used later. Patches #3-#4 add tests for VxLAN with bridge aware and unaware. Patche #5 cleans unused function. Patches #6-#7 add tests for VxLAN symmetric and asymmetric. Patch #8 adds test for Q-in-VNI. ==================== Link: https://lore.kernel.org/r/20211221144949.2527545-1-amcohen@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22selftests: forwarding: Add Q-in-VNI test for IPv6Amit Cohen
Add test to check Q-in-VNI traffic with IPv6 underlay and overlay. The test is similar to the existing IPv4 test. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22selftests: forwarding: Add a test for VxLAN symmetric routing with IPv6Amit Cohen
In a similar fashion to the asymmetric test, add a test for symmetric routing. In symmetric routing both the ingress and egress VTEPs perform routing in the overlay network into / from the VxLAN tunnel. Packets in different directions use the same VNI - the L3 VNI. Different tenants (VRFs) use different L3 VNIs. Add a test which is similar to the existing IPv4 test to check IPv6. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22selftests: forwarding: Add a test for VxLAN asymmetric routing with IPv6Amit Cohen
In asymmetric routing the ingress VTEP routes the packet into the correct VxLAN tunnel, whereas the egress VTEP only bridges the packet to the correct host. Therefore, packets in different directions use different VNIs - the target VNI. Add a test which is similar to the existing IPv4 test to check IPv6. The test uses a simple topology with two VTEPs and two VNIs and verifies that ping passes between hosts (local / remote) in the same VLAN (VNI) and in different VLANs belonging to the same tenant (VRF). While the test does not check VM mobility, it does configure an anycast gateway using a macvlan device on both VTEPs. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22selftests: forwarding: vxlan_bridge_1q: Remove unused functionAmit Cohen
Remove `vxlan_ping_test()` which is not used and probably was copied mistakenly from vxlan_bridge_1d.sh. This was found while adding an equivalent test for IPv6. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22selftests: forwarding: Add VxLAN tests with a VLAN-aware bridge for IPv6Amit Cohen
The tests are very similar to their VLAN-unaware counterpart (vxlan_bridge_1d_ipv6.sh and vxlan_bridge_1d_port_8472_ipv6.sh), but instead of using multiple VLAN-unaware bridges, a single VLAN-aware bridge is used with multiple VLANs. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22selftests: forwarding: Add VxLAN tests with a VLAN-unaware bridge for IPv6Amit Cohen
Add tests similar to vxlan_bridge_1d.sh and vxlan_bridge_1d_port_8472.sh. The tests set up a topology with three VxLAN endpoints: one "local", possibly offloaded, and two "remote", formed using veth pairs and likely purely software bridges. The "local" endpoint is connected to host systems by a VLAN-unaware bridge. Since VxLAN tunnels must be unique per namespace, each of the "remote" endpoints is in its own namespace. H3 forms the bridge between the three domains. Send IPv4 packets and IPv6 packets with IPv6 underlay. Use `TC_FLAG`, which is defined in `forwarding.config` file, for TC checks. `TC_FLAG` allows testing that on HW datapath, the traffic actually goes through HW. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22selftests: lib.sh: Add PING_COUNT to allow sending configurable amount of ↵Amit Cohen
packets Currently `ping_do()` and `ping6_do()` send 10 packets. There are cases that it is not possible to catch only the interesting packets using tc rule, so then, it is possible to send many packets and verify that at least this amount of packets hit the rule. Add `PING_COUNT` variable, which is set to 10 by default, to allow tests sending more than 10 packets using the existing ping API. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22mlxsw: spectrum_flower: Make vlan_id limitation more specificAmit Cohen
Spectrum ASICs do not support matching of VLAN ID at egress. Currently, mlxsw driver forbids matching of all VLAN related fields at egress, which is too strict check. For example, the following filter is not supported by the driver: $ tc filter add dev swpX egress protocol 802.1q pref 1 handle 101 flower vlan_ethtype ipv4 src_ip .. dst_ip .. skip_sw action pass Error: mlxsw_spectrum: vlan_id key is not supported on egress. We have an error talking to the kernel The filter above does not match on VLAN ID, but is bounced anyway. Make the check more specific, forbid only matching of 'vlan_id' at egress. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22Merge tag 'mlx5-updates-2021-12-21' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-updates-2021-12-21 1) From Shay Drory: Devlink user knobs to control device's EQ size This series provides knobs which will enable users to minimize memory consumption of mlx5 Functions (PF/VF/SF). mlx5 exposes two new generic devlink params for EQ size configuration and uses devlink generic param max_macs. LINK: https://lore.kernel.org/netdev/20211208141722.13646-1-shayd@nvidia.com/ 2) From Tariq and Lama, allocate software channel objects and statistics of a mlx5 netdevice private data dynamically upon first demand to save on memory. * tag 'mlx5-updates-2021-12-21' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5e: Take packet_merge params directly from the RX res struct net/mlx5e: Allocate per-channel stats dynamically at first usage net/mlx5e: Use dynamic per-channel allocations in stats net/mlx5e: Allow profile-specific limitation on max num of channels net/mlx5e: Save memory by using dynamic allocation in netdev priv net/mlx5e: Add profile indications for PTP and QOS HTB features net/mlx5e: Use bitmap field for profile features net/mlx5: Remove the repeated declaration net/mlx5: Let user configure max_macs generic param devlink: Clarifies max_macs generic devlink param net/mlx5: Let user configure event_eq_size param devlink: Add new "event_eq_size" generic device param net/mlx5: Let user configure io_eq_size param devlink: Add new "io_eq_size" generic device param ==================== Link: https://lore.kernel.org/r/20211222031604.14540-1-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-23Merge tag 'mediatek-drm-fixes-5.16' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Mediatek DRM Fixes for Linux 5.16 1. Perform NULL pointer check for mtk_hdmi_conf. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/1639956861-14873-1-git-send-email-chunkuang.hu@kernel.org
2021-12-23netfilter: flowtable: remove ipv4/ipv6 modulesFlorian Westphal
Just place the structs and registration in the inet module. nf_flow_table_ipv6, nf_flow_table_ipv4 and nf_flow_table_inet share same module dependencies: nf_flow_table, nf_tables. before: text data bss dec hex filename 2278 1480 0 3758 eae nf_flow_table_inet.ko 1159 1352 0 2511 9cf nf_flow_table_ipv6.ko 1154 1352 0 2506 9ca nf_flow_table_ipv4.ko after: 2369 1672 0 4041 fc9 nf_flow_table_inet.ko Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2021-12-23netfilter: nat: force port remap to prevent shadowing well-known portsFlorian Westphal
If destination port is above 32k and source port below 16k assume this might cause 'port shadowing' where a 'new' inbound connection matches an existing one, e.g. inbound X:41234 -> Y:53 matches existing conntrack entry Z:53 -> X:4123, where Z got natted to X. In this case, new packet is natted to Z:53 which is likely unwanted. We avoid the rewrite for connections that originate from local host: port-shadowing is only possible with forwarded connections. Also adjust test case. v3: no need to call tuple_force_port_remap if already in random mode (Phil) Signed-off-by: Florian Westphal <fw@strlen.de> Acked-by: Phil Sutter <phil@nwl.cc> Acked-by: Eric Garver <eric@garver.life> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2021-12-23netfilter: conntrack: tag conntracks picked up in local out hookFlorian Westphal
This allows to identify flows that originate from local machine in a followup patch. It would be possible to make this a ->status bit instead. For now I did not do that yet because I don't have a use-case for exposing this info to userspace. If one comes up the toggle can be replaced with a status bit. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2021-12-23netfilter: nf_tables: make counter support built-inPablo Neira Ayuso
Make counter support built-in to allow for direct call in case of CONFIG_RETPOLINE. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2021-12-23netfilter: nf_tables: replace WARN_ON by WARN_ON_ONCE for unknown verdictsPablo Neira Ayuso
Bug might trigger warning for each packet, call WARN_ON_ONCE instead. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
generated by cgit (git 2.34.1) at 2025-09-19 09:51:02 +0000