OpenWiFi periodically (typically 120 seconds) issues nl80211

[venkatchimata]

call to get associated client list from the AP. The associated client list was protected by a mutex lock. Somehow it was causing tx/rx issues sometimes, speciically there was jitter in the video calls. Changing the lock to rcu_read lock from mutex. This resolved the jitter issue.

Tested thoroughly with the following procedure.

1. Connect 3 clients
2. A script running dumping clients in an infinite loop
3. Continuously disconnect / connect one client to see if there is any crash. No crash was observed.

Signed-off-by: Venkat Chimata [email protected]

[greearb]

Testing locking races is very difficult to do with great confidence, do you have reason to believe that an rcu read lock is actually sufficient? I think at the least the patch should go to the linux-wireless mailing list for review by Johannes and others.

[venkatchimata]

I see in other places say tx.c where the sta list is protected by rcu read lock. Thought we could use it here too.

[venkatchimata]

Adding the comment that I sent to upstream:

wifi: mac80211: Fix performance issue with mutex_lock

OpenWiFi's ucentral agent periodically (typically 120 seconds) issues nl80211 call to get associated client list from the WLAN driver. Somehow this operation was causing tx/rx delays sometimes and the video calls on connected clients are experiencing jitter. The associated client list was protected by a mutex lock. I saw that ieee80211_check_fast_xmit_all uses rcu_read_lock and rcu_read_unlock to iterate through sta_list. I took it as a refernce and changed the lock to rcu_read lock from mutex. Also saw this this comment just above sta_mutex declaration. /* Station data / / * The mutex only protects the list, hash table and * counter, reads are done with RCU. */ struct mutex sta_mtx;

Hence tried changing mutex_lock(/unlock) in ieee80211_dump_station to rcu_read_lock(/unlock) and it resolved the jitter issue in the video calls.

Tests: We had this issue show up consistently and the patch fixed the issue. We spent a good part of 2 weeks following up on this and with this fix, the video calls are smooth.

Also tested if this could cause any crashes with below mentioned process.

1. Connect 3 clients
2. A script running dumping clients in an infinite loop
3. Continuously disconnect / connect one client to see if there is any crash. No crash was observed.