Hi Andrei, * Andrei Emeltchenko <andrei.emeltchenko.news@xxxxxxxxx> [2010-11-10 17:24:54 +0200]: > Hi Marcel, > > > Hi Andrei, > > > > > Yet another version of patches fixing kernel crash in RFCOMM / L2CAP. > > > *v4: taken Gustavo comments about timer HZ -> HZ/5 > > > > > > Do not delete l2cap channel and socket sk when sk is owned by user. > > > To delete l2cap channel standard timer is used. > > > > > > lock_sock and release_sock do not hold a normal spinlock directly but > > > instead hold the owner field. This means bh_lock_sock can still execute > > > even if the socket is "locked". More info can be found here: > > > http://www.linuxfoundation.org/collaborate/workgroups/networking/socketlocks > > > > > > When sending following sequence: > > > ... > > > No. Time Source Destination > > > Protocol Info 89 1.951202 RFCOMM Rcvd DISC DLCI=20 > > > 90 1.951324 RFCOMM Sent UA DLCI=20 > > > 91 1.959381 HCI_EVT Number of Completed Packets > > > 92 1.966461 RFCOMM Rcvd DISC DLCI=0 > > > 93 1.966492 L2CAP Rcvd Disconnect Request > > > 94 1.972595 L2CAP Sent Disconnect Response > > > > > > ... > > > > > > krfcommd kernel thread is preempted with l2cap tasklet which remove > > > l2cap_conn (L2CAP connection handler structure). Then rfcomm thread > > > tries to send RFCOMM UA which is reply to RFCOMM DISC and when > > > de-referencing l2cap_conn crash happens. > > > > so I assume you have tested this extensively with various RFCOMM corner > > cases like incoming RFCOMM. Since a lot of profiles require proper > > disconnects and we have to ensure that our reference counting is > > correct. > > We have the slightly modified patch applied for a several months. No regression found. > > Regards, > Andrei > > > > > Other then that it seems fine to me. > > > > Acked-by: Marcel Holtmann <marcel@xxxxxxxxxxxx> Applied to bluetooth-next-2,6, thanks. -- Gustavo F. Padovan http://profusion.mobi -- 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
