mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-11 07:03:09 -04:00
No description
- C 98.2%
- Assembly 1%
- Makefile 0.3%
- Shell 0.2%
- Python 0.1%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
65e8c1c219
A race condition can happen when roaming state machine
transition takes place in the following sequence:
1) FW indicates 'roam_synch' event to driver, and driver in
turn, advances its roaming state machine to
'WLAN_ROAM_SYNCH_IN_PROG', in wlan scheduler context;
2) HDD layer starts to do 'disconnect'(could be due to NUD
failure), and thus needs to stop roaming scan offload in
the following sequence:
2.1) Post a RSO stop cmd to FW, via the scheduler thread;
2.2) Advance the roaming state machine to a new state of
'WLAN_ROAM_RSO_STOPPED';
2.3) Check if:
>> the roaming state machine is still in a state of
'WLAN_ROAM_SYNCH_IN_PROG'
>> the neighbor roaming state is in any of the states
below:
eCSR_NEIGHBOR_ROAM_STATE_REASSOCIATING;
eCSR_NEIGHBOR_ROAM_STATE_PREAUTHENTICATING;
eCSR_NEIGHBOR_ROAM_STATE_PREAUTH_DONE;
Here, if any of the conditions becomes true, then
HDD will wait for 4 sec to let the roam_synch handler
finish its job, otherwise the wait will not happen.
2.4) Disconnect the current vdev and advance the roaming
state machine to 'WLAN_ROAM_DEINIT';
In a corner case, race condition can happen in the following
sequence:
>> thread 1), which executes in wlan scheduler context, starts
to run first, and thus roaming state machine advances to
'WLAN_ROAM_SYNCH_IN_PROG', but then gets preempted before
starting to parse the assoc resp frame attached in the
roam_synch event;
>> thread 2) starts to run and posts RSO stop cmd, but the req
msg cannot be handled right away due to scheduler thread
is actively running with other tasks, so it gets queued at
step 2.1);
>> thread 2) continues to run, and simply advances the roaming
state machine to 'WLAN_ROAM_RSO_STOPPED' at 2.2), and then
it will find out none of the conditions listed in 2.3) is
true, so it choses NOT to wait for 'roam_synch' handler to
finish;
>> thread 2) reaches to step 2.4) without waiting at 2.3), and
roaming state machine advances to 'WLAN_ROAM_DEINIT';
>> thread 1) continues to run and starts to parse the assoc
resp frame indicated by FW, and finds that the roaming state
machine NOT in 'WLAN_ROAM_SYNCH_IN_PROG', and thus goes to
the wrong way to treat the buffer in a different manner,
causing a invalid pointer access here.
Fix the racing condition by checking if the roaming state machine
is in 'WLAN_ROAM_SYNCH_IN_PROG' before advancing the same to
'WLAN_ROAM_RSO_STOPPED' in function wlan_hdd_wait_for_roaming().
Change-Id: I202ccb371e9e70a76ef35938c700b60c91b7d3cb
CRs-Fixed: 2761880
|
||
| components | ||
| configs | ||
| core | ||
| os_if | ||
| uapi/linux | ||
| Android.mk | ||
| Kbuild | ||
| Kconfig | ||
| Makefile | ||
| README.txt | ||
This is CNSS WLAN Host Driver for products starting from iHelium