Hi Gustavo,
On 2/2/2011 9:58 PM, Gustavo F. Padovan wrote:
Hi Suraj,
* Suraj Sumangala<suraj@xxxxxxxxxxx> [2011-01-31 18:42:51 +0530]:
This patch lets L2CAP process received S-frames even when socket is
continuously being locked by user process.
This issue was seen when testing with l2test without using "-D" option.
Since the user process does not expect any Rx packets,
it hogs the socket with continuous call to "send()".
When the TxWindow is full Tx stops untill the I-frames are acked by the receiver.
But the Rx S-Frame acknowleding the Tx frames will stay in the backlog queue
because the "sock_owned_by_user()" call in l2cap_data_channel()
will always return true.
The user process does not have an idea about this
mechanism and keep pumping data and locking the socket and cause a deadlock.
In which kernel are you seeing this error? I think it is already fixed.
Regards,
Can you direct me to the patch which fixed it?
I had see this problem when verifying Bluetooth 3.0 in kernel version
2.6.35 and see similar code in the kernel-next tree. That is the reason
why I sent an RFC.
Regards
Suraj
--
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
