537d59af73
There's logic in __rfcomm_dlc_close: rfcomm_dlc_lock(d); d->state = BT_CLOSED; d->state_changed(d, err); rfcomm_dlc_unlock(d); In rfcomm_dev_state_change, it's possible that rfcomm_dev_put try to take the dlc lock, then we will deadlock. Here fixed it by unlock dlc before rfcomm_dev_get in rfcomm_dev_state_change. why not unlock just before rfcomm_dev_put? it's because there's another problem. rfcomm_dev_get/rfcomm_dev_del will take rfcomm_dev_lock, but in rfcomm_dev_add the lock order is : rfcomm_dev_lock --> dlc lock so I unlock dlc before the taken of rfcomm_dev_lock. Actually it's a regression caused by commit |
||
|---|---|---|
| .. | ||
| bnep | ||
| cmtp | ||
| hidp | ||
| rfcomm | ||
| Kconfig | ||
| Makefile | ||
| af_bluetooth.c | ||
| hci_conn.c | ||
| hci_core.c | ||
| hci_event.c | ||
| hci_sock.c | ||
| hci_sysfs.c | ||
| l2cap.c | ||
| lib.c | ||
| sco.c | ||