RE: [Bluez-devel] Rfcomm use count

["Daryl Van Vorst" <daryl@wideray.com>]

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 =3D=3D 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@holtmann.org]=20
> Sent: September 14, 2004 2:18 AM
> To: Daryl Van Vorst
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Rfcomm use count
>=20
>=20
> Hi Daryl,
>=20
> > I just noticed that bluez_accept_unlink() was called with a=20
> socked that was
> > in state BT_CLOSED, so it can't be the second if(). It=20
> would have been
> > called from the first if().
> >=20
> > Clearly, I'm on glue.
> >=20
> > Still, does the order of bluez_accept_unlink() and=20
> sock_release() matter?
>=20
> 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=20
> release the
> socket when all the work is done, because otherwise=20
> lock_sock() makes no
> sense.
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20