Bug caused by multicast

[Teto]

Thanks a lot you were right. The worse is I had setup a timer to test that
function but this is the timer which creates a sotfirq and thus the stack
trace. I've removed it and it works ok.

Thank you.


On Tue, Apr 2, 2013 at 10:11 AM, Thomas Graf <tgraf at suug.ch> wrote:

> On 04/01/13 at 07:09pm, Teto wrote:
> > and caused by the following code. The family and ops are correctly
> > registered, I've created the multicast group beforehand. It seems it does
> > work when there is a client registered in this multicast group but if
> there
> > isn't any client, it returns -3. The return code is fine with me but I
> > don't understand why there is this stack trace though.
> >
> >
> > /**
> > send the request
> > **/
> > int send_request_for_eid(u32 eid)
> > {
> >     //!
> >     struct sk_buff *skb;
> >     int rc = 0;
> >     void *msg_head;
> >
> >     printk( "sending request for eid %u.%u.%u.%u.\n", NIPQUAD(eid) );
> >
> >
> >     /* send a message back*/
> >     /* allocate some memory, since the size is not yet known use
> > NLMSG_GOODSIZE*/
> >     skb = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>
> Looks like you are calling this function in (sw) interrupt context.
> If you do that you will have to pass GFP_ATOMIC into genlmsg_new()
> just like you would have to with kmalloc()
>
> Sames goes for genlmsg_multicast() below.
>
> If somehow doable I would advice you to create a worker though
> and send your messages from there.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130402/7a4124d2/attachment.html>