wil6210: drop old event after wmi_call timeout

This change fixes a rare race condition of handling WMI events after
wmi_call expires.

wmi_recv_cmd immediately handles an event when reply_buf is defined and
a wmi_call is waiting for the event.
However, in case the wmi_call has already timed-out, there will be no
waiting/running wmi_call and the event will be queued in WMI queue and
will be handled later in wmi_event_handle.
Meanwhile, a new similar wmi_call for the same command and event may
be issued. In this case, when handling the queued event we got WARN_ON
printed.

Fixing this case as a valid timeout and drop the unexpected event.

Signed-off-by: Ahmad Masri <amasri@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This commit is contained in:
Ahmad Masri 2019-06-16 10:26:07 +03:00 committed by Kalle Valo
parent 2a32c20b76
commit 1a27600311
1 changed files with 12 additions and 1 deletions

View File

@ -3303,7 +3303,18 @@ static void wmi_event_handle(struct wil6210_priv *wil,
/* check if someone waits for this event */
if (wil->reply_id && wil->reply_id == id &&
wil->reply_mid == mid) {
WARN_ON(wil->reply_buf);
if (wil->reply_buf) {
/* event received while wmi_call is waiting
* with a buffer. Such event should be handled
* in wmi_recv_cmd function. Handling the event
* here means a previous wmi_call was timeout.
* Drop the event and do not handle it.
*/
wil_err(wil,
"Old event (%d, %s) while wmi_call is waiting. Drop it and Continue waiting\n",
id, eventid2name(id));
return;
}
wmi_evt_call_handler(vif, id, evt_data,
len - sizeof(*wmi));