[Bluez-devel] Re: L2CAP non-blocking socket nasty race conditions

[Marcel Holtmann <marcel@holtmann.org>]

Hi Jean,

> > Touching sk_ack_backlog or introducing another counter is not a good
> > idea, I think. What about moving the bt_accept_enqueue() call in the
> > L2CAP code to the right "time"?
> 
> 	The problem with that is that you are going to loose track of
> those sockets. As accept has not been done, they are not referenced
> from user space. The only place knowing about them is parent->accept_q.
> 	If for some reason the config req/rsp fail, or if the user
> space doesn't accept, those sockets are going to leak. Look at the
> code in "dequeue" that reap CLOSED sockets, and also the code that
> close all childs when a socket is destroyed.
> 	I told you it was not totally trivial.

right now I don't see an easy way out of it. What I am thinking is that
if our socket is BT_LISTEN, we check for an not empty accept_q and than
iterate through all sockets for BT_CONNECTED. If we found one, we return
POLLIN else nothing.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel