Hi,
On Monday 26 May 2014 14:46:37 Marcel Holtmann wrote:
> 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.
FWIW this is due to holding hci_dev_list_lock which is RW_LOCK. For similar
reason there is GFP_ATOMIC in read_index_list() in mgmt.c.
--
Szymon K. Janc
szymon.janc@xxxxxxxxx
--
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
