Searched hist:f85958151900f9d30fa5ff941b0ce71eaa45a7de (Results 1 – 1 of 1) sorted by relevance
| /linux/drivers/char/ |
| H A D | random.c | diff 9b42c336d06411e6463949d2dac63949f66ff70b Mon Oct 01 22:58:36 CEST 2007 Eric Dumazet <dada1@cosmosbay.com> [TCP]: secure_tcp_sequence_number() should not use a too fast clock
TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock.
In order to follow network speed increase, we can use a faster clock, but
we should limit this clock so that the delay between two rollovers is
greater than MSL (TCP Maximum Segment Lifetime : 2 minutes)
Choosing a 64 nsec clock should be OK, since the rollovers occur every
274 seconds.
Problem spotted by Denys Fedoryshchenko
[ This bug was introduced by f85958151900f9d30fa5ff941b0ce71eaa45a7de ]
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff f85958151900f9d30fa5ff941b0ce71eaa45a7de Wed Mar 28 23:22:33 CEST 2007 Eric Dumazet <dada1@cosmosbay.com> [NET]: random functions can use nsec resolution instead of usec
In order to get more randomness for secure_tcpv6_sequence_number(),
secure_tcp_sequence_number(), secure_dccp_sequence_number() functions,
we can use the high resolution time services, providing nanosec
resolution.
I've also done two kmalloc()/kzalloc() conversions.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|