2021-11-15 13:53:15

by Alain Michaud

[permalink] [raw]
Subject: [PATCH] Bluetooth: Fix adv set removal processing.

When multiple advertisement sets are active and a single instance is
removed, the processing of hci_cc_le_set_ext_adv_enable will result in
considering all advertisements as disabled since the instance has
already been removed from the list.

The fix is to use the command parameters to validate the intent rather
than making an assumption based on the validity of the adv set.

remove_advertising() hci0

hci_req_add_ev() hci0 opcode 0x2039 plen 6
hci_req_add_ev() hci0 opcode 0x203c plen 1

hci_remove_adv_instance() hci0 removing 2MR
<-- This removes instance 2 from the adv_instances list

hci_cc_le_set_ext_adv_enable() hci0 status 0x00
hci_sent_cmd_data() hci0 opcode 0x2039
hci_cc_le_set_ext_adv_enable() adv instance 0, enabled 0
<-- This incorrectly assumes that all instances are
being disabled while only handle 2 is being disabled.

hci_cc_le_set_ext_adv_enable() adv instance list status - before
hci_cc_le_set_ext_adv_enable() adv instance 3 is 1
hci_cc_le_set_ext_adv_enable() adv instance 1 is 1
hci_cc_le_set_ext_adv_enable() HCI_LE_ADV state before: 1
hci_cc_le_set_ext_adv_enable() adv instance list status - after
hci_cc_le_set_ext_adv_enable() adv instance 3 is 0
hci_cc_le_set_ext_adv_enable() adv instance 1 is 0
hci_cc_le_set_ext_adv_enable() HCI_LE_ADV state after: 0
<-- This is incorrect since handle 1 and 3 are still enabled
in the controller

The fix was validated by running the ChromeOS bluetooth_AdapterAdvHealth
test suite.

Reviewed-by: [email protected]
Signed-off-by: Alain Michaud <[email protected]>

---

net/bluetooth/hci_event.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index d4b75a6cfeee..52161d04136f 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1385,14 +1385,16 @@ static void hci_cc_le_set_ext_adv_enable(struct hci_dev *hdev,
if (adv->enabled)
goto unlock;
}
- } else {
+
+ hci_dev_clear_flag(hdev, HCI_LE_ADV);
+ } else if (!cp->num_of_sets || !set->handle) {
/* All instances shall be considered disabled */
list_for_each_entry_safe(adv, n, &hdev->adv_instances,
list)
adv->enabled = false;
- }

- hci_dev_clear_flag(hdev, HCI_LE_ADV);
+ hci_dev_clear_flag(hdev, HCI_LE_ADV);
+ }
}

unlock:
--
2.34.0.rc1.387.gb447b232ab-goog



2021-11-15 17:06:35

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [PATCH] Bluetooth: Fix adv set removal processing.

Hi Alain,

> When multiple advertisement sets are active and a single instance is
> removed, the processing of hci_cc_le_set_ext_adv_enable will result in
> considering all advertisements as disabled since the instance has
> already been removed from the list.
>
> The fix is to use the command parameters to validate the intent rather
> than making an assumption based on the validity of the adv set.
>
> remove_advertising() hci0
>
> hci_req_add_ev() hci0 opcode 0x2039 plen 6
> hci_req_add_ev() hci0 opcode 0x203c plen 1
>
> hci_remove_adv_instance() hci0 removing 2MR
> <-- This removes instance 2 from the adv_instances list
>
> hci_cc_le_set_ext_adv_enable() hci0 status 0x00
> hci_sent_cmd_data() hci0 opcode 0x2039
> hci_cc_le_set_ext_adv_enable() adv instance 0, enabled 0
> <-- This incorrectly assumes that all instances are
> being disabled while only handle 2 is being disabled.
>
> hci_cc_le_set_ext_adv_enable() adv instance list status - before
> hci_cc_le_set_ext_adv_enable() adv instance 3 is 1
> hci_cc_le_set_ext_adv_enable() adv instance 1 is 1
> hci_cc_le_set_ext_adv_enable() HCI_LE_ADV state before: 1
> hci_cc_le_set_ext_adv_enable() adv instance list status - after
> hci_cc_le_set_ext_adv_enable() adv instance 3 is 0
> hci_cc_le_set_ext_adv_enable() adv instance 1 is 0
> hci_cc_le_set_ext_adv_enable() HCI_LE_ADV state after: 0
> <-- This is incorrect since handle 1 and 3 are still enabled
> in the controller
>
> The fix was validated by running the ChromeOS bluetooth_AdapterAdvHealth
> test suite.
>
> Reviewed-by: [email protected]

