> Hi Ilia, > > * Ilia, Kolominsky <iliak@xxxxxx> [2011-12-25 20:34:35 +0000]: > > > Hi BlueZ community! > > > > I have encountered an incorrect behavior of l2cap connection > > establishment mechanism when handling an incoming connection > > request: > > > > > ACL data: handle 1 flags 0x02 dlen 12 > > L2CAP(s): Connect req: psm 23 scid 0x0083 > > < ACL data: handle 1 flags 0x00 dlen 16 > > L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0083 result 0 status 0 > > Connection successful > > < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2 > > handle 1 > > < ACL data: handle 1 flags 0x00 dlen 12 > > L2CAP(s): Config req: dcid 0x0083 flags 0x00 clen 0 > > > HCI Event: Mode Change (0x14) plen 6 > > status 0x00 handle 1 mode 0x00 interval 0 > > Mode: Active > > < ACL data: handle 1 flags 0x00 dlen 16 > > L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0083 result 1 status 2 > > Connection pending - Authorization pending > > > > After analyzing the code, it seems to me that there is indeed a > > clear possibility that replies will egress out of order on > > multicore systems: > > > > CPU0 (Tasklet: hci_rx_task) CPU1 (user process) > > Can you check if this also happens after the move to workqueue > processing? > The workqueue handling is quite different, then this problem might not > be > there anymore. Firstly, I think workqueue should only make the matters worse - since it can be preempted ( unlike tasklets ) this can happen even on single CPU. ) e.g. resched just before send_resp label). Secondly, as with any race situations, this bug is difficult to reproduce, I saw it only a couple of times, thus I call for theoretical analysis. > > Gustavo Regards, Ilia -- 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
