RE: Rfcomm Use Count

Hi Daryl,

> Looks like the rfcomm part isn't quite there. The accept queue doesn't fill
> up, but the use count still increases. And /proc/bluetooth/rfcomm still
> lists all of the closed sockets.
> 
> I added rfcomm_sock_close() and rfcomm_sock_kill() right after your addition
> to rfcomm_sk_state_change() and it seems to work. The affects of
> rfcomm_sock_alloc() (called by ...connect_ind()) needed to be dealt with. I
> changed it as follows:
> 
> --- mh_sock.c 2004-09-21 14:21:36.000000000 -0700
> +++ sock.c    2004-09-21 14:21:47.000000000 -0700
> @@ -104,8 +104,11 @@
>                       rfcomm_session_getaddr(d->session,
> &bluez_pi(sk)->src, NULL);
>               sk->state_change(sk);
>       } else {
> -             if (d->state == BT_CLOSED)
> +             if (d->state == BT_CLOSED) {
>                       bluez_accept_unlink(sk);
> +                     rfcomm_sock_close(sk);
> +                     rfcomm_sock_kill(sk);
> +             }
>               parent->data_ready(parent, 0);
>       }
>  
> I am not sure about the possible negative side effects of this. What do you
> think?

what I think is that we have two different bugs here. We may solved the
first one now, which wasn't a module reference count bug. The second now
increases the module reference count and don't decreases it correctly.
Since the RFCOMM implementation is much more complex, because of its
support for TTY and sockets as end user interfaces, we need to find out
if the socket functions are involved or the core/TTY functions.

At the moment I think calling ...sock_close() and ...sock_kill() in that
function is wrong. However I am not 100% sure.

Regards

Marcel




-------------------------------------------------------
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