we need clear name and email in the tags please. And I also like to have Fixes: tags here as well.

> Signed-off-by: Alain Michaud <[email protected]>
>
> ---
>
> net/bluetooth/hci_event.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index d4b75a6cfeee..52161d04136f 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1385,14 +1385,16 @@ static void hci_cc_le_set_ext_adv_enable(struct hci_dev *hdev,
> if (adv->enabled)
> goto unlock;
> }
> - } else {
> +
> + hci_dev_clear_flag(hdev, HCI_LE_ADV);
> + } else if (!cp->num_of_sets || !set->handle) {
> /* All instances shall be considered disabled */
> list_for_each_entry_safe(adv, n, &hdev->adv_instances,
> list)
> adv->enabled = false;
> - }
>
> - hci_dev_clear_flag(hdev, HCI_LE_ADV);
> + hci_dev_clear_flag(hdev, HCI_LE_ADV);
> + }
> }

Just checking if this wouldn’t be cleaner:

} else {
if (foo)
bar;

hci_dev_clear_flag(hdev, HCI_LE_ADV);
}

Regards

Marcel


2021-11-15 20:58:39

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: [PATCH] Bluetooth: Fix adv set removal processing.

Hi Alain,

On Mon, Nov 15, 2021 at 9:07 AM Marcel Holtmann <[email protected]> wrote:
>
> Hi Alain,
>
> > When multiple advertisement sets are active and a single instance is
> > removed, the processing of hci_cc_le_set_ext_adv_enable will result in
> > considering all advertisements as disabled since the instance has
> > already been removed from the list.
> >
> > The fix is to use the command parameters to validate the intent rather
> > than making an assumption based on the validity of the adv set.
> >
> > remove_advertising() hci0
> >
> > hci_req_add_ev() hci0 opcode 0x2039 plen 6
> > hci_req_add_ev() hci0 opcode 0x203c plen 1
> >
> > hci_remove_adv_instance() hci0 removing 2MR
> > <-- This removes instance 2 from the adv_instances list
> >
> > hci_cc_le_set_ext_adv_enable() hci0 status 0x00
> > hci_sent_cmd_data() hci0 opcode 0x2039
> > hci_cc_le_set_ext_adv_enable() adv instance 0, enabled 0
> > <-- This incorrectly assumes that all instances are
> > being disabled while only handle 2 is being disabled.
> >
> > hci_cc_le_set_ext_adv_enable() adv instance list status - before
> > hci_cc_le_set_ext_adv_enable() adv instance 3 is 1
> > hci_cc_le_set_ext_adv_enable() adv instance 1 is 1
> > hci_cc_le_set_ext_adv_enable() HCI_LE_ADV state before: 1
> > hci_cc_le_set_ext_adv_enable() adv instance list status - after
> > hci_cc_le_set_ext_adv_enable() adv instance 3 is 0
> > hci_cc_le_set_ext_adv_enable() adv instance 1 is 0
> > hci_cc_le_set_ext_adv_enable() HCI_LE_ADV state after: 0
> > <-- This is incorrect since handle 1 and 3 are still enabled
> > in the controller
> >
> > The fix was validated by running the ChromeOS bluetooth_AdapterAdvHealth
> > test suite.
> >
> > Reviewed-by: [email protected]
>
> we need clear name and email in the tags please. And I also like to have Fixes: tags here as well.
>
> > Signed-off-by: Alain Michaud <[email protected]>
> >
> > ---
> >
> > net/bluetooth/hci_event.c | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index d4b75a6cfeee..52161d04136f 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -1385,14 +1385,16 @@ static void hci_cc_le_set_ext_adv_enable(struct hci_dev *hdev,
> > if (adv->enabled)
> > goto unlock;
> > }
> > - } else {
> > +
> > + hci_dev_clear_flag(hdev, HCI_LE_ADV);
> > + } else if (!cp->num_of_sets || !set->handle) {
> > /* All instances shall be considered disabled */
> > list_for_each_entry_safe(adv, n, &hdev->adv_instances,
> > list)
> > adv->enabled = false;
> > - }
> >
> > - hci_dev_clear_flag(hdev, HCI_LE_ADV);
> > + hci_dev_clear_flag(hdev, HCI_LE_ADV);
> > + }
> > }
>
> Just checking if this wouldn’t be cleaner:
>
> } else {
> if (foo)
> bar;
>
> hci_dev_clear_flag(hdev, HCI_LE_ADV);
> }

