diff options
| author | Alexander Duyck <alexanderduyck@fb.com> | 2026-09-28 09:12:15 -0700 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-10-01 18:04:42 -0700 |
| commit | db99b6fae21cfc09d7201b18470acbc01e45d038 (patch) | |
| tree | d8cfa5b8875aa3e754692ffd3a40511ccc346507 /tools/lib/python/kdoc/python_version.py | |
| parent | d261a371e3b74c82c417b1171264dd35f6ddc615 (diff) | |
fbnic: Remove BMC routing rules when the BMC channel is disabled
While a BMC is present the driver programs MACDA entries for the BMC
addresses, action rules steering matching traffic to it, the DEST_BMC copy
bit on the multicast/broadcast RSS actions, and a host-unicast copy of the
RSS actions. All of these are only torn down when the host interface goes
down.
A BMC can disable its NC-SI channel while the host interface stays up. The
filters are then left in place, so the host keeps steering traffic to a BMC
that is no longer there, and the driver logs "Found BMC MAC address w/ BMC
not present" at the next interface down.
Detect that bmc_present dropped while BMC tagged rules are still programmed
in fbnic_bmc_rpc_check(), and remove the BMC MAC entries, the action rule
and the host-unicast RSS entries. That needs three supporting changes:
1. Action rules must be marked for deletion in any live state rather than
only VALID, as a missed deletion leaks the rule for good. The same
applies to the BMC all-multi rule, which ifdown leaves in UPDATE.
2. The host-unicast entries have to go because fbnic_rss_reinit() only
programs them while a BMC is present and would otherwise leave them
stale and valid in hardware.
3. Recompute the RSS actions for both directions; without that a disable
and re-enable cycle leaves the BMC without its multicast/broadcast
copies until the interface bounces.
Take the instance lock over the whole of fbnic_bmc_rpc_check() while here.
fbnic_fw_xmit_rpc_macda_sync() walks the entire MACDA shadow and the
teardown above rewrites it, but the service task they both run from holds
only RTNL. RTNL used to cover that, back when ndo_set_rx_mode() was called
inline from dev_set_rx_mode(). fbnic is ops-locked, so netif_rx_mode_run()
now calls ndo_set_rx_mode_async() under the instance lock alone, having
dropped netif_addr_lock and handed over a snapshot of the address lists.
The ethtool NFC paths are in the same position. The instance lock is the
one lock every writer of the shadow holds. The flags are tested once
without it first so the lock stays off the common path, where the service
task has nothing to do.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/179061193535.414394.10077526689774524435.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions
