Hi Desmond,
Commit fad003b6c8e3d ("Bluetooth: Fix inconsistent lock state with
RFCOMM") fixed a lockdep warning due to sk->sk_lock.slock being
acquired without disabling softirq while the lock is also used in
softirq context. This was done by disabling interrupts before calling
bh_lock_sock in rfcomm_sk_state_change.
Later, this was changed in commit e6da0edc24ee ("Bluetooth: Acquire
sk_lock.slock without disabling interrupts") to disable softirqs
only.
However, there is another instance of sk->sk_lock.slock being acquired
without disabling softirq in rfcomm_connect_ind. This patch fixes this
by disabling local bh before the call to bh_lock_sock.
back in the days, the packet processing was done in a tasklet, but these days it is done in a workqueue. So shouldn’t this be just converted into a lock_sock(). Am I missing something?