Description of problem:


While rfcomm_sock_connect acquires the sk lock and waits for
the rfcomm lock, rfcomm_sock_release could have the rfcomm
lock and hit a deadlock for acquiring the sk lock.
Here's a simplified flow:

```
rfcomm_sock_connect:
  lock_sock(sk)
  rfcomm_dlc_open:
    rfcomm_lock()
```

```

rfcomm_sock_release:
  rfcomm_sock_shutdown:
    rfcomm_lock()
    __rfcomm_dlc_close:
        rfcomm_k_state_change:
	  lock_sock(sk)
```


How reproducible: reproducible


Steps to Reproduce:
1. In bluetooth connection, bluetooth device will send HciEvent Packets to kernel bluetooth module. The most common HciEvent Type of the 3rd packet is 0x03. This type of packet has an attribute Link_Type, which must be 0x00 or 0x01 according to the Bluetooth Stantard. But when Link_Type is an undefined value except 0x00 or 0x01, and this undefined HciEvent Packet is send to kernel bluetooth module, deadlock will occur.
2. Use a way to change HciEvent Packets bluetooth device send, for example，  Virtual Interrupt for add a Hook in btusb module.
3. Send a 0x03 type HciEvent Packet with undefined Link_Type.


Actual results: deadlock for acquiring the sk lock


Expected results: no deaklock