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

[Marcel Holtmann <marcel@holtmann.org>]

Hi Jean,

> 	I could find an informal arrangement if you want my code, like
> "for your eyes only", but it's also not totally trivial to setup.

not needed, because it is very clear where the problem is. But thanks
for the offer.

> 	Yes, the accept() code is right, what's wrong is obviously the
> "poll" code that should not indicate socket readyness before the
> socket is really ready.
> 	The more "correct" way would be to change the "poll()" code to
> really test child socket readyness instead of just testing
> sk_ack_backlog. But, the poll code would get very ugly quickly.
> 	One of the simplest way would be to increase sk_ack_backlog
> only when the socket change to the BT_CONNECTED state (as opposed to
> immediately when we add it to the parent queue). I would need to
> understand where and how exactly is sk_ack_backlog used.
> 	Another solution if we can't use sk_ack_backlog is to use our
> own counter to count the number of child ready, or a flag, or whatever
> mechanism.

I don't see what sk_ack_backlog have to do with it. Can you explain this
to me?

I haven't tested this yet, but I think the problem is the extra check in
bt_sock_poll() for the accept_q:

        if (!skb_queue_empty(&sk->sk_receive_queue) || 
                        !list_empty(&bt_sk(sk)->accept_q) ||
                        (sk->sk_shutdown & RCV_SHUTDOWN))
                mask |= POLLIN | POLLRDNORM;

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