Re: [RFC] Bluetooth: process received S-frames when socket is locked by user process

Hi Gustavo,

On 2/2/2011 9:58 PM, Gustavo F. Padovan wrote:

Hi Suraj,

* Suraj Sumangala[off-list ref]  [2011-01-31 18:42:51 +0530]:

quoted

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