Re: sk_buff misunderstanding?

Re: sk_buff misunderstanding?

[David S. Miller]

If you don't copy your new sk_buff members at skb_copy and
skb_clone time, nobody will ever see them.

sk_buff misunderstanding?

[Wolfgang Wegner]

Hi all,

i am trying to do some modification in the kernel to get some different
timestamp directly from a modified network driver, and am having some
difficulty (or maybe misunderstanding) with sk_buff's...

- struct sk_buff has a new member, struct ww_timestamp rcvtime, containing
  the actual timestamp and a flag is_valid
- the driver (currently orinoco.c from pcmcia_cs) is modified to fill
  the my_timestamp struct and sets is_valid.
- when passing the packet to a socket, this new timestamp is evaluated
  (in sock_recv_timestamp, where both sk_buff _and_ sock are known)

The problem is: in sock_recv_timestamp, is_valid is reset to 0 - and i
have no idea why.

Here are the last relevant lines in orinoco.c: (orinoco_ev_rx)
        /* WW_TIMESTAMP stuff */
        skb->rcvtime=rcvtime;
        printk("orinoco.c: skb=%p\n",skb);

        skb->rcvtime.is_valid=1;
        /* Pass the packet to the networking stack */
        netif_rx(skb);

Here is include/net/sock.h (tsbucket is an extension i made)
static __inline__ void
sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
{
        if (sk->rcvtstamp)
                put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP, sizeof(skb->stamp), &skb
->stamp);
        else
                sk->stamp = skb->stamp;
        if((sk->tsbucket))
          printk("skb=%p, timestamp.is_valid=%d!\n",skb,skb->rcvtime.is_valid);

My first idea was that maybe the skb is copied around before, so i put
some printk in skb_head_from_pool - but this seems not to be the case.
Here is what the kernel says: (no lines left out!)

May 24 08:55:43 licht kernel: skb_head_from_pool, skb=cfaa6d80
May 24 08:55:43 licht kernel: orinoco.c: skb=cfaa6d80
May 24 08:55:43 licht kernel: skb=cfaa6d80, timestamp.is_valid=0!
May 24 08:55:43 licht kernel: skb_head_from_pool, skb=cfaa6d80
May 24 08:55:43 licht kernel: skb_head_from_pool, skb=cf0fa200

I am out of ideas - anybody else?
(This must be some really stupid bug or misunderstanding of mine, i guess,
but i really have no idea what i overlooked.)

Any help is appreciated.

Thanks,
Wolfgang

Re: sk_buff misunderstanding?

[Wolfgang Wegner]

On Fri, May 24, 2002 at 12:52:59AM -0700, David S. Miller wrote:
> 
> If you don't copy your new sk_buff members at skb_copy and
> skb_clone time, nobody will ever see them.
thanks, David...

I forgot to mention that I do initialize the values in alloc_skb
and skb_headerinit, and copy them in skb_clone and copy_skb_header

Are there any more occurrences?

Wolfgang

sk_buff modification problem

[Wolfgang Wegner]

Hi,

as my first post was a bit confused maybe, I try again - hopefully
more specific...

i am trying to do a modification in the kernel to get a more precise
timestamp directly from a modified network driver, and am having some
difficulty (or maybe misunderstanding) with sk_buff's... Kernel used
is 2.4.18.

Here's a list what I modified:

- struct sk_buff has a new member, struct ww_timestamp rcvtime, containing
  the actual timestamp and a flag is_valid. The flag is initialized to
  "0" in alloc_skb as well as skb_headerinit, and the complete struct
  is copied in skb_clone and copy_skb_header.
- the driver (currently orinoco.c from pcmcia_cs) is modified to fill
  the my_timestamp struct and sets is_valid.
- when passing the packet to a socket, this new timestamp is evaluated
  (in sock_recv_timestamp, where both sk_buff _and_ sock are known)

The problem is: in sock_recv_timestamp, is_valid is reset to 0 - and i
have no idea why. To track it down I tried to put some printk's in the
sk_buff handling functions and sock_recv_timestamp, but it seems there
is not even any copying done (as "&skb" is the same in orinoco.c and
sock_recv_timestamp):

> May 24 08:55:43 licht kernel: skb_head_from_pool, skb=cfaa6d80
> May 24 08:55:43 licht kernel: orinoco.c: skb=cfaa6d80
> May 24 08:55:43 licht kernel: skb=cfaa6d80, timestamp.is_valid=0!
> May 24 08:55:43 licht kernel: skb_head_from_pool, skb=cfaa6d80
> May 24 08:55:43 licht kernel: skb_head_from_pool, skb=cf0fa200

In case somebody wants to look at it, the patch is at
http://www-kt.e-technik.uni-dortmund.de/m_ww/l-k/patch-2.4.18-ww3.gz
and the orinoco_ev_rx part of orinoco.c is at
http://www-kt.e-technik.uni-dortmund.de/m_ww/l-k/orinoco.c

I am really out of ideas here, especially I do not know how to
debug it, because I do not see any further possibility where (and
why) the value gets overwritten.

Thanks,
Wolfgang

Re: sk_buff modification problem -> (almost) solved

[Wolfgang Wegner]

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

Re: sk_buff modification problem -> (almost) solved

[kuznet]

Hello!

> 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?

But _what_ did you change to make this working? Does this not imply
the answer?

Anyway, it would be better if you showed relevant patches.

Alexey