• M
    sfc: Take mac_lock before calling efx_ef10_filter_table_probe · d248953a
    Martin Habets 提交于
    When trying to enslave an SFC interface to a bond the following BUG_ON was
    hit:
    
     kernel BUG [in ef10.c]!
     CPU: 0 PID: 4383 Comm: ifenslave Tainted: G
    ...
     Call Trace:
      efx_ef10_filter_add_vlan+0x121/0x180 [sfc]
      efx_ef10_filter_table_probe+0x2a2/0x4f0 [sfc]
      efx_ef10_set_mac_address+0x370/0x6d0 [sfc]
      efx_set_mac_address+0x7d/0x120 [sfc]
      dev_set_mac_address+0x43/0xa0
      bond_enslave+0x337/0xea0 [bonding]
    This comes from function efx_ef10_filter_vlan_sync_rx_mode.
    
    To solve the bug we ensure the mac_lock is taken before calling
    efx_ef10_filter_add_vlan. But to avoid a priority inversion mac_lock must
    be taken before filter_sem.
    To satisfy these requirements we end up taking mac_lock in
    efx_ef10_vport_set_mac_address, efx_ef10_set_mac_address,
    efx_ef10_sriov_set_vf_vlan and efx_probe_filters.
    Signed-off-by: NEdward Cree <ecree@solarflare.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    d248953a
efx.c 91.5 KB