Currently if SSR happens and at the same time if driver gets
del virtual interface which is a vdev transition, it bloks
this vdev transition and queues into dsc queue assuming that
it will execute once SSR completes.
There is an issue with above assumption,
del virtual interface comes with rtnl lock held which may lead
for other processes to misbehave which are waiting for rtnl lock.
in current case kernel is waiting for rtnl lock to send
shutdown to driver as part of the SSR and this rtnl lock is held
by del virtual interface which is waiting inside dsc queue for
SSR to complete, this leads to the deadlock.
To address above issue, do not insert the vdev transintion in
dsc queue in case of SSR and return the failure instead.
Change-Id: I19c897d68086d885f340d35c686badb70601076a
CRs-Fixed: 2730903
Presently in case there is an interface down during SSR, the request is
rejected outright. This causes the driver and the userspace to go out of
sync on the status of that particular interface.
The root cause of this issue is that while SSR is ongoing if interface
down comes, the DSC control via __dsc_vdev_can_trans rejects the interface
down citing QDF_STATUS_E_INVAL. This prevents the request to be queued and
processed later.
To fix this remove the check for driver recovering from the DSC control.
Change-Id: I9598c4606984f924d63e8c459ded0520d0824d08
CRs-Fixed: 2658597
Previously vdev trans will be rejected if psoc in trans. but
it causes issue when __hdd_psoc_idle_shutdown is in psoc trans,
if ifconfig comes here, the ifconfig will fail.
Add checking if psoc trans in driver recovering and unloading,
if yes, it will be safe to reject vdev trans, otherwise, we should
let vdev trans waiting for psoc trans.
At the same time, we also need to make sure driver state has been
set before psoc trans when unloading.
Change-Id: Ic47eebef76b8eadc90780b74f75d4ebef73b822d
CRs-Fixed: 2601435
Issue happen when:
thread1:
rmmod driver, wlan_hdd_pld_remove which will get psoc trans.
then try to get rntl_lock in hdd_unregister_wext;
thread2:
trigger iw del interface, cfgops in kernel will get get rtnl_lock,
in wlan_hdd_del_virtual_intf, vdev trans will be blocked by psoc
trans in thread1. as thread1 it is also waiting for rtnl_lock, so
both thread will be stuck.
Fix is:
In psoc trans, vdev trans and vdev ops is not allowed, which should
return directly.
Change-Id: I9cbd04bac438bb9483b4e89e73801fe71859e139
CRs-Fixed: 2583675
The driver currently waits for driver transitions (loading/unloading)
to complete before allowing a psoc or vdev level transition/operation.
This can lead to race conditions if the driver acquires rtnl lock as a part
of the operation and simultaneously a driver transition is invoked.
One such scenario occurs if delete virtual interface is invoked in parallel
to rmmod. The timing of the calls can be such that the delete interface is
waiting on DSC queue to complete after rmmod while the rmmod is waiting on
the rtnl lock to be freed by the delete interface resulting in a scenario
where the threads are waiting on the other to complete.
* Thread B - Invokes rmmod and context switch happens before rtnl lock is
taken
* Thread A - Takes rtnl lock and invokes iw dev wlan0 del
- Context switch after entering wlan_hdd_del_virtual_intf
before osif_vdev_sync_trans_start_wait
* Thread B - Waits for rtnl lock to be released by Thread A
* Thread A - Waits for driver transition to be completed by Thread B
To avoid this possible scenario, modify the infrastructure such that any
down the tree transitions/operations are rejected if a driver transition
is taking place instead of waiting. Also, modify the corresponding tests
in the DSC unit test framework to correctly verify the changes made.
Change-Id: I61715c8fc2df33fd2deb46389da0375e4df5080c
CRs-Fixed: 2475386
Currently, the Driver Synchronization Core (DSC) blocks transitions
up-tree and down-tree from a node currently undergoing a transition, but
only rejects operations down-tree from the current node. Instead, reject
new operations both up-tree and down-tree from the current node under
transition. This provides more forgiving safety guarantees to operation
implementations at the cost of a reduced amount of parallelism that can
be achieved.
Change-Id: I09e1c48f7030a2252380d172c1c00ee22eac39c5
CRs-Fixed: 2421786
A common pattern in WLAN to panic the driver is to log the reason and
then unconditionally panic. QDF_DEBUG_PANIC() takes a reason string to
help make the reason for the panic more obvious, but it is not always
used. Ensure all callers of QDF_DEBUG_PANIC() provide a reason string.
Change-Id: I3d23a8980adaeaa1a9798a4a6b0fba1f36eb52ad
CRs-Fixed: 2403829
Very occasionally, the driver transition thread for the DSC race
condition unit test can be preempted before queuing the driver
transition. This leads to the transitions de-queuing in an unexpected
order, causing the test to fail. In order to close the race window, a
thread would have to set its event _after_ blocking on a pending
transition, which is impossible. So, rather than using events to
synchronize the different threads in this test case, use polling to
ensure the different transitions are queued in the appropriate order.
If the given condition is not met, call schedule() to give the other
threads a greater chance to run.
Change-Id: I05edfa9200ca7831926153f3ff0ec9dbbbab3fed
CRs-Fixed: 2378469
Convert the current hard-coded list of unit-test callbacks in
hdd_we_unit_test() to a vtable. This streamlines future additions.
Change-Id: I216bbb6699ae50eaa96ac559999cb42ba080867c
CRs-Fixed: 2358606
In order to catch and debug long running transitions, add a watchdog
timer to Driver Synchronization Core (DSC) transition start/stop call
pairs. If the timer expires, panic the driver for offline debugging.
Change-Id: I9b64fdb9cc20e1225394702d58b24db92a2d67e1
CRs-Fixed: 2328596
The Driver Synchronization Core (DSC) is a set of synchronization
primitives for use by the driver's orchestration layer. It provides APIs
for ensuring safe state transitions (including bring up and tear down)
of major driver objects: a single driver, associated psocs, and their
associated vdevs.
APIs are divided into two categories: mutual exclusion of conflicting
transitions, and operation tracking, blocking, and waiting capabilities.
For part 5, add the unit test implementations.
Change-Id: Ia68d6df18894b254c1f5fe3855d896e96be38a90
CRs-Fixed: 2290260
The Driver Synchronization Core (DSC) is a set of synchronization
primitives for use by the driver's orchestration layer. It provides APIs
for ensuring safe state transitions (including bring up and tear down)
of major driver objects: a single driver, associated psocs, and their
associated vdevs.
APIs are divided into two categories: mutual exclusion of conflicting
transitions, and operation tracking, blocking, and waiting capabilities.
For part 1, add common infrastructure and headers.
Change-Id: Id290e66d2dccd28b89fed5f285d3692ff3c814e7
CRs-Fixed: 2290260
