Hi,
Is this bug still present? I haven't seen any more updates on this thread.
Thanks,
Regards,
-- Ulisses
On Tue, Jan 3, 2012 at 10:03 AM, Andrei Emeltchenko
<andrei.emeltchenko.news@xxxxxxxxx> wrote:
> Hi Vinicius,
>
> On Mon, Jan 02, 2012 at 10:51:31PM -0300, Vinicius Costa Gomes wrote:
>> Hi,
>>
>> I found this bug (trace attached) and I don't think I will be able to
>> start working on it in the next 11 hours, so this email is to make
>> the life of anyone who wants to work on it a little easier. (If anyone
>> wishes to work on this, please respond this email).
>>
>> I was able to reproduce it consistenly doing a "hciconfig <dev> down"
>> with an established connection. I was using LE devices, but it seems that
>> the types of the devices don't matter.
>>
>> The problem is that cancel_delayed_work_sync() called inside
>> hci_conn_del() is blocking, because of and called in the context of an RCU
>> (inside hci_conn_hash_flush()).
>
> I think that if the RCU code is not protected by rcu_read_{,un}lock then
> it is OK to sleep (and this is updater anyway).
>
> In that function "hci_conn_hash_flush" maybe it is better to use
> list_for_each_entry instead of list_for_each_entry_rcu for better
> readability?
>
> Best regards
> Andrei Emeltchenko
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ulisses Furquim
ProFUSION embedded systems
http://profusion.mobi
Mobile: +55 19 9250 0942
Skype: ulissesffs
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
