Hi, On Mon, Nov 10, 2014, johan.hedberg@xxxxxxxxx wrote: > + /* smp_conn_security() will call l2cap_chan_lock() - > + * never for any CoC channel but only for the SMP > + * channel. However, this will still trigger lockdep > + * warnings of recursive locking, so to avoid these > + * unlock the channel here instead of after the call to > + * smp_conn_security(). > + */ > + sec_level = chan->sec_level; > + l2cap_chan_unlock(chan); > + > + smp_conn_security(hcon, sec_level); > + goto unlock; It's might be possible to avoid this "hack" by using nested locking annotation, so you might want to hold off with this patch for now. I'm right now experimenting in making the rather simple change of using mutex_lock_nested(&chan->lock, chan->chan_type) in l2cap_chan_lock() to classify channels into separate groups based on their type. This should allow simultaneous CoC and SMP (fixed channel) lock acquisition without getting (false positive) warnings from lockdep. Johan -- 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
