RE: Rfcomm Use Count

Hi Daryl,

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

try to test your normal stuff to make sure that it doesn't break
anything else.

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

I think so. Haven't thought about it so far.

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

Sorry, but I can't follow your point here. Please explain it again.

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

Actually I don't know. In general we should be protected against that
with our locking.

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