netdev - Re: trying to set skb->tstamp before netif_rx did not work in tun/tap driver, 2.6.27

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1310103900.2517.2.camel@edumazet-laptop>
Date:	Fri, 08 Jul 2011 07:45:00 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Bill F <falcigno@...o.com>
Cc:	netdev@...r.kernel.org
Subject: Re: trying to set skb->tstamp before netif_rx did not work in
 tun/tap driver, 2.6.27

Le vendredi 08 juillet 2011 à 02:33 +0000, Bill F a écrit :
> Hi all,
>  
> I am trying to set the receive timestamp for a packet in the tun/tap device
> driver before sending it into the network stack (by calling netif_rx_ni). On the 
> application side I'm using recvmsg() to receive the timestamp along with the 
> received packet.
>  
> I expected that any non-zero skb->tstamp I set would be the value my 
> application would see when it used recvmsg(), but a corrupted value is 
> coming out.
> * If I hardcode skb->tstamp.tv64 to x7777777766666666 
>         then recvmsg() always gets x011afd371a82fcc0.
> * If I hardcode x4de684b100000000, 
>         then recvmsg always gets x4f5f96640f2d1608.
> * If I set a timestamp that a different process gave to the tun/tap driver
>         (this is the goal), then recvmsg gets a corrupted version of that 
>         timestamp.
> * If I hardcode a zero tstamp, 
>         then an accurate timestamp comes out (but not precise enough for my 
>         project).
>  
> The kernel build is 2.6.27.7, the architecture is MIPS, 64bit. Shouldn't this 
> work? Do I need to apply any known patches?
>  
> This arrangement worked last month in a similar setup: an e1000 driver 
> setting tstamp before calling netif_receive_skb() in a 2.6.24 kernel and a 
> 686 architecture, 32 bit.
>  

You probably are hardcoding too much things ;)

The only portable tv64 value is the zero one.

Check CONFIG_KTIME_SCALAR on your config, and ktime_set()
implementations in include/linux/ktime.h



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html