mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-30 11:41:38 -04:00
[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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
This commit is contained in:
parent
ddea7be0ec
commit
325ed82393
8 changed files with 15 additions and 26 deletions
|
|
@ -240,8 +240,8 @@ ipq_build_packet_message(struct ipq_queue_entry *entry, int *errp)
|
|||
|
||||
pmsg->packet_id = (unsigned long )entry;
|
||||
pmsg->data_len = data_len;
|
||||
pmsg->timestamp_sec = skb_tv_base.tv_sec + entry->skb->tstamp.off_sec;
|
||||
pmsg->timestamp_usec = skb_tv_base.tv_usec + entry->skb->tstamp.off_usec;
|
||||
pmsg->timestamp_sec = entry->skb->tstamp.off_sec;
|
||||
pmsg->timestamp_usec = entry->skb->tstamp.off_usec;
|
||||
pmsg->mark = entry->skb->nfmark;
|
||||
pmsg->hook = entry->info->hook;
|
||||
pmsg->hw_protocol = entry->skb->protocol;
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
Loading…
Reference in a new issue