RE: [Bluez-devel] Rfcomm Use Count

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

Hi Marcel,

> try to test your normal stuff to make sure that it doesn't break
> anything else.

So far so good. I'm setting up some automated testers to pound on it for =
a
while.

> > Does this change make the "if (sk->state =3D=3D BT_CLOSED)" =
statement in
> > bluez_accept_dequeue() redundant?
>=20
> I think so. Haven't thought about it so far.
>=20
> > This is important because if somehow a socket is in=20
> BT_CLOSED state and is
> > in the accept queue during shutdown, then=20
> rfcomm_cleanup_listen() can't
> > clean it up (because bluez_accept_dequeue() won't return=20
> it). I think your
> > changes make it impossible for there to ever be an rfcomm=20
> socket (or l2cap
> > socket) in the BT_CLOSED state in the accept queue. If=20
> that's true, then
> > this isn't an issue. Thoughts?
>=20
> Sorry, but I can't follow your point here. Please explain it again.

Bluez_accept_dequeue() won't return a socket if it is in the closed =
state.
So rfcomm_cleanup_listen() will never call close and kill on the socket
because ...accept_dequeue() never returns it (it just unlinks it). And =
then
we would have the use count problem. But if there is no possibility of a
socket being in the closed state on the accept queue (for rfcomm at =
least),
then this isn't an issue.

I think this is fixed - so if I'm still talking nonsense, just ignore =
it. ;)

> > Do you think we've covered the case where there are=20
> incomming connections
> > while things are at various stages of being shut down? I=20
> think we're ok, but
> > I wanted to bring it up.
>=20
> Actually I don't know. In general we should be protected against that
> with our locking.

As far as I could see the locking protects against it. But I did not =
spend
enough time on it to fully understand how it works. If there is a =
problem,
my testing should eventually uncover it.

-Daryl.