RE: Rfcomm Use Count

Hi Daryl,

> > maybe this one helps:
> > 
> > --- 1.29/net/bluetooth/rfcomm/sock.c    2004-06-04 02:41:47 +02:00
> > +++ edited/net/bluetooth/rfcomm/sock.c  2004-09-22 00:12:34 +02:00
> > @@ -104,8 +104,13 @@
> >                 if (d->state == BT_CONNECTED)
> >                         rfcomm_session_getaddr(d->session, 
> > &bt_sk(sk)->src, NULL);
> >                 sk->sk_state_change(sk);
> > -       } else
> > +       } else {
> > +               if (d->state == BT_CLOSED) {
> > +                       bt_accept_unlink(sk);
> > +                       sk->sk_zapped = 1;
> > +               }
> >                 parent->sk_data_ready(parent, 0);
> > +       }
> >  
> >         bh_unlock_sock(sk);
> >  }
> 
> No luck.
> 
> Same behaviour as without the close and kill calls.

the correct approach seems to be:

        sk->sk_zapped = 1;
        rfcomm_sock_kill(sk);

The problem is that rfcomm_sock_kill() must be called on an unlocked
socket and I think that we will deadlock on a SMP machine or get some
NULL pointer dereferences.

> I noticed in l2cap.c that after l2cap_chan_del() is called (which now does
> the accept_unlink()), l2cap_sock_kill() is often called which decrements its
> use count which was incremented in l2cap_sock_alloc() (much like in rfcomm).
> But in rfcomm, there don't appear to be any calls to ...sock_kill() for
> similar circumstances.

That is right and I agree that a ...sock_kill() is missing that calls
sock_put() to decrease the reference count.

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