Hi Yuri, > This patch fixes NULL pointer dereference at running test with > connect-transfer-disconnect in loop. The problem conditions are the > following: there are 2 BT devices. The first one listens and > receives (l2test -r), the second one makes "connect-disconnect- > connect..." sequence (l2test -c -b 1000 -i hci0 -P 10 <addr>). > After some time this will cause the race between functions > bt_accept_dequeue and l2cap_chan_del. The function l2cap_chan_del > sets the socket state to BT_CLOSED, unlinks and kills the socket > in the middle of bt_accept_dequeue, then at running the removed code > kernel oops appears. it could be that we have this in here for RFCOMM. Can you retest it with this with using RFCOMM and see if we get dangling RFCOMM sockets. You need to test both directions, incoming and outgoing. Regards Marcel -- 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
