On 10/15/2014 05:53 PM, Alexander Aring wrote: > Hi Peter, > > On Wed, Oct 15, 2014 at 04:46:24PM -0400, Peter Hurley wrote: > ... >> >> That's happening because 6lowpan.c:send_mcast_pkt() is disabling >> interrupts with the read_lock_irqsave() before calling send_pkt(). >> >> It's unclear browsing through the lowpan driver why the >> irqflags save/restore read_lock flavors are being used; is there a >> place where the bluetooth core is calling the driver in atomic >> context (ie., where interrupts are disabled)? >> > > In my opinion bt_xmit is called in atomic context. Make the stacktrace > sense now? I don't think so. The network layer is very careful about keeping interrupts enabled and calling network drivers from softirq, so that spin_lock_bh() is typically all that's required. > It's the callback 'ndo_start_xmit' of 'struct net_device_ops' [0]. The send_mcast_pkt() isn't showing in the stack trace because it's being inlined; and send_mcast_pkt() is definitely disabling interrupts and calling send_pkt(). Regards, Peter Hurley -- 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
