From 9d6ed637d06b890c020cb2113cb516b384ea3669 Mon Sep 17 00:00:00 2001 From: Eric Dumazet Date: Mon, 1 Oct 2007 13:58:36 -0700 Subject: [PATCH] --- yaml --- r: 65246 b: refs/heads/master c: 9b42c336d06411e6463949d2dac63949f66ff70b h: refs/heads/master v: v3 --- [refs] | 2 +- trunk/drivers/char/random.c | 10 ++++++---- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/[refs] b/[refs] index 26b1403697f9..a4641b5f1e63 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 32740ddc1095e5e320bf961dda146bf97bc28adb +refs/heads/master: 9b42c336d06411e6463949d2dac63949f66ff70b diff --git a/trunk/drivers/char/random.c b/trunk/drivers/char/random.c index 397c714cf2ba..af274e5a25ee 100644 --- a/trunk/drivers/char/random.c +++ b/trunk/drivers/char/random.c @@ -1550,11 +1550,13 @@ __u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr, * As close as possible to RFC 793, which * suggests using a 250 kHz clock. * Further reading shows this assumes 2 Mb/s networks. - * For 10 Gb/s Ethernet, a 1 GHz clock is appropriate. - * That's funny, Linux has one built in! Use it! - * (Networks are faster now - should this be increased?) + * For 10 Mb/s Ethernet, a 1 MHz clock is appropriate. + * For 10 Gb/s Ethernet, a 1 GHz clock should be ok, but + * we also need to limit the resolution so that the u32 seq + * overlaps less than one time per MSL (2 minutes). + * Choosing a clock of 64 ns period is OK. (period of 274 s) */ - seq += ktime_get_real().tv64; + seq += ktime_get_real().tv64 >> 6; #if 0 printk("init_seq(%lx, %lx, %d, %d) = %d\n", saddr, daddr, sport, dport, seq);