aboutsummaryrefslogtreecommitdiff
path: root/net/ipv4/netfilter/ipt_ULOG.c
diff options
context:
space:
mode:
authorHerbert Xu <herbert@gondor.apana.org.au>2005-10-03 13:57:23 -0700
committerDavid S. Miller <davem@davemloft.net>2005-10-03 13:57:23 -0700
commit325ed8239309cb29f10ea58c5a668058ead11479 (patch)
tree77386825b72ac44f4f42a942ef78bd1ff924b351 /net/ipv4/netfilter/ipt_ULOG.c
parentddea7be0ec8d1374f0b483a81566ed56ec9f3905 (diff)
downloadlinux-stericsson-325ed8239309cb29f10ea58c5a668058ead11479.tar.gz
[NET]: Fix packet timestamping.
I've found the problem in general. It affects any 64-bit architecture. The problem occurs when you change the system time. Suppose that when you boot your system clock is forward by a day. This gets recorded down in skb_tv_base. You then wind the clock back by a day. From that point onwards the offset will be negative which essentially overflows the 32-bit variables they're stored in. In fact, why don't we just store the real time stamp in those 32-bit variables? After all, we're not going to overflow for quite a while yet. When we do overflow, we'll need a better solution of course. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/netfilter/ipt_ULOG.c')
-rw-r--r--net/ipv4/netfilter/ipt_ULOG.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/net/ipv4/netfilter/ipt_ULOG.c b/net/ipv4/netfilter/ipt_ULOG.c
index e2c14f3cb2fc..2883ccd8a91d 100644
--- a/net/ipv4/netfilter/ipt_ULOG.c
+++ b/net/ipv4/netfilter/ipt_ULOG.c
@@ -225,8 +225,8 @@ static void ipt_ulog_packet(unsigned int hooknum,
/* copy hook, prefix, timestamp, payload, etc. */
pm->data_len = copy_len;
- pm->timestamp_sec = skb_tv_base.tv_sec + skb->tstamp.off_sec;
- pm->timestamp_usec = skb_tv_base.tv_usec + skb->tstamp.off_usec;
+ pm->timestamp_sec = skb->tstamp.off_sec;
+ pm->timestamp_usec = skb->tstamp.off_usec;
pm->mark = skb->nfmark;
pm->hook = hooknum;
if (prefix != NULL)