RE: [Bluez-devel] Rfcomm Use Count

Daryl Van Vorst
2004-09-22T17:57:40Z

Hi Marcel,

> after more and more thinking about that problem I am almost=20
> sure that it
> is right to call rfcomm_sock_kill() in the state change=20
> function. Anyway
> we must do this on an unlocked socket. Here is my proposal=20
> for the final
> patch, but we need real testing on this so that I can be sure=20
> that there
> are no side effects. Can anyone test it on SMP or HT systems?

I manually applied your patch to my 2.4 kernel, and it seems to work =
fine. I
haven't been able to break it yet. Looks good. I will keep trying.

Does this change make the "if (sk->state =3D=3D BT_CLOSED)" statement in
bluez_accept_dequeue() redundant?

This is important because if somehow a socket is in BT_CLOSED state and =
is
in the accept queue during shutdown, then rfcomm_cleanup_listen() can't
clean it up (because bluez_accept_dequeue() won't return it). I think =
your
changes make it impossible for there to ever be an rfcomm socket (or =
l2cap
socket) in the BT_CLOSED state in the accept queue. If that's true, then
this isn't an issue. Thoughts?

Do you think we've covered the case where there are incomming =
connections
while things are at various stages of being shut down? I think we're ok, =
but
I wanted to bring it up.

-Daryl.