All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Daniel Winkler <danielwinkler@google.com>
Cc: linux-bluetooth <linux-bluetooth@vger.kernel.org>,
	CrosBT Upstreaming <chromeos-bluetooth-upstreaming@chromium.org>,
	Miao-chen Chou <mcchou@chromium.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: Always call advertising disable before setting params
Date: Wed, 24 Mar 2021 08:06:32 +0100	[thread overview]
Message-ID: <8E70C497-BDCE-471F-9ECD-790E2FE3B024@holtmann.org> (raw)
In-Reply-To: <20210323141653.1.I53e6be1f7df0be198b7e55ae9fc45c7f5760132d@changeid>

Hi Daniel,

> In __hci_req_enable_advertising, the HCI_LE_ADV hdev flag is temporarily
> cleared to allow the random address to be set, which exposes a race
> condition when an advertisement is configured immediately (<10ms) after
> software rotation starts to refresh an advertisement.
> 
> In normal operation, the HCI_LE_ADV flag is updated as follows:
> 
> 1. adv_timeout_expire is called, HCI_LE_ADV gets cleared in
>   __hci_req_enable_advertising, but hci_req configures an enable
>   request
> 2. hci_req is run, enable callback re-sets HCI_LE_ADV flag
> 
> However, in this race condition, the following occurs:
> 
> 1. adv_timeout_expire is called, HCI_LE_ADV gets cleared in
>   __hci_req_enable_advertising, but hci_req configures an enable
>   request
> 2. add_advertising is called, which also calls
>   __hci_req_enable_advertising. Because HCI_LE_ADV was cleared in Step
>   1, no "disable" command is queued.
> 3. hci_req for adv_timeout_expire is run, which enables advertising and
>   re-sets HCI_LE_ADV
> 4. hci_req for add_advertising is run, but because no "disable" command
>   was queued, we try to set advertising parameters while advertising is
>   active, causing a Command Disallowed error, failing the registration.
> 
> To resolve the issue, this patch removes the check for the HCI_LE_ADV
> flag, and always queues the "disable" request, since HCI_LE_ADV could be
> very temporarily out-of-sync. According to the spec, there is no harm in
> calling "disable" when advertising is not active.
> 
> Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
> Signed-off-by: Daniel Winkler <danielwinkler@google.com>
> ---
> 
> net/bluetooth/hci_request.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
> index 8ace5d34b01efe..2b4b99f4cedf21 100644
> --- a/net/bluetooth/hci_request.c
> +++ b/net/bluetooth/hci_request.c
> @@ -1547,8 +1547,10 @@ void __hci_req_enable_advertising(struct hci_request *req)
> 	if (!is_advertising_allowed(hdev, connectable))
> 		return;
> 
> -	if (hci_dev_test_flag(hdev, HCI_LE_ADV))
> -		__hci_req_disable_advertising(req);
> +	/* Request that the controller stop advertising. This can be called
> +	 * whether or not there is an active advertisement.
> +	 */
> +	__hci_req_disable_advertising(req);

can you include a btmon trace that shows that we don’t get a HCI error. Since if we get one, then the complete request will fail. And that has further side effects.

Regards

Marcel


  reply	other threads:[~2021-03-24  7:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-23 21:18 [PATCH] Bluetooth: Always call advertising disable before setting params Daniel Winkler
2021-03-24  7:06 ` Marcel Holtmann [this message]
2021-03-24 18:49   ` Daniel Winkler

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=8E70C497-BDCE-471F-9ECD-790E2FE3B024@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=chromeos-bluetooth-upstreaming@chromium.org \
    --cc=danielwinkler@google.com \
    --cc=davem@davemloft.net \
    --cc=johan.hedberg@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=mcchou@chromium.org \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.