---

yaml
---
r: 14257
b: refs/heads/master
c: 31f3426
h: refs/heads/master
i:
  14255: 9d077f1
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: cf225356578326308b16a0fd03ff3fa72fe3da07
+refs/heads/master: 31f3426904e066f17e3f88c468a2f7c869ad4aac

trunk/include/net/tcp.h

@@ -552,8 +552,8 @@ extern u32	__tcp_select_window(struct sock *sk);
 
 /* TCP timestamps are only 32-bits, this causes a slight
  * complication on 64-bit systems since we store a snapshot
- * of jiffies in the buffer control blocks below.  We decidedly
- * only use of the low 32-bits of jiffies and hide the ugly
+ * of jiffies in the buffer control blocks below.  We decided
+ * to use only the low 32-bits of jiffies and hide the ugly
  * casts with the following macro.
  */
 #define tcp_time_stamp		((__u32)(jiffies))

trunk/net/ipv4/tcp_input.c

@@ -367,7 +367,7 @@ static void tcp_rcv_rtt_update(struct tcp_sock *tp, u32 sample, int win_dep)
 		 * are stalled on filesystem I/O.
 		 *
 		 * Also, since we are only going for a minimum in the
-		 * non-timestamp case, we do not smoother things out
+		 * non-timestamp case, we do not smooth things out
 		 * else with timestamps disabled convergence takes too
 		 * long.
 		 */
@@ -546,7 +546,7 @@ static void tcp_rtt_estimator(struct sock *sk, const __u32 mrtt)
 	 *
 	 * Funny. This algorithm seems to be very broken.
 	 * These formulae increase RTO, when it should be decreased, increase
-	 * too slowly, when it should be increased fastly, decrease too fastly
+	 * too slowly, when it should be increased quickly, decrease too quickly
 	 * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
 	 * does not matter how to _calculate_ it. Seems, it was trap
 	 * that VJ failed to avoid. 8)