325ed82393
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> |
||
---|---|---|
.. | ||
ip6_queue.c | ||
ip6_tables.c | ||
ip6t_ah.c | ||
ip6t_dst.c | ||
ip6t_esp.c | ||
ip6t_eui64.c | ||
ip6t_frag.c | ||
ip6t_hbh.c | ||
ip6t_HL.c | ||
ip6t_hl.c | ||
ip6t_ipv6header.c | ||
ip6t_length.c | ||
ip6t_limit.c | ||
ip6t_LOG.c | ||
ip6t_mac.c | ||
ip6t_MARK.c | ||
ip6t_mark.c | ||
ip6t_multiport.c | ||
ip6t_NFQUEUE.c | ||
ip6t_owner.c | ||
ip6t_physdev.c | ||
ip6t_REJECT.c | ||
ip6t_rt.c | ||
ip6table_filter.c | ||
ip6table_mangle.c | ||
ip6table_raw.c | ||
Kconfig | ||
Makefile |