Hi Jukka,
>>> +static struct sk_buff *bt_6lowpan_chan_alloc_skb_cb(struct l2cap_chan *chan,
>>> + unsigned long len, int nb)
>>> +{
>>> + return bt_skb_alloc(len, GFP_ATOMIC);
>>
>> Does this have to be GFP_ATOMIC?
>>
>
> Yep, I see "BUG: sleeping function called from invalid context..."
> without it.
should we fix the caller? I am curious why this is possible in the first place. The whole Bluetooth subsystem should run in a workqueue these days. Do we have by any chance the wrong lock hold at this point or why is this happening.
If we really need to keep GFP_ATOMIC here then you need to add a comment on why that is. Because otherwise we will forget about it next time around.
Regards
Marcel
--
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
