Hi Ulisses, On Tue, Feb 14, 2012 at 03:23:54PM -0200, Ulisses Furquim wrote: > On Tue, Feb 14, 2012 at 11:21 AM, Emeltchenko Andrei > <Andrei.Emeltchenko.news@xxxxxxxxx> wrote: > > Hi Ulisses, > > > > On Mon, Feb 13, 2012 at 10:06:10PM -0300, Ulisses Furquim wrote: > > ... > >> Yes, I do think they belong together. And please, check l2cap_sock.c > >> where l2cap_chan_close() seems to be called without locking > >> conn->chan_lock in l2cap_sock_shutdown(). > > > > In that context we do not always have l2cap_conn so maybe we return > > chan list lock to chan_del or invent unlocked chan_del / chan_close? > > We don't have l2cap_conn? So are we already on conn->chan_l list or > not? Maybe it's better to check that instead of changing everything > now. I am afraid that the logic in l2cap_chan_close is a bit complicated, for listening socket is recursively invokes itself for every sk in accept queue. conn is created when connection is established, before that chan is added only to global chan list. So if there is no connection we cannot get lock in conn->chan_lock. I believe that it is better to keep locking inside of chan_del. 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
