kernel/git/next/linux-next.git/net/bluetooth, branch akpm

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git

2022-06-28T01:09:18+00:00

Bluetooth: mgmt: Fix refresh cached connection info

2022-06-21T19:26:58+00:00

Set the connection data before calling get_conn_info_sync, so it can be verified the connection is still connected, before refreshing cached values. Fixes: 47db6b42991e6 ("Bluetooth: hci_sync: Convert MGMT_OP_GET_CONN_INFO") Signed-off-by: Zhengping Jiang Signed-off-by: Luiz Augusto von Dentz

Bluetooth: HCI: Fix not always setting Scan Response/Advertising Data

2022-06-21T19:01:22+00:00

The scan response and advertising data needs to be tracked on a per instance (adv_info) since when these instaces are removed so are their data, to fix that new flags are introduced which is used to mark when the data changes and then checked to confirm when the data needs to be synced with the controller. Tested-by: Tedd Ho-Jeong An Signed-off-by: Luiz Augusto von Dentz

Bluetooth: eir: Fix using strlen with hdev->{dev_name,short_name}

2022-06-21T19:00:57+00:00

Both dev_name and short_name are not guaranteed to be NULL terminated so this instead use strnlen and then attempt to determine if the resulting string needs to be truncated or not. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216018 Signed-off-by: Luiz Augusto von Dentz

Bluetooth: use memset avoid memory leaks

2022-06-08T16:58:49+00:00

Similar to the handling of l2cap_ecred_connect in commit d3715b2333e9 ("Bluetooth: use memset avoid memory leaks"), we thought a patch might be needed here as well. Use memset to initialize structs to prevent memory leaks in l2cap_le_connect Signed-off-by: Xiaohui Zhang Signed-off-by: Marcel Holtmann

Bluetooth: fix an error code in hci_register_dev()

2022-06-08T16:57:45+00:00

Preserve the error code from hci_register_suspend_notifier(). Don't return success. Fixes: d6bb2a91f95b ("Bluetooth: Unregister suspend with userchannel") Signed-off-by: Dan Carpenter Signed-off-by: Marcel Holtmann

bluetooth: don't use bitmaps for random flag accesses

2022-06-05T23:28:41+00:00

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: Unregister suspend with userchannel

2022-06-05T04:44:17+00:00

When HCI_USERCHANNEL is used, unregister the suspend notifier when binding and register when releasing. The userchannel socket should be left alone after open is completed. Signed-off-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann

Bluetooth: Fix index added after unregister

2022-06-05T04:43:24+00:00

When a userchannel socket is released, we should check whether the hdev is already unregistered before sending out an IndexAdded. Signed-off-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann

Bluetooth: When HCI work queue is drained, only queue chained work

2022-06-03T14:19:31+00:00

The HCI command, event, and data packet processing workqueue is drained to avoid deadlock in commit 76727c02c1e1 ("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: ? 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 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: 76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state") Reported-by: syzbot+63bed493aebbf6872647@syzkaller.appspotmail.com Signed-off-by: Schspa Shi Signed-off-by: Marcel Holtmann