* [PATCH] Bluetooth: Fix adv set removal processing.
@ 2021-11-15 13:51 Alain Michaud
2021-11-15 17:05 ` Marcel Holtmann
0 siblings, 1 reply; 4+ messages in thread
From: Alain Michaud @ 2021-11-15 13:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Alain Michaud, mcchou
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: mcchou@chromium.org
Signed-off-by: Alain Michaud <alainm@chromium.org>
---
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
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] Bluetooth: Fix adv set removal processing.
2021-11-15 13:51 [PATCH] Bluetooth: Fix adv set removal processing Alain Michaud
@ 2021-11-15 17:05 ` Marcel Holtmann
2021-11-15 19:35 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 4+ messages in thread
From: Marcel Holtmann @ 2021-11-15 17:05 UTC (permalink / raw)
To: Alain Michaud; +Cc: linux-bluetooth, mcchou
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: mcchou@chromium.org
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 <alainm@chromium.org>
>
> ---
>
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] Bluetooth: Fix adv set removal processing.
2021-11-15 17:05 ` Marcel Holtmann
@ 2021-11-15 19:35 ` Luiz Augusto von Dentz
2021-11-16 20:49 ` Alain Michaud
0 siblings, 1 reply; 4+ messages in thread
From: Luiz Augusto von Dentz @ 2021-11-15 19:35 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Alain Michaud, linux-bluetooth, Miao-chen Chou
Hi Alain,
On Mon, Nov 15, 2021 at 9:07 AM Marcel Holtmann <marcel@holtmann.org> 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: mcchou@chromium.org
>
> 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 <alainm@chromium.org>
> >
> > ---
> >
> > 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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] Bluetooth: Fix adv set removal processing.
2021-11-15 19:35 ` Luiz Augusto von Dentz
@ 2021-11-16 20:49 ` Alain Michaud
0 siblings, 0 replies; 4+ messages in thread
From: Alain Michaud @ 2021-11-16 20:49 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Alain Michaud, linux-bluetooth, Miao-chen Chou
HI Luiz,
On Mon, Nov 15, 2021 at 2:35 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Alain,
>
> On Mon, Nov 15, 2021 at 9:07 AM Marcel Holtmann <marcel@holtmann.org> 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: mcchou@chromium.org
> >
> > 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 <alainm@chromium.org>
> > >
> > > ---
> > >
> > > 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-11-16 20:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-15 13:51 [PATCH] Bluetooth: Fix adv set removal processing Alain Michaud
2021-11-15 17:05 ` Marcel Holtmann
2021-11-15 19:35 ` Luiz Augusto von Dentz
2021-11-16 20:49 ` Alain Michaud
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.