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?
Regards
Marcel
Hi Marcel,
On 30/7/21 3:53 am, Marcel Holtmann wrote:
> 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.
Best wishes,
Desmond
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