An error occurred fetching the project authors.
  1. 21 Sep, 2022 1 commit
  2. 19 Sep, 2022 1 commit
  3. 06 Sep, 2022 1 commit
    • Brian Gix's avatar
      Bluetooth: Implement support for Mesh · b338d917
      Brian Gix authored
      The patch adds state bits, storage and HCI command chains for sending
      and receiving Bluetooth Mesh advertising packets, and delivery to
      requesting user space processes. It specifically creates 4 new MGMT
      commands and 2 new MGMT events:
      
      MGMT_OP_SET_MESH_RECEIVER - Sets passive scan parameters and a list of
      AD Types which will trigger Mesh Packet Received events
      
      MGMT_OP_MESH_READ_FEATURES - Returns information on how many outbound
      Mesh packets can be simultaneously queued, and what the currently queued
      handles are.
      
      MGMT_OP_MESH_SEND - Command to queue a specific outbound Mesh packet,
      with the number of times it should be sent, and the BD Addr to use.
      Discrete advertisments are added to the ADV Instance list.
      
      MGMT_OP_MESH_SEND_CANCEL - Command to cancel a prior outbound message
      request.
      
      MGMT_EV_MESH_DEVICE_FOUND - Event to deliver entire received Mesh
      Advertisement packet, along with timing information.
      
      MGMT_EV_MESH_PACKET_CMPLT - Event to indicate that an outbound packet is
      no longer queued for delivery.
      Signed-off-by: default avatarBrian Gix <brian.gix@intel.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      b338d917
  4. 31 Aug, 2022 1 commit
  5. 25 Aug, 2022 5 commits
    • Archie Pusaka's avatar
      Bluetooth: hci_event: Fix checking conn for le_conn_complete_evt · f48735a9
      Archie Pusaka authored
      To prevent multiple conn complete events, we shouldn't look up the
      conn with hci_lookup_le_connect, since it requires the state to be
      BT_CONNECT. By the time the duplicate event is processed, the state
      might have changed, so we end up processing the new event anyway.
      
      Change the lookup function to hci_conn_hash_lookup_ba.
      
      Fixes: d5ebaa7c ("Bluetooth: hci_event: Ignore multiple conn complete events")
      Signed-off-by: default avatarArchie Pusaka <apusaka@chromium.org>
      Reviewed-by: default avatarSonny Sasaka <sonnysasaka@chromium.org>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      f48735a9
    • Hans de Goede's avatar
      Bluetooth: hci_event: Fix vendor (unknown) opcode status handling · b82a26d8
      Hans de Goede authored
      Commit c8992cff ("Bluetooth: hci_event: Use of a function table to
      handle Command Complete") was (presumably) meant to only refactor things
      without any functional changes.
      
      But it does have one undesirable side-effect, before *status would always
      be set to skb->data[0] and it might be overridden by some of the opcode
      specific handling. While now it always set by the opcode specific handlers.
      This means that if the opcode is not known *status does not get set any
      more at all!
      
      This behavior change has broken bluetooth support for BCM4343A0 HCIs,
      the hci_bcm.c code tries to configure UART attached HCIs at a higher
      baudraute using vendor specific opcodes. The BCM4343A0 does not
      support this and this used to simply fail:
      
      [   25.646442] Bluetooth: hci0: BCM: failed to write clock (-56)
      [   25.646481] Bluetooth: hci0: Failed to set baudrate
      
      After which things would continue with the initial baudraute. But now
      that hci_cmd_complete_evt() no longer sets status for unknown opcodes
      *status is left at 0. This causes the hci_bcm.c code to think the baudraute
      has been changed on the HCI side and to also adjust the UART baudrate,
      after which communication with the HCI is broken, leading to:
      
      [   28.579042] Bluetooth: hci0: command 0x0c03 tx timeout
      [   36.961601] Bluetooth: hci0: BCM: Reset failed (-110)
      
      And non working bluetooth. Fix this by restoring the previous
      default "*status = skb->data[0]" handling for unknown opcodes.
      
      Fixes: c8992cff ("Bluetooth: hci_event: Use of a function table to handle Command Complete")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      b82a26d8
    • Archie Pusaka's avatar
      Bluetooth: hci_event: Fix checking conn for le_conn_complete_evt · 53562665
      Archie Pusaka authored
      To prevent multiple conn complete events, we shouldn't look up the
      conn with hci_lookup_le_connect, since it requires the state to be
      BT_CONNECT. By the time the duplicate event is processed, the state
      might have changed, so we end up processing the new event anyway.
      
      Change the lookup function to hci_conn_hash_lookup_ba.
      
      Fixes: d5ebaa7c ("Bluetooth: hci_event: Ignore multiple conn complete events")
      Signed-off-by: default avatarArchie Pusaka <apusaka@chromium.org>
      Reviewed-by: default avatarSonny Sasaka <sonnysasaka@chromium.org>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      53562665
    • Hans de Goede's avatar
      Bluetooth: hci_event: Fix vendor (unknown) opcode status handling · afcb3369
      Hans de Goede authored
      Commit c8992cff ("Bluetooth: hci_event: Use of a function table to
      handle Command Complete") was (presumably) meant to only refactor things
      without any functional changes.
      
      But it does have one undesirable side-effect, before *status would always
      be set to skb->data[0] and it might be overridden by some of the opcode
      specific handling. While now it always set by the opcode specific handlers.
      This means that if the opcode is not known *status does not get set any
      more at all!
      
      This behavior change has broken bluetooth support for BCM4343A0 HCIs,
      the hci_bcm.c code tries to configure UART attached HCIs at a higher
      baudraute using vendor specific opcodes. The BCM4343A0 does not
      support this and this used to simply fail:
      
      [   25.646442] Bluetooth: hci0: BCM: failed to write clock (-56)
      [   25.646481] Bluetooth: hci0: Failed to set baudrate
      
      After which things would continue with the initial baudraute. But now
      that hci_cmd_complete_evt() no longer sets status for unknown opcodes
      *status is left at 0. This causes the hci_bcm.c code to think the baudraute
      has been changed on the HCI side and to also adjust the UART baudrate,
      after which communication with the HCI is broken, leading to:
      
      [   28.579042] Bluetooth: hci0: command 0x0c03 tx timeout
      [   36.961601] Bluetooth: hci0: BCM: Reset failed (-110)
      
      And non working bluetooth. Fix this by restoring the previous
      default "*status = skb->data[0]" handling for unknown opcodes.
      
      Fixes: c8992cff ("Bluetooth: hci_event: Use of a function table to handle Command Complete")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      afcb3369
    • Brian Gix's avatar
      Bluetooth: convert hci_update_adv_data to hci_sync · 651cd3d6
      Brian Gix authored
      hci_update_adv_data() is called from hci_event and hci_core due to
      events from the controller. The prior function used the deprecated
      hci_request method, and the new one uses hci_sync.c
      Signed-off-by: default avatarBrian Gix <brian.gix@intel.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      651cd3d6
  6. 09 Aug, 2022 1 commit
  7. 23 Jul, 2022 2 commits
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Add initial implementation of BIS connections · eca0ae4a
      Luiz Augusto von Dentz authored
      This adds initial support for BIS/BIG which includes:
      
      == Broadcaster role: Setup a periodic advertising and create a BIG ==
      
      > tools/isotest -s 00:00:00:00:00:00
      isotest[63]: Connected [00:00:00:00:00:00]
      isotest[63]: QoS BIG 0x00 BIS 0x00 Packing 0x00 Framing 0x00]
      isotest[63]: Output QoS [Interval 10000 us Latency 10 ms SDU 40 PHY 0x02
      RTN 2]
      isotest[63]: Sending ...
      isotest[63]: Number of packets: 1
      isotest[63]: Socket jitter buffer: 80 buffer
      < HCI Command: LE Set Perio.. (0x08|0x003e) plen 7
      ...
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Periodic Advertising Parameters (0x08|0x003e) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Perio.. (0x08|0x003f) plen 7
      ...
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Periodic Advertising Data (0x08|0x003f) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Perio.. (0x08|0x0040) plen 2
      ...
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Periodic Advertising Enable (0x08|0x0040) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Create B.. (0x08|0x0068) plen 31
      ...
      > HCI Event: Command Status (0x0f) plen 4
            LE Create Broadcast Isochronous Group (0x08|0x0068) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 21
            LE Broadcast Isochronous Group Complete (0x1b)
            ...
      
      == Broadcast Receiver role: Create a PA Sync and BIG Sync ==
      
      > tools/isotest -i hci1 -d 00:AA:01:00:00:00
      isotest[66]: Waiting for connection 00:AA:01:00:00:00...
      < HCI Command: LE Periodic Advert.. (0x08|0x0044) plen 14
      ...
      > HCI Event: Command Status (0x0f) plen 4
            LE Periodic Advertising Create Sync (0x08|0x0044) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Extended Sca.. (0x08|0x0041) plen 8
      ...
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Extended Sca.. (0x08|0x0042) plen 6
      ...
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Scan Enable (0x08|0x0042) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 29
            LE Extended Advertising Report (0x0d)
            ...
      > HCI Event: LE Meta Event (0x3e) plen 16
            LE Periodic Advertising Sync Established (0x0e)
            ...
      < HCI Command: LE Broadcast Isoch.. (0x08|0x006b) plen 25
      ...
      > HCI Event: Command Status (0x0f) plen 4
            LE Broadcast Isochronous Group Create Sync (0x08|0x006b) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 17
            LE Broadcast Isochronous Group Sync Estabilished (0x1d)
            ...
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      eca0ae4a
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Add initial implementation of CIS connections · 26afbd82
      Luiz Augusto von Dentz authored
      This adds the initial implementation of CIS connections and introduces
      the ISO packets/links.
      
      == Central: Set CIG Parameters, create a CIS and Setup Data Path ==
      
      > tools/isotest -s <address>
      
      < HCI Command: LE Extended Create... (0x08|0x0043) plen 26
      ...
      > HCI Event: Command Status (0x0f) plen 4
            LE Extended Create Connection (0x08|0x0043) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 31
            LE Enhanced Connection Complete (0x0a)
            ...
      < HCI Command: LE Create Connected... (0x08|0x0064) plen 5
      ...
      > HCI Event: Command Status (0x0f) plen 4
            LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
              Status: Success (0x00)
      > HCI Event: LE Meta Event (0x3e) plen 29
            LE Connected Isochronous Stream Established (0x19)
            ...
      < HCI Command: LE Setup Isochronou.. (0x08|0x006e) plen 13
      ...
      > HCI Event: Command Complete (0x0e) plen 6
            LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
              Status: Success (0x00)
              Handle: 257
      < HCI Command: LE Setup Isochronou.. (0x08|0x006e) plen 13
      ...
      > HCI Event: Command Complete (0x0e) plen 6
            LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
              Status: Success (0x00)
              Handle: 257
      
      == Peripheral: Accept CIS and Setup Data Path ==
      
      > tools/isotest -d
      
       HCI Event: LE Meta Event (0x3e) plen 7
            LE Connected Isochronous Stream Request (0x1a)
      ...
      < HCI Command: LE Accept Co.. (0x08|0x0066) plen 2
      ...
      > HCI Event: LE Meta Event (0x3e) plen 29
            LE Connected Isochronous Stream Established (0x19)
      ...
      < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13
      ...
      > HCI Event: Command Complete (0x0e) plen 6
            LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
              Status: Success (0x00)
              Handle: 257
      < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13
      ...
      > HCI Event: Command Complete (0x0e) plen 6
            LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
              Status: Success (0x00)
              Handle: 257
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      26afbd82
  8. 22 Jul, 2022 4 commits
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_core: Introduce hci_recv_event_data · dfe6d5c3
      Luiz Augusto von Dentz authored
      This introduces hci_recv_event_data to make it simpler to access the
      contents of last received event rather than having to pass its contents
      to the likes of *_ind/*_cfm callbacks.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      dfe6d5c3
    • Brian Gix's avatar
      Bluetooth: Remove update_scan hci_request dependancy · bb876725
      Brian Gix authored
      This removes the remaining calls to HCI_OP_WRITE_SCAN_ENABLE from
      hci_request call chains, and converts them to hci_sync calls.
      Signed-off-by: default avatarBrian Gix <brian.gix@intel.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      bb876725
    • Schspa Shi's avatar
      Bluetooth: When HCI work queue is drained, only queue chained work · 877afada
      Schspa Shi authored
      The HCI command, event, and data packet processing workqueue is drained
      to avoid deadlock in commit
      76727c02 ("Bluetooth: Call drain_workqueue() before resetting state").
      
      There is another delayed work, which will queue command to this drained
      workqueue. Which results in the following error report:
      
      Bluetooth: hci2: command 0x040f tx timeout
      WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140
      Workqueue: events hci_cmd_timeout
      RIP: 0010:__queue_work+0xdad/0x1140
      RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093
      RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000
      RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08
      RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700
      R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60
      R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800
      FS:  0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       ? queue_work_on+0xcb/0x110
       ? lockdep_hardirqs_off+0x90/0xd0
       queue_work_on+0xee/0x110
       process_one_work+0x996/0x1610
       ? pwq_dec_nr_in_flight+0x2a0/0x2a0
       ? rwlock_bug.part.0+0x90/0x90
       ? _raw_spin_lock_irq+0x41/0x50
       worker_thread+0x665/0x1080
       ? process_one_work+0x1610/0x1610
       kthread+0x2e9/0x3a0
       ? kthread_complete_and_exit+0x40/0x40
       ret_from_fork+0x1f/0x30
       </TASK>
      
      To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue the
      timeout workqueue while command workqueue is draining.
      
      Fixes: 76727c02 ("Bluetooth: Call drain_workqueue() before resetting state")
      Reported-by: syzbot+63bed493aebbf6872647@syzkaller.appspotmail.com
      Signed-off-by: default avatarSchspa Shi <schspa@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      877afada
    • Alain Michaud's avatar
      Bluetooth: clear the temporary linkkey in hci_conn_cleanup · 629f66aa
      Alain Michaud authored
      If a hardware error occurs and the connections are flushed without a
      disconnection_complete event being signaled, the temporary linkkeys are
      not flushed.
      
      This change ensures that any outstanding flushable linkkeys are flushed
      when the connection are flushed from the hash table.
      
      Additionally, this also makes use of test_and_clear_bit to avoid
      multiple attempts to delete the link key that's already been flushed.
      Signed-off-by: default avatarAlain Michaud <alainm@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      629f66aa
  9. 23 May, 2022 1 commit
  10. 13 May, 2022 2 commits
  11. 26 Apr, 2022 3 commits
  12. 18 Mar, 2022 1 commit
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Fix use after free in hci_send_acl · f63d24ba
      Luiz Augusto von Dentz authored
      This fixes the following trace caused by receiving
      HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without
      first checking if conn->type is in fact AMP_LINK and in case it is
      do properly cleanup upper layers with hci_disconn_cfm:
      
       ==================================================================
          BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50
          Read of size 8 at addr ffff88800e404818 by task bluetoothd/142
      
          CPU: 0 PID: 142 Comm: bluetoothd Not tainted
          5.17.0-rc5-00006-gda4022eeac1a #7
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
          rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
          Call Trace:
           <TASK>
           dump_stack_lvl+0x45/0x59
           print_address_description.constprop.0+0x1f/0x150
           kasan_report.cold+0x7f/0x11b
           hci_send_acl+0xaba/0xc50
           l2cap_do_send+0x23f/0x3d0
           l2cap_chan_send+0xc06/0x2cc0
           l2cap_sock_sendmsg+0x201/0x2b0
           sock_sendmsg+0xdc/0x110
           sock_write_iter+0x20f/0x370
           do_iter_readv_writev+0x343/0x690
           do_iter_write+0x132/0x640
           vfs_writev+0x198/0x570
           do_writev+0x202/0x280
           do_syscall_64+0x38/0x90
           entry_SYSCALL_64_after_hwframe+0x44/0xae
          RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
          Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3
          0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05
          <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
          RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015
          RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77
          R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580
          RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001
          </TASK>
          R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0
      
          Allocated by task 45:
              kasan_save_stack+0x1e/0x40
              __kasan_kmalloc+0x81/0xa0
              hci_chan_create+0x9a/0x2f0
              l2cap_conn_add.part.0+0x1a/0xdc0
              l2cap_connect_cfm+0x236/0x1000
              le_conn_complete_evt+0x15a7/0x1db0
              hci_le_conn_complete_evt+0x226/0x2c0
              hci_le_meta_evt+0x247/0x450
              hci_event_packet+0x61b/0xe90
              hci_rx_work+0x4d5/0xc50
              process_one_work+0x8fb/0x15a0
              worker_thread+0x576/0x1240
              kthread+0x29d/0x340
              ret_from_fork+0x1f/0x30
      
          Freed by task 45:
              kasan_save_stack+0x1e/0x40
              kasan_set_track+0x21/0x30
              kasan_set_free_info+0x20/0x30
              __kasan_slab_free+0xfb/0x130
              kfree+0xac/0x350
              hci_conn_cleanup+0x101/0x6a0
              hci_conn_del+0x27e/0x6c0
              hci_disconn_phylink_complete_evt+0xe0/0x120
              hci_event_packet+0x812/0xe90
              hci_rx_work+0x4d5/0xc50
              process_one_work+0x8fb/0x15a0
              worker_thread+0x576/0x1240
              kthread+0x29d/0x340
              ret_from_fork+0x1f/0x30
      
          The buggy address belongs to the object at ffff88800c0f0500
          The buggy address is located 24 bytes inside of
          which belongs to the cache kmalloc-128 of size 128
          The buggy address belongs to the page:
          128-byte region [ffff88800c0f0500, ffff88800c0f0580)
          flags: 0x100000000000200(slab|node=0|zone=1)
          page:00000000fe45cd86 refcount:1 mapcount:0
          mapping:0000000000000000 index:0x0 pfn:0xc0f0
          raw: 0000000000000000 0000000080100010 00000001ffffffff
          0000000000000000
          raw: 0100000000000200 ffffea00003a2c80 dead000000000004
          ffff8880078418c0
          page dumped because: kasan: bad access detected
          ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
          Memory state around the buggy address:
          >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
          ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
          ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                      ^
          ==================================================================
          ffff88800c0f0600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      Reported-by: default avatarSönke Huster <soenke.huster@eknoes.de>
      Tested-by: default avatarSönke Huster <soenke.huster@eknoes.de>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f63d24ba
  13. 04 Mar, 2022 1 commit
    • Niels Dossche's avatar
      Bluetooth: hci_event: Add missing locking on hdev in hci_le_ext_adv_term_evt · 728abc01
      Niels Dossche authored
      Both hci_find_adv_instance and hci_remove_adv_instance have a comment
      above their function definition saying that these two functions require
      the caller to hold the hdev->lock lock. However, hci_le_ext_adv_term_evt
      does not acquire that lock and neither does its caller hci_le_meta_evt
      (hci_le_meta_evt calls hci_le_ext_adv_term_evt via an indirect function
      call because of the lookup in hci_le_ev_table).
      
      The other event handlers all acquire and release the hdev->lock and they
      follow the rule that hci_find_adv_instance and hci_remove_adv_instance
      must be called while holding the hdev->lock lock.
      
      The solution is to make sure hci_le_ext_adv_term_evt also acquires and
      releases the hdev->lock lock. The check on ev->status which logs a
      warning and does an early return is not covered by the lock because
      other functions also access ev->status without holding the lock.
      Signed-off-by: default avatarNiels Dossche <niels.dossche@ugent.be>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      728abc01
  14. 25 Jan, 2022 2 commits
  15. 14 Jan, 2022 1 commit
  16. 11 Jan, 2022 1 commit
  17. 06 Jan, 2022 1 commit
  18. 22 Dec, 2021 3 commits
  19. 07 Dec, 2021 8 commits