RE: Rfcomm use count

Marcel,

That didn't work, but I think I found the problem. Not sure what the correct
solution is though.

Rfcomm_sock_cleanup_listen() calls bluez_accept_dequeue() in a loop until
bluez_accept_dequeue() has no more sockets to return. For each socket that
bluez_accept_dequeue() returns, rfcomm_sock_cleanup_listen() closes and
kills it. Killing it unlinks it from rfcomm_sk_list.

But if the socket is already closed (sk->state == BT_CLOSED), then
bluez_accept_dequeue() does not return the socket (it just continues to the
next one in the queue). Bluez_accept_dequeue() does unlink it from the
accept queue, but not from rfcomm_sk_list.

I suppose the first question is: Is the bug in cleanup/dequeue, or is the
bug elsewhere (i.e.: things shouldn't ever be in quite that state when
cleanup_listen is called)?

Also, should rfcomm_sock_destruct() be called to decrement the use count?

-Daryl.

> -----Original Message-----
> From: Marcel Holtmann [mailto:marcel@xxxxxxxxxxxx] 
> Sent: September 14, 2004 2:18 AM
> To: Daryl Van Vorst
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Rfcomm use count
> 
> 
> Hi Daryl,
> 
> > I just noticed that bluez_accept_unlink() was called with a 
> socked that was
> > in state BT_CLOSED, so it can't be the second if(). It 
> would have been
> > called from the first if().
> > 
> > Clearly, I'm on glue.
> > 
> > Still, does the order of bluez_accept_unlink() and 
> sock_release() matter?
> 
> I haven't done a full audit yet, but try to switch the order and see
> what happens. From a first look at it it makes sense to only 
> release the
> socket when all the work is done, because otherwise 
> lock_sock() makes no
> sense.
> 
> Regards
> 
> Marcel
> 
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m