summaryrefslogtreecommitdiff
path: root/lib/debugobjects.c
diff options
context:
space:
mode:
Diffstat (limited to 'lib/debugobjects.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit (git 2.34.1) at 2025-12-09 04:29:07 +0000
-02-22 21:24:51 -0800'>2020-02-22mlxsw: spectrum_router: Take router lock from inside routing codeIdo Schimmel There are several work items in the routing code that currently rely on RTNL lock to guard against concurrent changes. Have these work items acquire the router lock in preparation for the removal for RTNL lock from the routing code. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-22mlxsw: spectrum_router: Introduce router lockIdo Schimmel Introduce a mutex to protect the internal structure of the routing code. A single lock is added instead of a more fine-grained and complicated locking scheme because there is not a lot of concurrency in the routing code. The main motivation is remove the dependence on RTNL lock, which is currently used by both the process pushing routes to the kernel and the workqueue pushing the routes to the underlying device. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-22mlxsw: spectrum_router: Store NVE decapsulation configuration in routerIdo Schimmel When a host route is added, the driver checks if the route needs to be promoted to perform NVE decapsulation based on the current NVE configuration. If so, the index of the decapsulation entry is retrieved and associated with the route. Currently, this information is stored in the NVE module which the router module consults. Since the information is protected under RTNL and since route insertion happens with RTNL held, there is no problem to retrieve the information from the NVE module. However, this is going to change and route insertion will no longer happen under RTNL. Instead, a dedicated lock will be introduced for the router module. Therefore, store this information in the router module and change the router module to consult this copy. The validity of the information is set / cleared whenever an NVE tunnel is initialized / de-initialized. When this happens the NVE module calls into the router module to promote / demote the relevant host route. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-22mlxsw: spectrum_router: Expose router struct to internal usersIdo Schimmel The dpipe code accesses internal router data structures and acquires RTNL to protect against their changes. Subsequent patches will remove reliance on RTNL and introduce a dedicated lock to protect router data structures. Publish the router struct to internal users such as the dpipe, so that they could acquire it instead of RTNL. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-22mlxsw: spectrum_mr: Protect multicast route list with a lockIdo Schimmel Protect the per-table multicast route list with a lock and remove RTNL from the delayed work that periodically updates the kernel about packets and bytes statistics from each multicast route. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-22mlxsw: spectrum_mr: Protect multicast table list with a lockIdo Schimmel The multicast table list is traversed from a delayed work that periodically updates the kernel about packets and bytes statistics from each multicast route. The list is currently protected by RTNL, but subsequent patches will remove the driver's dependence on this contended lock. In order to be able to remove dependence on RTNL in the next patch, guard this list with a dedicated mutex. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-22mlxsw: spectrum_mr: Publish multicast route after writing it to the deviceIdo Schimmel The driver periodically traverses the linked list of multicast routes and updates the kernel about packets and bytes statistics from each multicast route. These statistics are read from a counter associated with the route when it is written to the device. Currently, multicast routes are published via this linked list before they are associated with a counter. Despite that, it is not possible for the driver to access an invalid counter because the delayed work that reads the statistics and multicast route addition / deletion are mutually exclusive using RTNL. In order to be able to remove RTNL, the list needs to be protected by a dedicated lock, but any route published via the list must have an associated counter, otherwise the driver will access an invalid counter. Solve this by re-ordering the operations during multicast route addition so that the route is only added to the linked list after it was written to the device. Similarly, during deletion the route is first removed from the linked list before its deletion from the device. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-21net/mlx5: Add fsm_reactivate callback supportEran Ben Elisha Add support for fsm reactivate via MIRC (Management Image Re-activation Control) set and query commands. For re-activation flow, driver shall first run MIRC set, and then wait until FW is done (via querying MIRC status). Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-21net/mlxfw: Add reactivate flow support to FSM burn flowEran Ben Elisha Expose fsm_reactivate callback to the mlxfw_dev_ops struct. FSM reactivate is needed before flashing the new image in order to flush the old flashed but not running firmware image. In case mlxfw_dev do not support the reactivation, this step will be skipped. But if later image flash will fail, a hint will be provided by the extack to advise the user that the failure might be related to it. Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-21net/mlxfw: Use MLXFW_ERR_MSG macro for error reportingSaeed Mahameed Instead of always calling both mlxfw_err and NL_SET_ERR_MSG_MOD with the same message, use the dedicated macro instead. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-21net/mlxfw: Convert pr_* to dev_* in mlxfw_fsm.cSaeed Mahameed Introduce mlxfw_{info, err, dbg} macros and make them call corresponding dev_* macros, then convert all instances of pr_* to mlxfw_*. This will allow printing the device name mlxfw is operating on. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-21net/mlxfw: More error messages coverageSaeed Mahameed Make sure mlxfw_firmware_flash reports a detailed user readable error message in every possible error path, basically every time mlxfw_dev->ops->*() is called and an error is returned, or when image initialization is failed. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-21net/mlxfw: Improve FSM err message reporting and return codesSaeed Mahameed Report unique and standard error codes corresponding to the specific FW flash error. In addition, add a more detailed error messages to netlink. Before: $ devlink dev flash pci/0000:05:00.0 file ... Error: mlxfw: Firmware flash failed. devlink answers: Invalid argument After: $ devlink dev flash pci/0000:05:00.0 file ... Error: mlxfw: Firmware flash failed: pending reset. devlink answers: Device busy Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-02-21net/mlxfw: Generic mlx FW flash status notifySaeed Mahameed FW flash status notify is currently implemented via a callback to the caller mlx module, and all it is doing is to call devlink_flash_update_status_notify with the specific module devlink instance. Instead of repeating the whole process for all mlx modules and re-implement the status_notify callback again and again. Just provide the devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash and let mlxfw do the devlink status updates directly. This will be very useful for adding status notify support to mlx5, as already done in this patch, with a simple one line of just providing the devlink instance to mlxfw_firmware_flash. mlxfw now depends on NET_DEVLINK as all other mlx modules. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>