It is not correct to assume one can get nsec from a ktime directly by 
using .tv64 field.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>


[ message continues ]

From: Eric Dumazet <dada1@cosmosbay.com>

Patrick, this is very clearly a correct bug fix, so I'm
going to apply this directly.

Applied, thanks Eric.
-

[ message continues ]

Thanks, thats obviously correct. Still, I would prefer if
people would CC netfilter-devel and myself, it has become
a bad habit lately especially to skip netfilter-devel.

-

[ message continues ]

Sorry for forgeting netfilter-devel, I'll try to remember for next time...

Thank you




-

[ message continues ]

Thanks Eric. I missed that I actually was CCed because greylisting
took a bit longer to let it through :)
-

[ message continues ]

I discovered one other incorrect use of .tv64 (coming from me, I must 
confess)

I guess this patch is  needed for 2.6.24 and stable (2.6.22 & 2.6.23)

Thank you

[NET] random : secure_tcp_sequence_number should not assume 
CONFIG_KTIME_SCALAR

All 32 bits machines but i386 dont have CONFIG_KTIME_SCALAR. On these 
machines, ktime.tv64
is more than 4 times the (correct) result given by ktime_to_ns()

Again on these machines, using ktime_get_real().tv64 >> 6 give a 32bits 
rollover every 64 seconds,
which is not wanted (less than the 120 s MSL)

Using ktime_to_ns() is the portable way to get nsecs from a ktime, and 
have correct code.


Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

[ message continues ]

From: Eric Dumazet <dada1@cosmosbay.com>

Applied thanks Eric, I'll queue it up for -stable too.

Perhaps ktime_t->tv64 should be renamed to "->__tv64" or
similar to prevent future mistakes like this.  Only
the ktime implementation should be touching that thing.
-

[ message continues ]

Thanks for sending this to stable@, but David does a great job of
forwarding these to us, so I'll wait for him to relay it to us before
taking it into our tree.

thanks,

greg k-h
-

[ message continues ]