Hi, > Does this silent reset desynchronize the driver from the ethtool core?
I will leave the ordinary allocation path unchanged in v8. The stale user-indirection metadata is a real gap, but both upstream bases already reinitialize the RSS table in mana_alloc_queues() without clearing the ethtool core's user-table state. It is not introduced by this series. A hardware queue-limit reduction during reattach can make a saved user table invalid. Rebuilding a default table without reporting the loss can then leave the core describing a user configuration that no longer exists. I am treating this as an independent baseline issue, not claiming that documenting the silent reset makes it correct. The specific later-growth scenario also needs qualification because the inspected reattach path monotonically clamps apc->max_queues. The stale metadata and missing loss notification are the more direct issues. > Can we safely call ethtool_rxfh_indir_lost() here to keep the states > synchronized? Not solely on the basis of its initial RTNL assertion. The notification call chain also reaches netdev_assert_locked_ops_compat(). MANA registers net_shaper_ops, so that check requires the netdev operations lock. The reset worker holds RTNL but not that lock. A separate correction needs to account for the notification context and locking of every ordinary allocation caller; an unconditional helper call at this location is not sufficient. That broader baseline fix is outside this queue-set revision. Thanks, Wei
