skput - kernel panic

Eddie Kohler kohler at icir.org
Fri Feb 8 15:54:11 EST 2002


>  The below errors seem to because of my bad 
>  code. I fixed that and now it seems to work 
>  fine but after some time i m getting
>  the skput:over kernel panic again.
> 
>  Can anyone point me a documentation or
>  briefly tell me why this panic occurs.

The skput:over panic occurs when someone tries to push additional space
onto the end of the packet, but there is not enough space. Generally Click
will prevent this situation, but if you are making Linux calls (like
skb_put()), you might encounter it.

We've also seen this panic occur on multiprocessor machines when
configurations are swapped in. This was due to a locking error that should
be fixed now.

The code you are writing seems like it might be a little convoluted.

> >   I m maintaining a buffer that buffer packets for
> >   a brief time to make some decision. I m storing
> >   the packet to the buffer as follows.
> > 
> >   buff -> packet = (Packet *) p -> uniqueify().

You don't need to uniqueify a packet before storing it.

> >   So i have done the following to send:
> > 
> >   Packet *p = (Packet *)Packet::make(p_tmp -> 
> >                                    steal_skb());
> > 
> >    output(0).push(p);

This is a bad idea. The packet you already have is perfectly suitable for
sending. You don't need to do a Packet::make(p->steal_skb()).

> >   When i do this seems like output(0).push(p) is
> >   working but when i tried to free the buff , click
> >   is crashing.

Where are you trying to free the buff? Once you push a packet out, *you are
no longer allowed to touch it*. The elements downstream will free it
themselves. If you want to keep a copy of the packet, use

       output(0).push(p->clone());

or, even better,

       if (Packet *q = p->clone())
           output(0).push(q);

(to check for null pointers).

Eddie



More information about the click mailing list