summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
AgeCommit message (Collapse)AuthorFilesLines
2023-03-13ice: merge ice_mbx_report_malvf with ice_mbx_vf_state_handlerJacob Keller1-36/+15
The ice_mbx_report_malvf function is used to update the ice_mbx_vf_info.malicious member after we detect a malicious VF. This is done by calling ice_mbx_report_malvf after ice_mbx_vf_state_handler sets its "is_malvf" return parameter true. Instead of requiring two steps, directly update the malicious bit in the state handler, and remove the need for separately calling ice_mbx_report_malvf. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Marek Szlosek <marek.szlosek@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-03-13ice: remove ice_mbx_deinit_snapshotJacob Keller1-14/+0
The ice_mbx_deinit_snapshot function's only remaining job is to clear the previous snapshot data. This snapshot data is initialized when SR-IOV adds VFs, so it is not necessary to clear this data when removing VFs. Since no allocation occurs we no longer need to free anything and we can safely remove this function. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Marek Szlosek <marek.szlosek@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-03-13ice: move VF overflow message count into struct ice_mbx_vf_infoJacob Keller1-112/+55
The ice driver has some logic in ice_vf_mbx.c used to detect potentially malicious VF behavior with regards to overflowing the PF mailbox. This logic currently stores message counts in struct ice_mbx_vf_counter.vf_cntr as an array. This array is allocated during initialization with ice_mbx_init_snapshot. This logic makes sense for SR-IOV where all VFs are allocated at once up front. However, in the future with Scalable IOV this logic will not work. VFs can be added and removed dynamically. We could try to keep the vf_cntr array for the maximum possible number of VFs, but this is a waste of memory. Use the recently introduced struct ice_mbx_vf_info structure to store the message count. Pass a pointer to the mbx_info for a VF instead of using its VF ID. Replace the array of VF message counts with a linked list that tracks all currently active mailbox tracking info structures. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Marek Szlosek <marek.szlosek@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-03-13ice: track malicious VFs in new ice_mbx_vf_info structureJacob Keller1-40/+31
Currently the PF tracks malicious VFs in a malvfs bitmap which is used by the ice_mbx_clear_malvf and ice_mbx_report_malvf functions. This bitmap is used to ensure that we only report a VF as malicious once rather than continuously spamming the event log. This mechanism of storage for the malicious indication works well enough for SR-IOV. However, it will not work with Scalable IOV. This is because Scalable IOV VFs can be allocated dynamically and might change VF ID when their underlying VSI changes. To support this, the mailbox overflow logic will need to be refactored. First, introduce a new ice_mbx_vf_info structure which will be used to store data about a VF. Embed this structure in the struct ice_vf, and ensure it gets initialized when a new VF is created. For now this only stores the malicious indicator bit. Pass a pointer to the VF's mbx_info structure instead of using a bitmap to keep track of these bits. A future change will extend this structure and the rest of the logic associated with the overflow detection. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Marek Szlosek <marek.szlosek@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-03-13ice: convert ice_mbx_clear_malvf to void and use WARNJacob Keller1-9/+7
The ice_mbx_clear_malvf function checks for a few error conditions before clearing the appropriate data. These error conditions are really warnings that should never occur in a properly initialized driver. Every caller of ice_mbx_clear_malvf just prints a dev_dbg message on failure which will generally be ignored. Convert this function to void and switch the error return values to WARN_ON. This will make any potentially misconfiguration more visible and makes future refactors that involve changing how we store the malicious VF data easier. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Marek Szlosek <marek.szlosek@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-03-13ice: re-order ice_mbx_reset_snapshot functionJacob Keller1-24/+24
A future change is going to refactor the VF mailbox overflow detection logic, including modifying ice_mbx_reset_snapshot and its callers. To make this change easier to review, first move the ice_mbx_reset_snapshot function higher in the ice_vf_mbx.c file. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Marek Szlosek <marek.szlosek@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-02-07ice: fix out-of-bounds KASAN warning in virtchnlMichal Swiatkowski1-13/+8
KASAN reported: [ 9793.708867] BUG: KASAN: global-out-of-bounds in ice_get_link_speed+0x16/0x30 [ice] [ 9793.709205] Read of size 4 at addr ffffffffc1271b1c by task kworker/6:1/402 [ 9793.709222] CPU: 6 PID: 402 Comm: kworker/6:1 Kdump: loaded Tainted: G B OE 6.1.0+ #3 [ 9793.709235] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.00.01.0014.070920180847 07/09/2018 [ 9793.709245] Workqueue: ice ice_service_task [ice] [ 9793.709575] Call Trace: [ 9793.709582] <TASK> [ 9793.709588] dump_stack_lvl+0x44/0x5c [ 9793.709613] print_report+0x17f/0x47b [ 9793.709632] ? __cpuidle_text_end+0x5/0x5 [ 9793.709653] ? ice_get_link_speed+0x16/0x30 [ice] [ 9793.709986] ? ice_get_link_speed+0x16/0x30 [ice] [ 9793.710317] kasan_report+0xb7/0x140 [ 9793.710335] ? ice_get_link_speed+0x16/0x30 [ice] [ 9793.710673] ice_get_link_speed+0x16/0x30 [ice] [ 9793.711006] ice_vc_notify_vf_link_state+0x14c/0x160 [ice] [ 9793.711351] ? ice_vc_repr_cfg_promiscuous_mode+0x120/0x120 [ice] [ 9793.711698] ice_vc_process_vf_msg+0x7a7/0xc00 [ice] [ 9793.712074] __ice_clean_ctrlq+0x98f/0xd20 [ice] [ 9793.712534] ? ice_bridge_setlink+0x410/0x410 [ice] [ 9793.712979] ? __request_module+0x320/0x520 [ 9793.713014] ? ice_process_vflr_event+0x27/0x130 [ice] [ 9793.713489] ice_service_task+0x11cf/0x1950 [ice] [ 9793.713948] ? io_schedule_timeout+0xb0/0xb0 [ 9793.713972] process_one_work+0x3d0/0x6a0 [ 9793.714003] worker_thread+0x8a/0x610 [ 9793.714031] ? process_one_work+0x6a0/0x6a0 [ 9793.714049] kthread+0x164/0x1a0 [ 9793.714071] ? kthread_complete_and_exit+0x20/0x20 [ 9793.714100] ret_from_fork+0x1f/0x30 [ 9793.714137] </TASK> [ 9793.714151] The buggy address belongs to the variable: [ 9793.714158] ice_aq_to_link_speed+0x3c/0xffffffffffff3520 [ice] [ 9793.714632] Memory state around the buggy address: [ 9793.714642] ffffffffc1271a00: f9 f9 f9 f9 00 00 05 f9 f9 f9 f9 f9 00 00 02 f9 [ 9793.714656] ffffffffc1271a80: f9 f9 f9 f9 00 00 04 f9 f9 f9 f9 f9 00 00 00 00 [ 9793.714670] >ffffffffc1271b00: 00 00 00 04 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 [ 9793.714680] ^ [ 9793.714690] ffffffffc1271b80: 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 00 00 00 00 [ 9793.714704] ffffffffc1271c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The ICE_AQ_LINK_SPEED_UNKNOWN define is BIT(15). The value is bigger than both legacy and normal link speed tables. Add one element (0 - unknown) to both tables. There is no need to explicitly set table size, leave it empty. Fixes: 1d0e28a9be1f ("ice: Remove and replace ice speed defines with ethtool.h versions") Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
2022-11-23ice: Remove and replace ice speed defines with ethtool.h versionsBrett Creeley1-68/+24
The driver is currently using ICE_LINK_SPEED_* defines that mirror what ethtool.h defines, with one exception ICE_LINK_SPEED_UNKNOWN. This issue is fixed by the following changes: 1. replace ICE_LINK_SPEED_UNKNOWN with 0 because SPEED_UNKNOWN in ethtool.h is "-1" and that doesn't match the driver's expected behavior 2. transform ICE_LINK_SPEED_*MBPS to SPEED_* using static tables and fls()-1 to convert from BIT() to an index in a table. Suggested-by: Alexander Lobakin <alexandr.lobakin@intel.com> Signed-off-by: Brett Creeley <brett.creeley@intel.com> Co-developed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: rename ice_sriov.c to ice_vf_mbx.cJacob Keller1-0/+532
The ice_sriov.c file primarily contains code which handles the logic for mailbox overflow detection and some other utility functions related to the virtualization mailbox. The bulk of the SR-IOV implementation is actually found in ice_virtchnl_pf.c, and this file isn't strictly SR-IOV specific. In the future, the ice driver will support an additional virtualization scheme known as Scalable IOV, and the code in this file will be used for this alternative implementation. Rename this file (and its associated header) to ice_vf_mbx.c, so that we can later re-use the ice_sriov.c file as the SR-IOV specific file. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>