aboutsummaryrefslogtreecommitdiff
path: root/lib/mpi/mpi-add.c
diff options
context:
space:
mode:
authorVladimir Oltean <[email protected]>2022-11-29 16:12:16 +0200
committerPaolo Abeni <[email protected]>2022-12-01 13:40:22 +0100
commit29811d6e19d795efcf26644b66c4152abbac35a6 (patch)
treef1477ebcd909783f65ec392267eab6c99f10ce26 /lib/mpi/mpi-add.c
parent88d64367cea019fa6197d0d97a85ac90279919b7 (diff)
net: dpaa2: publish MAC stringset to ethtool -S even if MAC is missing
DPNIs and DPSW objects can connect and disconnect at runtime from DPMAC objects on the same fsl-mc bus. The DPMAC object also holds "ethtool -S" unstructured counters. Those counters are only shown for the entity owning the netdev (DPNI, DPSW) if it's connected to a DPMAC. The ethtool stringset code path is split into multiple callbacks, but currently, connecting and disconnecting the DPMAC takes the rtnl_lock(). This blocks the entire ethtool code path from running, see ethnl_default_doit() -> rtnl_lock() -> ops->prepare_data() -> strset_prepare_data(). This is going to be a problem if we are going to no longer require rtnl_lock() when connecting/disconnecting the DPMAC, because the DPMAC could appear between ops->get_sset_count() and ops->get_strings(). If it appears out of the blue, we will provide a stringset into an array that was dimensioned thinking the DPMAC wouldn't be there => array accessed out of bounds. There isn't really a good way to work around that, and I don't want to put too much pressure on the ethtool framework by playing locking games. Just make the DPMAC counters be always available. They'll be zeroes if the DPNI or DPSW isn't connected to a DPMAC. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Ioana Ciornei <[email protected]> Tested-by: Ioana Ciornei <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
Diffstat (limited to 'lib/mpi/mpi-add.c')
0 files changed, 0 insertions, 0 deletions