In response to the Read Index List command, it is possible that
uninitialized data is sent to userspace because the way the number
of adapters is counted. This way we only count adapters that will
be included in the response.
Signed-off-by: Vinicius Costa Gomes <[email protected]>
---
net/bluetooth/mgmt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 05d4b83..6219a39 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -333,6 +333,9 @@ static int read_index_list(struct sock *sk, struct hci_dev *hdev, void *data,
count = 0;
list_for_each_entry(d, &hci_dev_list, list) {
+ if (test_bit(HCI_SETUP, &d->dev_flags))
+ continue;
+
if (!mgmt_valid_hdev(d))
continue;
--
1.7.11.4
Hi Vinicius,
On Fri, Aug 24, 2012, Vinicius Costa Gomes wrote:
> With the HCI_SETUP patches, this is all that is needed to make the
> case when a adapter is added with Bluetooth blocked in rfkill to work.
>
> When rfkill is unblocked, the device will be powered on if the device
> is in HCI_SETUP state, meaning that it was never properly initialized.
> If the device is not used by userspace, the HCI_AUTO_OFF flag will
> take care of powering it off.
>
> Signed-off-by: Vinicius Costa Gomes <[email protected]>
> ---
> net/bluetooth/hci_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index fa974a1..ef69d8b 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1061,8 +1061,10 @@ static int hci_rfkill_set_block(void *data, bool blocked)
>
> BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
>
> - if (!blocked)
> + if (!blocked && test_bit(HCI_SETUP, &hdev->dev_flags)) {
> + schedule_work(&hdev->power_on);
> return 0;
> + }
>
> hci_dev_do_close(hdev);
This still isn't right. Now you'd be calling hci_dev_do_close() when
unblocking a device that doesn't have HCI_SETUP set. The test_bit needs
to be inside the if-branch. Btw, this all implies that you're not
properly testing your patches. Please always do that.
Johan
With the HCI_SETUP patches, this is all that is needed to make the
case when a adapter is added with Bluetooth blocked in rfkill to work.
When rfkill is unblocked, the device will be powered on if the device
is in HCI_SETUP state, meaning that it was never properly initialized.
If the device is not used by userspace, the HCI_AUTO_OFF flag will
take care of powering it off.
Signed-off-by: Vinicius Costa Gomes <[email protected]>
---
net/bluetooth/hci_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index fa974a1..ef69d8b 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1061,8 +1061,10 @@ static int hci_rfkill_set_block(void *data, bool blocked)
BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
- if (!blocked)
+ if (!blocked && test_bit(HCI_SETUP, &hdev->dev_flags)) {
+ schedule_work(&hdev->power_on);
return 0;
+ }
hci_dev_do_close(hdev);
--
1.7.12
Hi Johan,
On 15:28 Fri 24 Aug, Johan Hedberg wrote:
> Hi Vinicius,
>
> On Wed, Aug 22, 2012, Vinicius Costa Gomes wrote:
> > With the HCI_SETUP patches, this is all that is needed to make the
> > case when a adapter is added with Bluetooth blocked in rfkill to work.
> >
> > When rfkill is unblocked, the device will be powered on, and if not
> > needed it will be automatically powered off.
> >
> > Signed-off-by: Vinicius Costa Gomes <[email protected]>
> > ---
> > net/bluetooth/hci_core.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index fa974a1..395dcc6 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -1061,8 +1061,10 @@ static int hci_rfkill_set_block(void *data, bool blocked)
> >
> > BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
> >
> > - if (!blocked)
> > + if (!blocked) {
> > + schedule_work(&hdev->power_on);
>
> Don't you need to check for HCI_SETUP before calling schedule_work here?
> It should be possible to have an adapter powered off and toggling rfkill
> back and forth shouldn't cause it to be powered on.
Most probably. Nice catch. Thanks.
I am going to try it and see if it doesn't have any unexpected side effects.
Cheers,
--
Vinicius
Hi Vinicius,
On Wed, Aug 22, 2012, Vinicius Costa Gomes wrote:
> With the HCI_SETUP patches, this is all that is needed to make the
> case when a adapter is added with Bluetooth blocked in rfkill to work.
>
> When rfkill is unblocked, the device will be powered on, and if not
> needed it will be automatically powered off.
>
> Signed-off-by: Vinicius Costa Gomes <[email protected]>
> ---
> net/bluetooth/hci_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index fa974a1..395dcc6 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1061,8 +1061,10 @@ static int hci_rfkill_set_block(void *data, bool blocked)
>
> BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
>
> - if (!blocked)
> + if (!blocked) {
> + schedule_work(&hdev->power_on);
Don't you need to check for HCI_SETUP before calling schedule_work here?
It should be possible to have an adapter powered off and toggling rfkill
back and forth shouldn't cause it to be powered on.
Johan
With the HCI_SETUP patches, this is all that is needed to make the
case when a adapter is added with Bluetooth blocked in rfkill to work.
When rfkill is unblocked, the device will be powered on, and if not
needed it will be automatically powered off.
Signed-off-by: Vinicius Costa Gomes <[email protected]>
---
net/bluetooth/hci_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index fa974a1..395dcc6 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1061,8 +1061,10 @@ static int hci_rfkill_set_block(void *data, bool blocked)
BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
- if (!blocked)
+ if (!blocked) {
+ schedule_work(&hdev->power_on);
return 0;
+ }
hci_dev_do_close(hdev);
--
1.7.11.4