Messages in this thread | | | Subject | Re: [PATCH v3 2/2] Bluetooth: fix inconsistent lock state in rfcomm_connect_ind | From | Marcel Holtmann <> | Date | Fri, 30 Jul 2021 15:40:19 +0200 |
| |
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? > > Thanks for the info. I think you're right, I just didn't understand very much when I wrote this patch. > > If I'm understanding correctly, it seems that both the bh_lock_sock in rfcomm_connect_ind, and spin_lock_bh in rfcomm_sk_state_change need to be changed to lock_sock, otherwise they don't provide any synchronization with other functions in RFCOMM that use lock_sock. > > If that sounds correct I can prepare the patch for that.
please do so and re-run the tests. Thanks.
Regards
Marcel
| |