* Mat Martineau <mathewm@xxxxxxxxxxxxxx> [2012-09-07 10:00:40 -0700]: > > Andrei - > > On Fri, 7 Sep 2012, Andrei Emeltchenko wrote: > > >Hi Marcel, > > > >On Thu, Sep 06, 2012 at 01:10:51PM -0700, Marcel Holtmann wrote: > >>Hi Mat, > >> > >>>>If we have unacked frames when closing bluetooth socket we deadlock > >>>>since conn->chan_lock, chan->lock and socket lock are taken. Remove > >>>>__l2cap_wait_ack completely. > >>>> > >>>>Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@xxxxxxxxx> > >>> > >>>I don't think you want to remove this code completely, at least not > >>>without giving some thought to the problem it is solving. > >>> > >>>The problem is that programs may have an open socket which they send > >>>some data on, then immediately close. There is no feedback when data > >>>is actually sent over the air, so the socket may end up getting torn > >>>down while there is still data in the HCI tx buffer or some data was > >>>lost and needs to be retransmitted. Waiting for an acknowledgement > >>>confirms that the application's sent data made it to the remote > >>>device. > >>> > >>>Without this code, it's difficult to use l2test on a number of > >>>qualification tests. Profiles or applications using ERTM may depend > >>>on the "wait for ack before closing" behavior in order to have a clean > >>>disconnect. > >> > >>isn't that what we have SO_LINGER for? > > > >Looking at the code I suspect that SO_LINGER is not working. Maybe we need > >to merge linger code and wait_ack stuff. > > It does look like a bug that the "wait_ack" behavior happens even > without SO_LINGER. > > In order to do SO_LINGER right, it would be better to check > chan->tx_q instead of chan->unacked_frames to makes sure all data is > sent and acked. chan->unacked_frames only tells you how many sent > frames are unacked and does not take in to account queued data that > hasn't been sent yet. Not sure if we need SO_LINGER here, in TCP shutdown() per default waits for the remote side to close the connection, we basically doing something similar here. IMHO we just fixes this to avoid deadlock and stay with this code. Gustavo -- 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
