• Manikanta Pubbisetty's avatar
    mac80211: restrict delayed tailroom needed decrement · 133bf90d
    Manikanta Pubbisetty authored
    As explained in ieee80211_delayed_tailroom_dec(), during roam,
    keys of the old AP will be destroyed and new keys will be
    installed. Deletion of the old key causes
    crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key
    installation causes a transition from 0 to 1.
    
    Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1,
    we invoke synchronize_net(); the reason for doing this is to avoid
    a race in the TX path as explained in increment_tailroom_need_count().
    This synchronize_net() operation can be slow and can affect the station
    roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt
    is delayed for a while so that upon installation of new key the
    transition would be from 1 to 2 instead of 0 to 1 and thereby
    improving the roam time.
    
    This is all correct for a STA iftype, but deferring the tailroom_needed
    decrement for other iftypes may be unnecessary.
    
    For example, let's consider the case of a 4-addr client connecting to
    an AP for which AP_VLAN interface is also created, let the initial
    value for tailroom_needed on the AP be 1.
    
    * 4-addr client connects to the AP (AP: tailroom_needed = 1)
    * AP will clear old keys, delay decrement of tailroom_needed count
    * AP_VLAN is created, it takes the tailroom count from master
      (AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
    * Install new key for the station, assume key is plumbed in the HW,
      there won't be any change in tailroom_needed count on AP iface
    * Delayed decrement of tailroom_needed count on AP
      (AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)
    
    Because of the delayed decrement on AP iface, tailroom_needed count goes
    out of sync between AP(master iface) and AP_VLAN(slave iface) and
    there would be unnecessary tailroom created for the packets going
    through AP_VLAN iface.
    
    Also, WARN_ONs were observed while trying to bring down the AP_VLAN
    interface:
    (warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
    (warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4)
    (ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850)
    (ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c)
    (ieee80211_stop) (__dev_close_many+0x94/0xb8)
    (__dev_close_many) (dev_close_many+0x5c/0xc8)
    
    Restricting delayed decrement to station interface alone fixes the problem
    and it makes sense to do so because delayed decrement is done to improve
    roam time which is applicable only for client devices.
    Signed-off-by: default avatarManikanta Pubbisetty <mpubbise@codeaurora.org>
    Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    133bf90d
key.c 31.9 KB