sfc: Take mac_lock before calling efx_ef10_filter_table_probe
authorMartin Habets <mhabets@solarflare.com>
Wed, 15 Jun 2016 16:48:49 +0000 (17:48 +0100)
committerDavid S. Miller <davem@davemloft.net>
Thu, 16 Jun 2016 05:26:26 +0000 (22:26 -0700)
commitd248953a3ccd218893b5119a0e63058f0dabca67
tree149c4b4bfb07deb8d13e524e3ba3949e709a95c6
parent4a53ea8a74248adfb3179c4ede3d741a5dd9ef5a
sfc: Take mac_lock before calling efx_ef10_filter_table_probe

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: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/ethernet/sfc/ef10.c
drivers/net/ethernet/sfc/ef10_sriov.c
drivers/net/ethernet/sfc/efx.c