While testing the support for setting the MAC type [0], rmmod while multiple vports are up would occasionally report an error, caused by a VC message being sent with opcode 536, attempting to delete a MAC filter that was already deleted by the call to idpf_vport_stop(): idpf 0000:83:00.0: Received invalid MAC filter payload (op 536) (len 0)
This can happen as idpf_addr_unsync() is called via ndo_set_rx_mode() while idpf_vport_stop() is called by rmmod: rmmod-231066 [004] ..... 100851.014226: idpf_add_del_mac_filters <-idpf_vport_stop systemd-resolve-1364 [029] b..1. 100851.159457: idpf_add_del_mac_filters <-idpf_addr_unsync Though the issue was discovered while testing the MAC type change, it is not specific to that flow, hence why it is posted in a separate series. While it can be applied on its own, for the purpose of testing it is recommended to be applied on top of [0]. The changes are split in 2 parts: - The first commit is just a conversion to bitmap for the vport state. - Second commit plugs the race by making sure the IDPF_VPORT_UP bit is cleared by idpf_vport_stop() on entry. [0] https://lore.kernel.org/intel-wired-lan/[email protected]/ Emil Tantilov (2): idpf: convert vport state to bitmap idpf: fix possible race in idpf_vport_stop() drivers/net/ethernet/intel/idpf/idpf.h | 12 ++++------ .../net/ethernet/intel/idpf/idpf_ethtool.c | 10 ++++---- drivers/net/ethernet/intel/idpf/idpf_lib.c | 23 +++++++++---------- .../ethernet/intel/idpf/idpf_singleq_txrx.c | 2 +- drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +- .../net/ethernet/intel/idpf/idpf_virtchnl.c | 4 ++-- 6 files changed, 25 insertions(+), 28 deletions(-) -- 2.37.3
