Hi,
pe, 2024-11-01 kello 10:23 +0200, Iulia Tanasescu kirjoitti:
[clip]
> + rcu_read_lock();
> +
> + /* The spec allows only one pending LE Periodic Advertising Create
> + * Sync command at a time. If the command is pending now, don't do
> + * anything. We check for pending connections after each PA Sync
> + * Established event.
> + *
> + * BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E
> + * page 2493:
> + *
> + * If the Host issues this command when another HCI_LE_Periodic_
> + * Advertising_Create_Sync command is pending, the Controller shall
> + * return the error code Command Disallowed (0x0C).
> + */
> + list_for_each_entry_rcu(conn, &hdev->conn_hash.list, list) {
> + if (test_bit(HCI_CONN_CREATE_PA_SYNC, &conn->flags))
> + goto unlock;
> }
>
> - return hci_update_passive_scan_sync(hdev);
> + list_for_each_entry_rcu(conn, &hdev->conn_hash.list, list) {
> + if (hci_conn_check_create_pa_sync(conn)) {
> + struct bt_iso_qos *qos = &conn->iso_qos;
> +
> + cp = kzalloc(sizeof(*cp), GFP_KERNEL);
AFAIK sleeping alloc in rcu critical section is not allowed, I suspect
this produces:
BUG: sleeping function called from invalid context at include/linux/sched/mm.h:321
if you run it on kernel compiled with CONFIG_DEBUG_ATOMIC_SLEEP=y.
I've found the following useful when testing:
CONFIG_DEBUG_KERNEL=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_PROVE_LOCKING=y
CONFIG_PROVE_RCU=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_KASAN=y
--
Pauli Virtanen
