logo       

RE: Rfcomm Use Count: msg#00066

linux.bluez.devel

Subject: RE: Rfcomm Use Count

Hi Marcel,

> > Making bluez_accept_dequeue() return sockets regardless of
> state is a
> > potential solution. Accept() for rfcomm and l2cap would
> then need to be
> > modified to kill already closed sockets. The existing loop
> in the accept()'s
> > would need to be modified or a new one added to handle
> > bluez_accept_dequeue() not always returning an open socket.
>
> I don't like that idea and the problem is not in
> ...cleanup_listen() and
> so I am not sure if it will really help us.

Fair enough. Though I'm talking about changing bluez_accept_dequeue(), not
necessarily cleanup_listen().

> > I may not have been clear about my thoughts on
> rfcomm_sock_cleanup_listen().
> > If bluez_accept_dequeue() did return sockets regardless of
> state, then
> > rfcomm_sock_cleanup_listen() should work (unless calling
> close on an already
> > closed socket causes trouble). When it calls
> rfcomm_sock_kill(), sock_put()
> > gets called which calls destruct() which should decrement
> the use count.
>
> The ...cleanup_listen() kicks in when you stop the listening
> server, but
> that is far too late. The problematic part already happened.
> We close a
> connection that wasn't accepted. We must fix it there and not
> afterwards
> like somekind of garbage collection. This is the kernel and not some
> weird Jave/C++ code.

With my suggestion above the condition would be handled by either accept()
or cleanup_listen(), whichever is called first. Though I guess you could
still consider that to be garbage collection.

> > What if bluez_accept_dequeue() called sk->shutdown() on
> sockets which are
> > already closed in the accept queue?
>
> I am not sure about the side effects, but this can be a
> solution. What I
> think is that setting the socket to BT_CLOSED is wrong. Maybe using
> BT_DISCONN is better, but this involves changing the state machine.

Calling sk->shutdown() is bluez_accept_dequeue() would be virtually the same
timing (i.e. garbage collecting likeness) as the suggestion above (returning
the closed socket in ...accept_dequeue). It would happen only when accept()
or cleanup_listen() are called.

> > I'll try out l2cap later for you. We should see the same thing.
>
> I am not sure anymore. Maybe this is only RFCOMM related.

I sent another e-mail a moment ago... It doesn't happen with l2cap (or at
least I wasn't able to get it to happen).

-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


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise