Re: sk_buff modification problem -> (almost) solved

[Wolfgang Wegner <ww@kt.e-technik.uni-dortmund.de>]

Hi,

I finally found the source of the problem, and was such able to solve
it for me. Unfortunately, I do not really understand, why all this
behaves that way.

In short:
I inserted a new member into struct sk_buff, which was filled in in the
driver (orinoco.c) and should be evaluated "upstairs". However, the contents
of this field was already lost in netif_rx...

(Like this:
[orinoco.c, orinoco_ev_rx]
        skb->rcvtime.is_valid=1; 
        printk("orinoco.c: skb=%p, is_valid=%d\n",skb,skb->rcvtime.is_valid);
        netif_rx(skb);

[linux/net/core/dev.c]
int netif_rx(struct sk_buff *skb)
{
        int this_cpu = smp_processor_id();
        struct softnet_data *queue;
        unsigned long flags;

        if (skb->stamp.tv_sec == 0)
                do_gettimeofday(&skb->stamp);

        printk("netif_rx: skb=%p, is_valid=%d\n",skb,skb->rcvtime.is_valid);

dmesg:
May 26 14:41:05 licht kernel: orinoco.c: skb=c3d40d80, is_valid=1
May 26 14:41:05 licht kernel: netif_rx: skb=c3d40d80, is_valid=0
May 26 14:41:05 licht kernel: orinoco.c: skb=c3d400c0, is_valid=1
May 26 14:41:05 licht kernel: netif_rx: skb=c3d400c0, is_valid=0
...and so on)

It turned out to be a problem with the pcmcia-cs-3.1.33 package i was using,
now i modified the in-kernel orinoco driver to generate the timestamps i want,
and everything works as expected.

What i do not understand is how such a behaviour can evolve, without any
compiler warning?
Just post it again because i really would be interested which trap i ran
into here... ;-)

Wolfgang