There is a bug in the driver that causes an oops when a vap is destroyed and recreated with the same settings, provided that there is a remote host sending packets to the device before and after it is destroyed and recreated.
The bug occurs because a mapping in the driver is not correctly cleared when a VAP is destroyed. When the vap is recreated the first incoming packet is handled using the mapping which now contains a stale record pointing to an invalid VAP structure. When ieee80211_input tries to dereference this vap structure an oops occurs as shown in the first attachment.
The mapping in question is called sc_keyixmap and is meant to be cleared when a node is removed via the ath_key_delete routine which is called from the vap via the iv_key_delete method. This routine is meant to be triggered as the node objects are destroyed in the vap detach code starting in ieee80211_node_vdetach, however a reference counting error means that the nodes are never actually destroyed and hence ath_key_delete is never called to remove the entry from the mapping.
The reference counting error occurs due to the mapping itself, when it is setup in ath_rx_tasklet (line 5589) it takes another reference to the node object. This reference is still held when the ieee80211_node_vdetach routine calls ieee80211_node_table_reset to free all node entries related to the vap. ieee80211_node_table_reset uses node_reclaim to attempt to remove the node, however this function never completes because of the reference held by the mapping. Because the mapping relies on the node object being deleted (and hence ath_key_delete being called) to be cleaned up, we end up in a situation where the node object is never removed and the mapping becomes stale when the VAP is recreated.
The solution is call _ieee80211_free_node instead of node_reclaim to remove the node entry. This begins the node removal process, ignoring the reference held by the mapping, and eventually ath_key_delete is called to clean things up properly. No other parts of the code should be holding a reference to the node at this time.
A patch is attached to implement this behaviour.
Ticket #222 is almost certainly a duplicate of this bug and will be fixed with the attached patch, the oops provided is different however, so I cannot verify 100% that it is the same issue.
Tickets #656 and #733 also sound very similar and should be checked after this patch has been applied to see if they are fixed too.
Signed-Off-By: Matt Brown <matt@mattb.net.nz>
