RE: Rfcomm Use Count

Hi Marcel,

> after more and more thinking about that problem I am almost 
> sure that it
> is right to call rfcomm_sock_kill() in the state change 
> function. Anyway
> we must do this on an unlocked socket. Here is my proposal 
> for the final
> patch, but we need real testing on this so that I can be sure 
> 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 == 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.



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php