Actually this seems to already have been fixed by:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2128939fe2e771645dd88e1938c27fdf96bd1cd0

Perhaps the Chrome OS tree is outdated?

> Regards
>
> Marcel
>


--
Luiz Augusto von Dentz

2021-11-16 20:50:24

by Alain Michaud

[permalink] [raw]
Subject: Re: [PATCH] Bluetooth: Fix adv set removal processing.

HI Luiz,



On Mon, Nov 15, 2021 at 2:35 PM Luiz Augusto von Dentz
<[email protected]> wrote:
>
> Hi Alain,
>
> On Mon, Nov 15, 2021 at 9:07 AM Marcel Holtmann <[email protected]> wrote:
> >
> > Hi Alain,
> >
> > > When multiple advertisement sets are active and a single instance is
> > > removed, the processing of hci_cc_le_set_ext_adv_enable will result in
> > > considering all advertisements as disabled since the instance has
> > > already been removed from the list.
> > >
> > > The fix is to use the command parameters to validate the intent rather
> > > than making an assumption based on the validity of the adv set.
> > >
> > > remove_advertising() hci0
> > >
> > > hci_req_add_ev() hci0 opcode 0x2039 plen 6
> > > hci_req_add_ev() hci0 opcode 0x203c plen 1
> > >
> > > hci_remove_adv_instance() hci0 removing 2MR
> > > <-- This removes instance 2 from the adv_instances list
> > >
> > > hci_cc_le_set_ext_adv_enable() hci0 status 0x00
> > > hci_sent_cmd_data() hci0 opcode 0x2039
> > > hci_cc_le_set_ext_adv_enable() adv instance 0, enabled 0
> > > <-- This incorrectly assumes that all instances are
> > > being disabled while only handle 2 is being disabled.
> > >
> > > hci_cc_le_set_ext_adv_enable() adv instance list status - before
> > > hci_cc_le_set_ext_adv_enable() adv instance 3 is 1
> > > hci_cc_le_set_ext_adv_enable() adv instance 1 is 1
> > > hci_cc_le_set_ext_adv_enable() HCI_LE_ADV state before: 1
> > > hci_cc_le_set_ext_adv_enable() adv instance list status - after
> > > hci_cc_le_set_ext_adv_enable() adv instance 3 is 0
> > > hci_cc_le_set_ext_adv_enable() adv instance 1 is 0
> > > hci_cc_le_set_ext_adv_enable() HCI_LE_ADV state after: 0
> > > <-- This is incorrect since handle 1 and 3 are still enabled
> > > in the controller
> > >
> > > The fix was validated by running the ChromeOS bluetooth_AdapterAdvHealth
> > > test suite.
> > >
> > > Reviewed-by: [email protected]
> >
> > we need clear name and email in the tags please. And I also like to have Fixes: tags here as well.
> >
> > > Signed-off-by: Alain Michaud <[email protected]>
> > >
> > > ---
> > >
> > > net/bluetooth/hci_event.c | 8 +++++---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > > index d4b75a6cfeee..52161d04136f 100644
> > > --- a/net/bluetooth/hci_event.c
> > > +++ b/net/bluetooth/hci_event.c
> > > @@ -1385,14 +1385,16 @@ static void hci_cc_le_set_ext_adv_enable(struct hci_dev *hdev,
> > > if (adv->enabled)
> > > goto unlock;
> > > }
> > > - } else {
> > > +
> > > + hci_dev_clear_flag(hdev, HCI_LE_ADV);
> > > + } else if (!cp->num_of_sets || !set->handle) {
> > > /* All instances shall be considered disabled */
> > > list_for_each_entry_safe(adv, n, &hdev->adv_instances,
> > > list)
> > > adv->enabled = false;
> > > - }
> > >
> > > - hci_dev_clear_flag(hdev, HCI_LE_ADV);
> > > + hci_dev_clear_flag(hdev, HCI_LE_ADV);
> > > + }
> > > }
> >
> > Just checking if this wouldn’t be cleaner:
> >
> > } else {
> > if (foo)
> > bar;
> >
> > hci_dev_clear_flag(hdev, HCI_LE_ADV);
> > }
>
> Actually this seems to already have been fixed by:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2128939fe2e771645dd88e1938c27fdf96bd1cd0
>
> Perhaps the Chrome OS tree is outdated?
You are right, looks like this would fix it and it was indeed not
merged to the chromium tree. Please ignore this patch.
>
> > Regards
> >
> > Marcel
> >
>
>
> --
> Luiz Augusto von Dentz