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

[Marcel Holtmann <marcel@holtmann.org>]

Hi Jean,

> 	I've just managed to reproduce and track a few bug that so far
> were escaping me. There is a race condition in the accept() code for
> non-blocking L2CAP sockets, and a similar one in sendmsg. Or maybe
> it's just that my code is too fast ;-)

do you have a simple test code to reproduce it?

> 	This is the accept race :
> 	1) L2CAP socket in non blocking mode, because program waiting
> on multiple outputs.
> 	2) Wait on socket to be readable with poll/select.
> 	3) When socket is ready, accept() it and do what we have to do.
> 	4) When the race occur, accept() return an error (EAGAIN).
> 	5) We don't touch the socket and go back to poll/select.
> 	6) Poll/select returns immediately (socket is still readable).
> 	7) We attempt the accept(), EAGAIN, goto (5)

Is this an endless loop? Or do accept() succeeds after some time?

BTW why must a listen socket non-blocking? The listen() command itself
doesn't block and I don't see any need for a non-blocking listen socket.

> 	I didn't managed to fully identify the sendmsg race, but I
> goes like this :
> 	1) Open L2CAP socket in non blocking mode, because program
> waiting on multiple outputs.
> 	2) Connect to BT peer.
> 	3) Wait on socket to be writeable with poll/select.
> 	4) When socket is ready, sendmsg() and do what we have to do.
> 	5) When the race occur, sendmsg() return an error (ENOTCONN).
> 	...
> 
> 	I looked at way to fix the code, but it's not a quick fix and
> there is multiple way to attack the problem. So, if one of you could
> have a look at it...

Is this on a listen/accepted socket or is this a simple connection?

> 	Below you will find a self explanatory log of the kernel
> showing the problem with accept. The first accept was successful (no
> problem), the second one was racy.

>>From the logfile function names I assume this is a 2.6 kernel. Do you
see the same behaviour on 2.4?

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