Hi Ulisses,
On Fri, Feb 10, 2012 at 04:31:26PM -0200, Ulisses Furquim wrote:
> Hi Andrei,
>
> On Fri, Feb 10, 2012 at 7:18 AM, Emeltchenko Andrei
> <Andrei.Emeltchenko.news@xxxxxxxxx> wrote:
> > Hi Ulisses,
> >
> > On Thu, Feb 09, 2012 at 04:25:11PM -0200, Ulisses Furquim wrote:
> >> > bacpy(src, conn->src);
> >> >
> >> > + l2cap_chan_unlock(chan);
> >> > l2cap_chan_add(conn, chan);
> >> > + l2cap_chan_lock(chan);
> >>
> >> Hum, do we really need to do this? Maybe l2cap_chan_add() can receive
> >> chan already locked?
> >
> > Then we have here order of locking changed and I have lockdep warnings.
> >
> > And here l2cap_chan_add used locked.
>
> Why the locked version and not __l2cap_chan_add()?
Because we need to lock addition channel to chan list and we are locked
only with chan->lock.
> >> > - __l2cap_state_change(chan, BT_CONNECT);
> >> > + l2cap_state_change(chan, BT_CONNECT);
> >>
> >> Why? Is there a problem moving the release_sock() call to we don't
> >> call the locked function here?
> >>
> >> > __set_chan_timer(chan, sk->sk_sndtimeo);
> >> >
> >> > if (hcon->state == BT_CONNECTED) {
> >> > if (chan->chan_type != L2CAP_CHAN_CONN_ORIENTED) {
> >> > __clear_chan_timer(chan);
> >> > if (l2cap_chan_check_security(chan))
> >> > - __l2cap_state_change(chan, BT_CONNECTED);
> >> > + l2cap_state_change(chan, BT_CONNECTED);
> >>
> >> And here as well.
> >
> > Then we would need to release lock before l2cap_do_start.
>
> Sure.
I will check what can be done, currently including wide locks/unlocks would
significantly reduce readability of this part of the code.
Best regards
Andrei Emeltchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
