linux-dev/net/bluetooth/hci_request.c, branch linus/master

bluetooth: don't use bitmaps for random flag accesses

2022-06-05T23:28:41Z

The bluetooth code uses our bitmap infrastructure for the two bits (!) of connection setup flags, and in the process causes odd problems when it converts between a bitmap and just the regular values of said bits. It's completely pointless to do things like bitmap_to_arr32() to convert a bitmap into a u32. It shoudln't have been a bitmap in the first place. The reason to use bitmaps is if you have arbitrary number of bits you want to manage (not two!), or if you rely on the atomicity guarantees of the bitmap setting and clearing. The code could use an "atomic_t" and use "atomic_or/andnot()" to set and clear the bit values, but considering that it then copies the bitmaps around with "bitmap_to_arr32()" and friends, there clearly cannot be a lot of atomicity requirements. So just use a regular integer. In the process, this avoids the warnings about erroneous use of bitmap_from_u64() which were triggered on 32-bit architectures when conversion from a u64 would access two words (and, surprise, surprise, only one word is needed - and indeed overkill - for a 2-bit bitmap). That was always problematic, but the compiler seems to notice it and warn about the invalid pattern only after commit 0a97953fd221 ("lib: add bitmap_{from,to}_arr64") changed the exact implementation details of 'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell. Fixes: fe92ee6425a2 ("Bluetooth: hci_core: Rework hci_conn_params flags") Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/ Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/ Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/ Reported-by: Stephen Rothwell Reported-by: Sudip Mukherjee Reviewed-by: Yury Norov Cc: Luiz Augusto von Dentz Cc: Marcel Holtmann Signed-off-by: Linus Torvalds

Bluetooth: hci_sync: use hci_skb_event() helper

2022-05-23T15:21:59Z

This instance is the only opencoded version of the macro, so have it follow suit. Signed-off-by: Ahmad Fatoum Signed-off-by: Marcel Holtmann

Bluetooth: use hdev lock in activate_scan for hci_is_adv_monitoring

2022-05-13T11:05:49Z

hci_is_adv_monitoring's function documentation states that it must be called under the hdev lock. Paths that leads to an unlocked call are: discov_update => start_discovery => interleaved_discov => active_scan and: discov_update => start_discovery => active_scan The solution is to take the lock in active_scan during the duration of the call to hci_is_adv_monitoring. Fixes: c32d624640fd ("Bluetooth: disable filter dup when scan for adv monitor") Signed-off-by: Niels Dossche Signed-off-by: Marcel Holtmann

Bluetooth: hci_sync: Add hci_le_create_conn_sync

2021-12-22T22:01:35Z

This adds hci_le_create_conn_sync and make hci_le_connect use it instead of queueing multiple commands which may conflict with the likes of hci_update_passive_scan which uses hci_cmd_sync_queue. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann

Bluetooth: hci_sync: Push sync command cancellation to workqueue

2021-12-22T22:01:27Z

syzbot reported that hci_cmd_sync_cancel may sleep from the wrong context. To avoid this, create a new work item that pushes the relevant parts into a different context. Note that we keep the old implementation with the name __hci_cmd_sync_cancel as the sleeping behaviour is desired in some cases. Reported-and-tested-by: syzbot+485cc00ea7cf41dfdbf1@syzkaller.appspotmail.com Fixes: c97a747efc93 ("Bluetooth: btusb: Cancel sync commands for certain URB errors") Signed-off-by: Benjamin Berg Signed-off-by: Marcel Holtmann

Bluetooth: hci_core: Rework hci_conn_params flags

2021-12-07T16:05:51Z

This reworks hci_conn_params flags to use bitmap_* helpers and add support for setting the supported flags in hdev->conn_flags so it can easily be accessed. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann

Bluetooth: Add hci_cmd_sync_cancel to public API

2021-12-03T18:41:59Z

After transfer errors it makes sense to cancel an ongoing synchronous command that cannot complete anymore. To permit this, export the old hci_req_sync_cancel function as hci_cmd_sync_cancel in the API. Signed-off-by: Benjamin Berg Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Reset more state when cancelling a sync command

2021-12-03T18:41:59Z

Resetting the timers and cmd_cnt means that we assume the device will be in a good state after the sync command finishes. Without this a chain of synchronous commands might get stuck if one of them is cancelled. Signed-off-by: Benjamin Berg Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_request: Remove bg_scan_update work

2021-11-16T14:13:34Z

This work is no longer necessary since all the code using it has been converted to use hci_passive_scan/hci_passive_scan_sync. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann

Bluetooth: hci_sync: Convert MGMT_OP_SET_CONNECTABLE to use cmd_sync

2021-11-16T14:13:34Z

This makes MGMT_OP_SET_CONNEABLE use hci_cmd_sync_queue instead of use a dedicated connetable_update work. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann