#
a71f2147 |
|
13-Mar-2023 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Fix MACsec state loss upon state update in offload path The packet number attribute of the SA is incremented by the device rather than the software stack when enabling hardware offload. Because the packet number attribute is managed by the hardware, the software has no insight into the value of the packet number attribute actually written by the device. Previously when MACsec offload was enabled, the hardware object for handling the offload was destroyed when the SA was disabled. Re-enabling the SA would lead to a new hardware object being instantiated. This new hardware object would not have any recollection of the correct packet number for the SA. Instead, destroy the flow steering rule when deactivating the SA and recreate it upon reactivation, preserving the original hardware object. Fixes: 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
fde2f2d7 |
|
05-Oct-2023 |
Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> |
net/mlx5e: macsec: use update_pn flag instead of PN comparation When updating the SA, use the new update_pn flags instead of comparing the new PN with the initial one. Comparing the initial PN value with the new value will allow the user to update the SA using the initial PN value as a parameter like this: $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \ ead3664f508eb06c40ac7104cdae4ce5 $ ip macsec set macsec0 tx sa 0 pn 1 off Fixes: 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support") Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
#
758ce14a |
|
02-May-2022 |
Patrisious Haddad <phaddad@nvidia.com> |
RDMA/mlx5: Implement MACsec gid addition and deletion Handle MACsec IP ambiguity issue, since mlx5 hw can't support programming both the MACsec and the physical gid when they have the same IP address, because it wouldn't know to whom to steer the traffic. Hence in such case we delete the physical gid from the hw gid table, which would then cause all traffic sent over it to fail, and we'll only be able to send traffic over the MACsec gid. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Mark Zhang <markzhang@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
#
d4ece08f |
|
08-Jan-2023 |
Patrisious Haddad <phaddad@nvidia.com> |
net/mlx5: Maintain fs_id xarray per MACsec device inside macsec steering Remove fs_id from the MACsec SA, since it has no real usage there and instead maintain with the MACsec steering data inside the core. Downstream patches requires this change to facilitate IB driver accesses to the fs_ids to avoid RoCE MACsec dependency on EN driver. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
#
7e2304f5 |
|
05-Jan-2023 |
Patrisious Haddad <phaddad@nvidia.com> |
net/mlx5: Remove netdevice from MACsec steering Since MACsec steering was moved from ethernet private code to core, remove the netdevice from the MACsec steering, and use core device methods for error reporting instead. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
#
2e92f669 |
|
06-Dec-2022 |
Patrisious Haddad <phaddad@nvidia.com> |
net/mlx5e: Move MACsec flow steering and statistics database from ethernet to core Since now MACsec flow steering (macsec_fs) and MACsec statistics (stats) are maintained by the core driver, move their data as well to be saved inside core structures instead of staying part of ethernet MACsec database. In addition cleanup all MACsec stats functions from the ethernet MACsec code and move what's needed to be part of macsec_fs instead. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
#
8603efbd |
|
29-Nov-2022 |
Patrisious Haddad <phaddad@nvidia.com> |
net/mlx5e: Rename MACsec flow steering functions/parameters to suit core naming style Rename MACsec flow steering(macsec_fs) functions and parameters from ethernet(core/en_accel) naming convention to core naming convention. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
#
7390762a |
|
29-Nov-2022 |
Patrisious Haddad <phaddad@nvidia.com> |
net/mlx5e: Move MACsec flow steering operations to be used as core library Move MACsec flow steering operations(macsec_fs) from core/en_accel to core/lib, this mandates moving MACsec statistics structure from the general MACsec code header(en_accel/macsec.h) to macsec_fs header to remove macsec_fs.h dependency over en_accel/macsec.h. This to lay the ground for RoCE MACsec by moving all the data that will need to be accessed by both ethernet MACsec and RoCE MACsec to be shared at core. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
#
bd9424ef |
|
10-May-2023 |
Subbaraya Sundeep <sbhatta@marvell.com> |
macsec: Use helper macsec_netdev_priv for offload drivers Now macsec on top of vlan can be offloaded to macsec offloading devices so that VLAN tag is sent in clear text on wire i.e, packet structure is DMAC|SMAC|VLAN|SECTAG. Offloading devices can simply enable NETIF_F_HW_MACSEC feature in netdev->vlan_features for this to work. But the logic in offloading drivers to retrieve the private structure from netdev needs to be changed to check whether the netdev received is real device or a vlan device and get private structure accordingly. This patch changes the offloading drivers to use helper macsec_netdev_priv instead of netdev_priv. Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4bba492b |
|
19-Apr-2023 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5: Support MACsec over VLAN MACsec device may have a VLAN device on top of it. Detect MACsec state correctly under this condition, and return the correct net device accordingly. Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
23532061 |
|
01-Feb-2023 |
Uladzislau Rezki (Sony) <urezki@gmail.com> |
net/mlx5: Rename kfree_rcu() to kfree_rcu_mightsleep() The kfree_rcu() and kvfree_rcu() macros' single-argument forms are deprecated. Therefore switch to the new kfree_rcu_mightsleep() and kvfree_rcu_mightsleep() variants. The goal is to avoid accidental use of the single-argument forms, which can introduce functionality bugs in atomic contexts and latency bugs in non-atomic contexts. Cc: Ariel Levkovich <lariel@nvidia.com> Cc: Saeed Mahameed <saeedm@nvidia.com> Cc: Vlad Buslov <vladbu@nvidia.com> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
|
#
7e3fce82 |
|
20-Mar-2023 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Overcome slow response for first macsec ASO WQE First ASO WQE poll causes a cache miss in hardware hence the resut is delayed. It causes to the situation where such WQE is polled earlier than it is needed. Add logic to retry ASO CQ polling operation. Fixes: 739cfa34518e ("net/mlx5: Make ASO poll CQ usable in atomic context") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
37beabe9 |
|
08-Feb-2023 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Fix macsec ASO context alignment Currently mlx5e_macsec_umr struct does not satisfy hardware memory alignment requirement. Hence the result of querying advanced steering operation (ASO) is not copied to the memory region as expected. Fix by satisfying hardware memory alignment requirement and move context to be first field in struct for better readability. Fixes: 1f53da676439 ("net/mlx5e: Create advanced steering operation (ASO) object for MACsec") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
c673b677 |
|
13-Mar-2022 |
Tariq Toukan <tariqt@nvidia.com> |
net/mlx5: Header file for crypto Take crypto API out of the generic mlx5.h header into a dedicated header. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
9828994a |
|
11-Dec-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Fix macsec possible null dereference when updating MAC security entity (SecY) Upon updating MAC security entity (SecY) in hw offload path, the macsec security association (SA) initialization routine is called. In case of extended packet number (epn) is enabled the salt and ssci attributes are retrieved using the MACsec driver rx_sa context which is unavailable when updating a SecY property such as encoding-sa hence the null dereference. Fix by using the provided SA to set those attributes. Fixes: 4411a6c0abd3 ("net/mlx5e: Support MACsec offload extended packet number (EPN)") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
f5e1ed04 |
|
14-Dec-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Fix macsec ssci attribute handling in offload path Currently when macsec offload is set with extended packet number (epn) enabled, the driver wrongly deduce the short secure channel identifier (ssci) from the salt instead of the stand alone ssci attribute as it should, consequently creating a mismatch between the kernel and driver's ssci values. Fix by using the ssci value from the relevant attribute. Fixes: 4411a6c0abd3 ("net/mlx5e: Support MACsec offload extended packet number (EPN)") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
d11c0ec2 |
|
13-Oct-2022 |
Leon Romanovsky <leon@kernel.org> |
net/mlx5e: Delete always true DMA check DMA address always exists for MACsec ASO object. Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
7c11eae2 |
|
12-Oct-2022 |
Leon Romanovsky <leon@kernel.org> |
net/mlx5e: Don't access directly DMA device pointer Use specialized helper to fetch DMA device pointer. Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
dda3bbbb |
|
29-Nov-2022 |
Saeed Mahameed <saeedm@nvidia.com> |
Revert "net/mlx5e: MACsec, remove replay window size limitation in offload path" This reverts commit c0071be0e16c461680d87b763ba1ee5e46548fde. The cited commit removed the validity checks which initialized the window_sz and never removed the use of the now uninitialized variable, so now we are left with wrong value in the window size and the following clang warning: [-Wuninitialized] drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c:232:45: warning: variable 'window_sz' is uninitialized when used here MLX5_SET(macsec_aso, aso_ctx, window_size, window_sz); Revet at this time to address the clang issue due to lack of time to test the proper solution. Fixes: c0071be0e16c ("net/mlx5e: MACsec, remove replay window size limitation in offload path") Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reported-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20221129093006.378840-1-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
9034b292 |
|
09-Nov-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: MACsec, block offload requests with encrypt off Currently offloading MACsec with authentication only (encrypt property set to off) is not supported, block such requests when adding/updating a macsec device. Fixes: 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
7c5578e2 |
|
08-Nov-2022 |
Raed Salem <raeds@nvidia.com> |
net/mlx5e: MACsec, fix Tx SA active field update Currently during update Tx security association (SA) flow, the Tx SA active state is updated only if the Tx SA in question is the same SA that the MACsec interface is using for Tx,in consequence when the MACsec interface chose to work with this Tx SA later, where this SA for example should have been updated to active state and it was not, the relevant Tx SA HW context won't be installed, hence the MACSec flow won't be offloaded. Fix by update Tx SA active state as part of update flow regardless whether the SA in question is the same Tx SA used by the MACsec interface. Fixes: 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support") Signed-off-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Emeel Hakim <ehakim@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
c0071be0 |
|
31-Oct-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: MACsec, remove replay window size limitation in offload path Currently offload path limits replay window size to 32/64/128/256 bits, such a limitation should not exist since software allows it. Remove such limitation. Fixes: eb43846b43c3 ("net/mlx5e: Support MACsec offload replay window") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
ceb51b27 |
|
31-Oct-2022 |
Raed Salem <raeds@nvidia.com> |
net/mlx5e: MACsec, fix mlx5e_macsec_update_rxsa bail condition and functionality Fix update Rx SA wrong bail condition, naturally update functionality needs to check that something changed otherwise bailout currently the active state check does just the opposite, furthermore unlike deactivate path which remove the macsec rules to deactivate the offload, the activation path does not include the counter part installation of the macsec rules. Fix by using correct bailout condition and when Rx SA changes state to active then add the relevant macsec rules. While at it, refine function name to reflect more precisely its role. Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Emeel Hakim <ehakim@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
eead5ea2 |
|
31-Oct-2022 |
Raed Salem <raeds@nvidia.com> |
net/mlx5e: MACsec, fix update Rx secure channel active field The main functionality for this operation is to update the active state of the Rx security channel (SC) if the new active setting is different from the current active state of this Rx SC, however the relevant active state check is done post updating the current active state to match the new active state, effectively blocks any offload state update for the Rx SC in question. Fix by delay the assignment to be post the relevant check. Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Emeel Hakim <ehakim@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
9b9e23c4 |
|
30-Oct-2022 |
Raed Salem <raeds@nvidia.com> |
net/mlx5e: MACsec, fix memory leak when MACsec device is deleted When the MACsec netdevice is deleted, all related Rx/Tx HW/SW states should be released/deallocated, however currently part of the Rx security channel association data is not cleaned properly, hence the memory leaks. Fix by make sure all related Rx Sc resources are cleaned/freed, while at it improve code by grouping release SC context in a function so it can be used in both delete MACsec device and delete Rx SC operations. Fixes: 5a39816a75e5 ("net/mlx5e: Add MACsec offload SecY support") Signed-off-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Emeel Hakim <ehakim@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
813115c4 |
|
27-Oct-2022 |
Raed Salem <raeds@nvidia.com> |
net/mlx5e: MACsec, fix RX data path 16 RX security channel limit Currently the data path metadata flow id mask wrongly limits the number of different RX security channels (SC) to 16, whereas in adding RX SC the limit is "2^16 - 1" this cause an overlap in metadata flow id once more than 16 RX SCs is added, this corrupts MACsec RX offloaded flow handling. Fix by using the correct mask, while at it improve code to use this mask when adding the Rx rule and improve visibility of such errors by adding debug massage. Fixes: b7c9400cbc48 ("net/mlx5e: Implement MACsec Rx data path using MACsec skb_metadata_dst") Signed-off-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Emeel Hakim <ehakim@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
8514e325 |
|
30-Oct-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Fix possible race condition in macsec extended packet number update routine Currenty extended packet number (EPN) update routine is accessing macsec object without holding the general macsec lock hence facing a possible race condition when an EPN update occurs while updating or deleting the SA. Fix by holding the general macsec lock before accessing the object. Fixes: 4411a6c0abd3 ("net/mlx5e: Support MACsec offload extended packet number (EPN)") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
94ffd6e0 |
|
30-Oct-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Fix MACsec update SecY Currently updating SecY destroys and re-creates RX SA objects, the re-created RX SA objects are not identical to the destroyed objects and it disagree on the encryption enabled property which holds the value false after recreation, this value is not supported with offload which leads to no traffic after an update. Fix by recreating an identical objects. Fixes: 5a39816a75e5 ("net/mlx5e: Add MACsec offload SecY support") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
d20a56b0 |
|
30-Oct-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Fix MACsec SA initialization routine Currently as part of MACsec SA initialization routine extended packet number (EPN) object attribute is always being set without checking if EPN is actually enabled, the above could lead to a NULL dereference. Fix by adding such a check. Fixes: 4411a6c0abd3 ("net/mlx5e: Support MACsec offload extended packet number (EPN)") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
#
12ba40ba |
|
26-Oct-2022 |
Raed Salem <raeds@nvidia.com> |
net/mlx5e: Fix macsec sci endianness at rx sa update The cited commit at rx sa update operation passes the sci object attribute, in the wrong endianness and not as expected by the HW effectively create malformed hw sa context in case of update rx sa consequently, HW produces unexpected MACsec packets which uses this sa. Fix by passing sci to create macsec object with the correct endianness, while at it add __force u64 to prevent sparse check error of type "sparse: error: incorrect type in assignment". Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20221026135153.154807-16-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
74573e38 |
|
26-Oct-2022 |
Raed Salem <raeds@nvidia.com> |
net/mlx5e: Fix macsec rx security association (SA) update/delete The cited commit adds the support for update/delete MACsec Rx SA, naturally, these operations need to check if the SA in question exists to update/delete the SA and return error code otherwise, however they do just the opposite i.e. return with error if the SA exists Fix by change the check to return error in case the SA in question does not exist, adjust error message and code accordingly. Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20221026135153.154807-14-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
d3ecf037 |
|
26-Oct-2022 |
Raed Salem <raeds@nvidia.com> |
net/mlx5e: Fix macsec coverity issue at rx sa update The cited commit at update rx sa operation passes object attributes to MACsec object create function without initializing/setting all attributes fields leaving some of them with garbage values, therefore violating the implicit assumption at create object function, which assumes that all input object attributes fields are set. Fix by initializing the object attributes struct to zero, thus leaving unset fields with the legal zero value. Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Lior Nahmanson <liorna@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20221026135153.154807-13-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
f8127476 |
|
19-Oct-2022 |
Leon Romanovsky <leon@kernel.org> |
net/mlx5e: Cleanup MACsec uninitialization routine The mlx5e_macsec_cleanup() routine has NULL pointer dereferencing if mlx5 device doesn't support MACsec (priv->macsec will be NULL). While at it delete comment line, assignment and extra blank lines, so fix everything in one patch. Fixes: 1f53da676439 ("net/mlx5e: Create advanced steering operation (ASO) object for MACsec") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
739cfa34 |
|
11-Oct-2022 |
Leon Romanovsky <leon@kernel.org> |
net/mlx5: Make ASO poll CQ usable in atomic context Poll CQ functions shouldn't sleep as they are called in atomic context. The following splat appears once the mlx5_aso_poll_cq() is used in such flow. BUG: scheduling while atomic: swapper/17/0/0x00000100 Modules linked in: sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core fuse [last unloaded: mlx5_core] CPU: 17 PID: 0 Comm: swapper/17 Tainted: G W 6.0.0-rc2+ #13 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x34/0x44 __schedule_bug.cold+0x47/0x53 __schedule+0x4b6/0x670 ? hrtimer_start_range_ns+0x28d/0x360 schedule+0x50/0x90 schedule_hrtimeout_range_clock+0x98/0x120 ? __hrtimer_init+0xb0/0xb0 usleep_range_state+0x60/0x90 mlx5_aso_poll_cq+0xad/0x190 [mlx5_core] mlx5e_ipsec_aso_update_curlft+0x81/0xb0 [mlx5_core] xfrm_timer_handler+0x6b/0x360 ? xfrm_find_acq_byseq+0x50/0x50 __hrtimer_run_queues+0x139/0x290 hrtimer_run_softirq+0x7d/0xe0 __do_softirq+0xc7/0x272 irq_exit_rcu+0x87/0xb0 sysvec_apic_timer_interrupt+0x72/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x16/0x20 RIP: 0010:default_idle+0x18/0x20 Code: ae 7d ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 8b 05 b5 30 0d 01 85 c0 7e 07 0f 00 2d 0a e3 53 00 fb f4 <c3> 0f 1f 80 00 00 00 00 0f 1f 44 00 00 65 48 8b 04 25 80 ad 01 00 RSP: 0018:ffff888100883ee0 EFLAGS: 00000242 RAX: 0000000000000001 RBX: ffff888100849580 RCX: 4000000000000000 RDX: 0000000000000001 RSI: 0000000000000083 RDI: 000000000008863c RBP: 0000000000000011 R08: 00000064e6977fa9 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 default_idle_call+0x37/0xb0 do_idle+0x1cd/0x1e0 cpu_startup_entry+0x19/0x20 start_secondary+0xfe/0x120 secondary_startup_64_no_verify+0xcd/0xdb </TASK> softirq: huh, entered softirq 8 HRTIMER 00000000a97c08cb with preempt_count 00000100, exited with 00000000? Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
36c2ebce |
|
21-Sep-2022 |
Antoine Tenart <atenart@kernel.org> |
net/mlx5e: macsec: remove checks on the prepare phase Remove checks on the prepare phase as it is now unused by the MACsec core implementation. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
eb43846b |
|
21-Sep-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Support MACsec offload replay window Support setting replay window size for MACsec offload. Currently supported window size of 32, 64, 128 and 256 bit. Other values will be returned as invalid parameter. Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
4411a6c0 |
|
21-Sep-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Support MACsec offload extended packet number (EPN) MACsec EPN splits the packet number (PN) into two 32-bits fields, epn_lsb (32 least significant bits (LSBs) of PN) and epn_msb (32 most significant bits (MSBs) of PN). Epn_msb bits are managed by SW and for that HW is required to send an object change event of type EPN event notifying the SW to update the epn_msb in addition, once epn_msb is updated SW update HW with the new epn_msb value for HW to perform replay protection. To prevent HW from stopping while handling the event, SW manages another bit for HW called epn_overlap, HW uses the latter to get an indication regarding how to read the epn_msb value correctly while still receiving packets. Add epn event handling that updates the epn_overlap and epn_msb for every 2^31 packets according to the following logic: if epn_lsb crosses 2^31 (half sequence number wraparound) upon HW relevant event, SW updates the esn_overlap value to OLD (value = 1). When the epn_lsb crosses 2^32 (full sequence number wraparound) upon HW relevant event, SW updates the esn_overlap to NEW (value = 0) and increment the esn_msb. When using MACsec EPN a salt and short secure channel id (ssci) needs to be provided by the user, when offloading EPN need to pass this salt and ssci to the HW to be used in the initial vector (IV) calculations. Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
1f53da67 |
|
21-Sep-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Create advanced steering operation (ASO) object for MACsec Add support for ASO work queue entry (WQE) data to allow reading data upon querying the ASO work queue (WQ). Register user mode memory registration (UMR) upon ASO WQ init, de-register UMR upon ASO WQ cleanup. MACsec uses UMR to determine the cause of the event triggered by the HW since different scenarios could trigger the same event. Setup MACsec ASO object to sync HW with SW about various macsec flow stateful features like: replay window, lifetime limits e.t.c Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
cb6d3c0f |
|
21-Sep-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Fix MACsec initial packet number Currently when creating MACsec object, next_pn which represents the initial packet number (PN) is considered only in TX flow. The above causes mismatch between TX and RX initial PN which is reflected in packet drops. Fix by considering next_pn in RX flow too. Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
6c5e0b25 |
|
21-Sep-2022 |
Emeel Hakim <ehakim@nvidia.com> |
net/mlx5e: Fix MACsec initialization error path Currently MACsec initialization error path does not destroy sci hash table in case of failure. Fix by destroying hash table in case of failure. Fixes: 9515978eee0b ("net/mlx5e: Implement MACsec Tx data path using MACsec skb_metadata_dst") Signed-off-by: Emeel Hakim <ehakim@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
13c76227 |
|
14-Sep-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
net/mlx5e: Switch to kmemdup() when allocate dev_addr Use kmemdup() helper instead of open-coding to simplify the code when allocate dev_addr. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20220914140100.3795545-2-yangyingliang@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
46ff47bc |
|
14-Sep-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
net/mlx5e: add missing error code in error path Add missing error code when mlx5e_macsec_fs_add_rule() or mlx5e_macsec_fs_init() fails. mlx5e_macsec_fs_init() don't return ERR_PTR(), so replace IS_ERR_OR_NULL() check with NULL pointer check. Fixes: e467b283ffd5 ("net/mlx5e: Add MACsec TX steering rules") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20220914140100.3795545-1-yangyingliang@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
99d4dc66 |
|
05-Sep-2022 |
Lior Nahmanson <liorna@nvidia.com> |
net/mlx5e: Add support to configure more than one macsec offload device Add the ability to add up to 16 MACsec offload interfaces over the same physical interface Signed-off-by: Lior Nahmanson <liorna@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
807a1b76 |
|
05-Sep-2022 |
Lior Nahmanson <liorna@nvidia.com> |
net/mlx5e: Add MACsec stats support for Rx/Tx flows Add the following statistics: RX successfully decrypted MACsec packets: macsec_rx_pkts : Number of packets decrypted successfully macsec_rx_bytes : Number of bytes decrypted successfully Rx dropped MACsec packets: macsec_rx_pkts_drop : Number of MACsec packets dropped macsec_rx_bytes_drop : Number of MACsec bytes dropped TX successfully encrypted MACsec packets: macsec_tx_pkts : Number of packets encrypted/authenticated successfully macsec_tx_bytes : Number of bytes encrypted/authenticated successfully Tx dropped MACsec packets: macsec_tx_pkts_drop : Number of MACsec packets dropped macsec_tx_bytes_drop : Number of MACsec bytes dropped The above can be seen using: ethtool -S <ifc> |grep macsec Signed-off-by: Lior Nahmanson <liorna@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5a39816a |
|
05-Sep-2022 |
Lior Nahmanson <liorna@nvidia.com> |
net/mlx5e: Add MACsec offload SecY support Add offload support for MACsec SecY callbacks - add/update/delete. add_secy is called when need to create a new MACsec interface. upd_secy is called when source MAC address or tx SC was changed. del_secy is called when need to destroy the MACsec interface. Signed-off-by: Lior Nahmanson <liorna@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b7c9400c |
|
05-Sep-2022 |
Lior Nahmanson <liorna@nvidia.com> |
net/mlx5e: Implement MACsec Rx data path using MACsec skb_metadata_dst MACsec driver need to distinguish to which offload device the MACsec is target to, in order to handle them correctly. This can be done by attaching a metadata_dst to a SKB with a SCI, when there is a match on MACsec rule. To achieve that, there is a map between fs_id to SCI, so for each RX SC, there is a unique fs_id allocated when creating RX SC. fs_id passed to device driver as metadata for packets that passed Rx MACsec offload to aid the driver to retrieve the matching SCI. Signed-off-by: Lior Nahmanson <liorna@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3b20949c |
|
05-Sep-2022 |
Lior Nahmanson <liorna@nvidia.com> |
net/mlx5e: Add MACsec RX steering rules Rx flow steering consists of two flow tables (FTs). The first FT (crypto table) have one default miss rule so non MACsec offloaded packets bypass the MACSec tables. All others flow table entries (FTEs) are divided to two equal groups size, both of them are for MACsec packets: The first group is for MACsec packets which contains SCI field in the SecTAG header. The second group is for MACsec packets which doesn't contain SCI, where need to match on the source MAC address (only if the SCI is built from default MACsec port). Destination MAC address, ethertype and some of SecTAG fields are also matched for both groups. In case of match, invoke decrypt action on the packet. For each MACsec Rx offloaded SA two rules are created: one with SCI and one without SCI. The second FT (check table) has two fixed rules: One rule is for verifying that the previous offload actions were finished successfully. In this case, need to decap the SecTAG header and forward the packet for further processing. Another default rule for dropping packets that failed in the previous decrypt actions. The MACsec FTs are created on demand when the first MACsec rule is added and destroyed when the last MACsec rule is deleted. Signed-off-by: Lior Nahmanson <liorna@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
aae3454e |
|
05-Sep-2022 |
Lior Nahmanson <liorna@nvidia.com> |
net/mlx5e: Add MACsec offload Rx command support Add a support for Connect-X MACsec offload Rx SA & SC commands: add, update and delete. SCs are created on demend and aren't limited by number and unique by SCI. Each Rx SA must be associated with Rx SC according to SCI. Follow-up patches will implement the Rx steering. Signed-off-by: Lior Nahmanson <liorna@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9515978e |
|
05-Sep-2022 |
Lior Nahmanson <liorna@nvidia.com> |
net/mlx5e: Implement MACsec Tx data path using MACsec skb_metadata_dst MACsec driver marks Tx packets for device offload using a dedicated skb_metadata_dst which holds a 64 bits SCI number. A previously set rule will match on this number so the correct SA is used for the MACsec operation. As device driver can only provide 32 bits of metadata to flow tables, need to used a mapping from 64 bit to 32 bits marker or id, which is can be achieved by provide a 32 bit unique flow id in the control path, and used a hash table to map 64 bit to the unique id in the datapath. Signed-off-by: Lior Nahmanson <liorna@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e467b283 |
|
05-Sep-2022 |
Lior Nahmanson <liorna@nvidia.com> |
net/mlx5e: Add MACsec TX steering rules Tx flow steering consists of two flow tables (FTs). The first FT (crypto table) has two fixed rules: One default miss rule so non MACsec offloaded packets bypass the MACSec tables, another rule to make sure that MACsec key exchange (MKE) traffic passes unencrypted as expected (matched of ethertype). On each new MACsec offload flow, a new MACsec rule is added. This rule is matched on metadata_reg_a (which contains the id of the flow) and invokes the MACsec offload action on match. The second FT (check table) has two fixed rules: One rule for verifying that the previous offload actions were finished successfully and packet need to be transmitted. Another default rule for dropping packets that were failed in the offload actions. The MACsec FTs should be created on demand when the first MACsec rule is added and destroyed when the last MACsec rule is deleted. Signed-off-by: Lior Nahmanson <liorna@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8ff0ac5b |
|
05-Sep-2022 |
Lior Nahmanson <liorna@nvidia.com> |
net/mlx5: Add MACsec offload Tx command support This patch adds support for Connect-X MACsec offload Tx SA commands: add, update and delete. In Connect-X MACsec, a Security Association (SA) is added or deleted via allocating a HW context of an encryption/decryption key and a HW context of a matching SA (MACsec object). When new SA is added: - Use a separate crypto key HW context. - Create a separate MACsec context in HW to include the SA properties. Introduce a new compilation flag MLX5_EN_MACSEC for it. Follow-up patches will implement the Tx steering. Signed-off-by: Lior Nahmanson <liorna@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|