public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Fedor Pchelkin <pchelkin@ispras.ru>
To: Hillf Danton <hdanton@sina.com>
Cc: "Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Kalle Vallo" <kvalo@kernel.org>,
	syzbot+f2cb6e0ffdb961921e4d@syzkaller.appspotmail.com,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Alexey Khoroshilov" <khoroshilov@ispras.ru>,
	lvc-project@linuxtesting.org
Subject: Re: [PATCH v3 1/2] wifi: ath9k: fix races between ath9k_wmi_cmd and ath9k_wmi_ctrl_rx
Date: Wed, 26 Apr 2023 22:02:06 +0300	[thread overview]
Message-ID: <20230426190206.ni2au5mpjc5oty67@fpc> (raw)
In-Reply-To: <20230425230708.2132-1-hdanton@sina.com>

On Wed, Apr 26, 2023 at 07:07:08AM +0800, Hillf Danton wrote: 
> Given similar wait timeout[1], just taking lock on the waiter side is not
> enough wrt fixing the race, because in case job done on the waker side,
> waiter needs to wait again after timeout.
> 

As I understand you correctly, you mean the case when a timeout occurs
during ath9k_wmi_ctrl_rx() callback execution. I suppose if a timeout has
occurred on a waiter's side, it should return immediately and doesn't have
to care in which state the callback has been at that moment.

AFAICS, this is controlled properly with taking a wmi_lock on waiter and
waker sides, and there is no data corruption.

If a callback has not managed to do its work entirely (performing a
completion and subsequently waking waiting thread is included here), then,
well, it is considered a timeout, in my opinion.

Your suggestion makes a wmi_cmd call to give a little more chance for the
belated callback to complete (although timeout has actually expired). That
is probably good, but increasing a timeout value makes that job, too. I
don't think it makes any sense on real hardware.

Or do you mean there is data corruption that is properly fixed with your
patch?

That is, I agree there can be a situation when a callback makes all the
logical work it should and it just hasn't got enough time to perform a
completion before a timeout on waiter's side occurs. And this behaviour
can be named "racy". But, technically, this seems to be a rather valid
timeout.

> [1] https://lore.kernel.org/lkml/9d9b9652-c1ac-58e9-2eab-9256c17b1da2@I-love.SAKURA.ne.jp/
> 

I don't think it's a similar case because wait_for_completion_state() is
interruptible while wait_for_completion_timeout() is not.

> A correct fix looks like after putting pieces together
> 
> +++ b/drivers/net/wireless/ath/ath9k/wmi.c
> @@ -238,6 +238,7 @@ static void ath9k_wmi_ctrl_rx(void *priv
>  		spin_unlock_irqrestore(&wmi->wmi_lock, flags);
>  		goto free_skb;
>  	}
> +	wmi->last_seq_id = 0;
>  	spin_unlock_irqrestore(&wmi->wmi_lock, flags);
>  
>  	/* WMI command response */
> @@ -339,9 +340,20 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum
>  
>  	time_left = wait_for_completion_timeout(&wmi->cmd_wait, timeout);
>  	if (!time_left) {
> +		unsigned long flags;
> +		int wait = 0;
> +
>  		ath_dbg(common, WMI, "Timeout waiting for WMI command: %s\n",
>  			wmi_cmd_to_name(cmd_id));
> -		wmi->last_seq_id = 0;
> +
> +		spin_lock_irqsave(&wmi->wmi_lock, flags);
> +		if (wmi->last_seq_id == 0) /* job done on the waker side? */
> +			wait = 1;
> +		else
> +			wmi->last_seq_id = 0;
> +		spin_unlock_irqrestore(&wmi->wmi_lock, flags);
> +		if (wait)
> +			wait_for_completion(&wmi->cmd_wait);
>  		mutex_unlock(&wmi->op_mutex);
>  		return -ETIMEDOUT;
>  	}

  parent reply	other threads:[~2023-04-26 19:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-15 20:21 [PATCH 0/3] wifi: ath9k: deal with uninit memory Fedor Pchelkin
2023-03-15 20:21 ` [PATCH 1/3] wifi: ath9k: avoid referencing uninit memory in ath9k_wmi_ctrl_rx Fedor Pchelkin
2023-03-17  5:26   ` Kalle Valo
2023-03-18 20:25     ` Fedor Pchelkin
2023-04-24 18:23   ` Fedor Pchelkin
2023-04-24 18:33     ` [PATCH v2] " Fedor Pchelkin
2023-04-25 11:14       ` Toke Høiland-Jørgensen
2023-04-28 16:52       ` Kalle Valo
2023-03-15 20:21 ` [PATCH 2/3] wifi: ath9k: fix races between ath9k_wmi_cmd and ath9k_wmi_ctrl_rx Fedor Pchelkin
2023-04-24 19:11   ` Fedor Pchelkin
2023-04-24 19:18     ` [PATCH v2] " Fedor Pchelkin
     [not found]       ` <20230425033832.2041-1-hdanton@sina.com>
2023-04-25  7:54         ` Fedor Pchelkin
2023-04-25 19:26         ` [PATCH v3 1/2] " Fedor Pchelkin
2023-04-25 19:26           ` [PATCH v3 2/2] wifi: ath9k: protect WMI command response buffer replacement with a lock Fedor Pchelkin
2023-08-08 14:07             ` Toke Høiland-Jørgensen
     [not found]           ` <20230425230708.2132-1-hdanton@sina.com>
2023-04-26 19:02             ` Fedor Pchelkin [this message]
2023-05-15 12:06               ` [PATCH v3 1/2] wifi: ath9k: fix races between ath9k_wmi_cmd and ath9k_wmi_ctrl_rx Toke Høiland-Jørgensen
2023-05-18 10:24               ` Hillf Danton
2023-05-18 15:44                 ` Fedor Pchelkin
2023-08-08 14:06           ` Toke Høiland-Jørgensen
2023-08-22 13:35           ` Kalle Valo
2023-03-15 20:21 ` [PATCH 3/3] wifi: ath9k: fix ath9k_wmi_cmd return value when device is unplugged Fedor Pchelkin
2023-03-15 20:47 ` [PATCH 0/3] wifi: ath9k: deal with uninit memory Fedor Pchelkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230426190206.ni2au5mpjc5oty67@fpc \
    --to=pchelkin@ispras.ru \
    --cc=hdanton@sina.com \
    --cc=khoroshilov@ispras.ru \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lvc-project@linuxtesting.org \
    --cc=netdev@vger.kernel.org \
    --cc=syzbot+f2cb6e0ffdb961921e4d@syzkaller.appspotmail.com \
    --cc=toke@toke.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox