TCPCT part1: cookie option exchange

Updated to patch cleanly with recent commits.

Changes from previous version:
* Strongly type otherwise void parameter with empty struct.
* Combined two shorter patches (b + c), dropping update of 2 drivers, as nobody has gotten back to me about testing results.
* Added a little Documentation for new sysctl.

Add optional function parameters associated with sending SYNACK. These parameters are not needed after sending SYNACK, and are not used for retransmission. Avoids extending struct tcp_request_sock, and avoids allocating kernel memory.

Also affects DCCP as it uses common struct request_sock_ops, but this parameter is currently reserved for future use.

---
 include/net/request_sock.h      |    8 +++++++-
 include/net/tcp.h               |    1 +
 net/dccp/ipv4.c                 |    5 +++--
 net/dccp/ipv6.c                 |    5 +++--
 net/dccp/minisocks.c            |    2 +-
 net/ipv4/inet_connection_sock.c |    2 +-
 net/ipv4/tcp_ipv4.c             |   11 +++++++----
 net/ipv4/tcp_minisocks.c        |    2 +-
 net/ipv4/tcp_output.c           |    1 +
 net/ipv6/tcp_ipv6.c             |   14 +++++++-------
 10 files changed, 32 insertions(+), 19 deletions(-)

index c719084..c9b50eb 100644
@@ -27,13 +27,19 @@ struct sk_buff;
 struct dst_entry;
 struct proto;
 
+/* empty to "strongly type" an otherwise void parameter.
+ */
+struct request_values {
+};
+
 struct request_sock_ops {
 	int		family;
 	int		obj_size;
 	struct kmem_cache	*slab;
 	char		*slab_name;
 	int		(*rtx_syn_ack)(struct sock *sk,
-				       struct request_sock *req);
+				       struct request_sock *req,
+				       struct request_values *rvp);
 	void		(*send_ack)(struct sock *sk, struct sk_buff *skb,
 				    struct request_sock *req);
 	void		(*send_reset)(struct sock *sk,

index 03a49c7..4abdb4d 100644
@@ -443,6 +443,7 @@ extern int			tcp_connect(struct sock *sk);
 
 extern struct sk_buff *		tcp_make_synack(struct sock *sk,
 						struct dst_entry *dst,
+						struct request_values *rvp,
 						struct request_sock *req);
 
 extern int			tcp_disconnect(struct sock *sk, int flags);

index 00028d4..8d4a88a 100644
@@ -477,7 +477,8 @@ static struct dst_entry* dccp_v4_route_skb(struct net *net, struct sock *sk,
 	return &rt->u.dst;
 }
 
-static int dccp_v4_send_response(struct sock *sk, struct request_sock *req)
+static int dccp_v4_send_response(struct sock *sk, struct request_sock *req,
+				 struct request_values *rv_unused)
 {
 	int err = -1;
 	struct sk_buff *skb;

@@ -626,7 +627,7 @@ int dccp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 	dreq->dreq_iss	   = dccp_v4_init_sequence(skb);
 	dreq->dreq_service = service;
 
-	if (dccp_v4_send_response(sk, req))
+	if (dccp_v4_send_response(sk, req, NULL))
 		goto drop_and_free;
 
 	inet_csk_reqsk_queue_hash_add(sk, req, DCCP_TIMEOUT_INIT);

index 6d89f9f..f64981e 100644
@@ -241,7 +241,8 @@ out:
 }
 
 
-static int dccp_v6_send_response(struct sock *sk, struct request_sock *req)
+static int dccp_v6_send_response(struct sock *sk, struct request_sock *req,
+				 struct request_values *rv_unused)
 {
 	struct inet6_request_sock *ireq6 = inet6_rsk(req);
 	struct ipv6_pinfo *np = inet6_sk(sk);

@@ -468,7 +469,7 @@ static int dccp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
 	dreq->dreq_iss	   = dccp_v6_init_sequence(skb);
 	dreq->dreq_service = service;
 
-	if (dccp_v6_send_response(sk, req))
+	if (dccp_v6_send_response(sk, req, NULL))
 		goto drop_and_free;
 
 	inet6_csk_reqsk_queue_hash_add(sk, req, DCCP_TIMEOUT_INIT);

index 5ca49ce..af226a0 100644
@@ -184,7 +184,7 @@ struct sock *dccp_check_req(struct sock *sk, struct sk_buff *skb,
 			 * counter (backoff, monitored by dccp_response_timer).
 			 */
 			req->retrans++;
-			req->rsk_ops->rtx_syn_ack(sk, req);
+			req->rsk_ops->rtx_syn_ack(sk, req, NULL);
 		}
 		/* Network Duplicate, discard packet */
 		return NULL;

index f6a0af7..b81d3c9 100644
@@ -504,7 +504,7 @@ void inet_csk_reqsk_queue_prune(struct sock *parent,
 			if (time_after_eq(now, req->expires)) {
 				if ((req->retrans < thresh ||
 				     (inet_rsk(req)->acked && req->retrans < max_retries))
-				    && !req->rsk_ops->rtx_syn_ack(parent, req)) {
+				    && !req->rsk_ops->rtx_syn_ack(parent, req, NULL)) {
 					unsigned long timeo;
 
 					if (req->retrans++ == 0)

index a4a3390..6edc5e2 100644
@@ -743,6 +743,7 @@ static void tcp_v4_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
  *	socket.
  */
 static int __tcp_v4_send_synack(struct sock *sk, struct request_sock *req,
+				struct request_values *rvp,
 				struct dst_entry *dst)
 {
 	const struct inet_request_sock *ireq = inet_rsk(req);

@@ -753,7 +754,7 @@ static int __tcp_v4_send_synack(struct sock *sk, struct request_sock *req,
 	if (!dst && (dst = inet_csk_route_req(sk, req)) == NULL)
 		return -1;
 
-	skb = tcp_make_synack(sk, dst, req);
+	skb = tcp_make_synack(sk, dst, rvp, req);
 
 	if (skb) {
 		struct tcphdr *th = tcp_hdr(skb);

@@ -774,9 +775,10 @@ static int __tcp_v4_send_synack(struct sock *sk, struct request_sock *req,
 	return err;
 }
 
-static int tcp_v4_send_synack(struct sock *sk, struct request_sock *req)
+static int tcp_v4_send_synack(struct sock *sk, struct request_sock *req,
+			      struct request_values *rvp)
 {
-	return __tcp_v4_send_synack(sk, req, NULL);
+	return __tcp_v4_send_synack(sk, req, rvp, NULL);
 }
 
 /*

@@ -1334,7 +1336,8 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 	}
 	tcp_rsk(req)->snt_isn = isn;
 
-	if (__tcp_v4_send_synack(sk, req, dst) || want_cookie)
+	if (__tcp_v4_send_synack(sk, req, NULL, dst) ||
+	    want_cookie)
 		goto drop_and_free;
 
 	inet_csk_reqsk_queue_hash_add(sk, req, TCP_TIMEOUT_INIT);

index e320afe..8819882 100644
@@ -537,7 +537,7 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
 		 * Enforce "SYN-ACK" according to figure 8, figure 6
 		 * of RFC793, fixed by RFC1122.
 		 */
-		req->rsk_ops->rtx_syn_ack(sk, req);
+		req->rsk_ops->rtx_syn_ack(sk, req, NULL);
 		return NULL;
 	}
 

index 2e2eb74..79042f4 100644
@@ -2219,6 +2219,7 @@ int tcp_send_synack(struct sock *sk)
 
 /* Prepare a SYN-ACK. */
 struct sk_buff *tcp_make_synack(struct sock *sk, struct dst_entry *dst,
+				struct request_values *rvp,
 				struct request_sock *req)
 {
 	struct inet_request_sock *ireq = inet_rsk(req);

index c54ec36..3960d72 100644
@@ -461,7 +461,8 @@ out:
 }
 
 
-static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req)
+static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req,
+			      struct request_values *rvp)
 {
 	struct inet6_request_sock *treq = inet6_rsk(req);
 	struct ipv6_pinfo *np = inet6_sk(sk);

@@ -499,7 +500,7 @@ static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req)
 	if ((err = xfrm_lookup(sock_net(sk), &dst, &fl, sk, 0)) < 0)
 		goto done;
 
-	skb = tcp_make_synack(sk, dst, req);
+	skb = tcp_make_synack(sk, dst, rvp, req);
 	if (skb) {
 		struct tcphdr *th = tcp_hdr(skb);
 

@@ -1243,13 +1244,12 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
 
 	security_inet_conn_request(sk, skb, req);
 
-	if (tcp_v6_send_synack(sk, req))
+	if (tcp_v6_send_synack(sk, req, NULL) ||
+	    want_cookie)
 		goto drop;
 
-	if (!want_cookie) {
-		inet6_csk_reqsk_queue_hash_add(sk, req, TCP_TIMEOUT_INIT);
-		return 0;
-	}
+	inet6_csk_reqsk_queue_hash_add(sk, req, TCP_TIMEOUT_INIT);
+	return 0;
 
 drop:
 	if (req)

1.6.0.4

Define sysctl (tcp_cookie_size) to turn on and off the cookie option default globally, instead of a compiled configuration option.

Define per socket option (TCP_COOKIE_TRANSACTIONS) for setting constant data values, retrieving variable cookie values, and other facilities.

Redefine two TCP header functions to accept TCP header pointer. When subtracting, return signed int to allow error checking.

Move inline tcp_clear_options() unchanged from net/tcp.h to linux/tcp.h, near its corresponding struct tcp_options_received (prior to changes).

This is a straightforward re-implementation of an earlier (year-old) patch that no longer applies cleanly, with permission of the original author (Adam Langley). The patch was previously reviewed:

http://thread.gmane.org/gmane.linux.network/102586

These functions will also be used in subsequent patches that implement additional features.

---
 Documentation/networking/ip-sysctl.txt |    8 +++++
 include/linux/tcp.h                    |   47 +++++++++++++++++++++++++++++++-
 include/net/tcp.h                      |    6 +---
 net/ipv4/sysctl_net_ipv4.c             |    8 +++++
 net/ipv4/tcp_output.c                  |    8 +++++
 5 files changed, 71 insertions(+), 6 deletions(-)

index a0e134d..d47c000 100644
@@ -164,6 +164,14 @@ tcp_congestion_control - STRING
 	additional choices may be available based on kernel configuration.
 	Default is set as part of kernel configuration.
 
+tcp_cookie_size - INTEGER
+	Default size of TCP Cookie Transactions (TCPCT) option, that may be
+	overridden on a per socket basis by the TCPCT socket option.
+	Values greater than the maximum (16) are interpreted as the maximum.
+	Values greater than zero and less than the minimum (8) are interpreted
+	as the minimum.
+	Default: 0 (off).
+
 tcp_dsack - BOOLEAN
 	Allows TCP to send "duplicate" SACKs.
 

index 4abdb4d..142f32e 100644
@@ -237,6 +237,7 @@ extern int sysctl_tcp_base_mss;
 extern int sysctl_tcp_workaround_signed_windows;
 extern int sysctl_tcp_slow_start_after_idle;
 extern int sysctl_tcp_max_ssthresh;
+extern int sysctl_tcp_cookie_size;
 
 extern atomic_t tcp_memory_allocated;
 extern struct percpu_counter tcp_sockets_allocated;

@@ -343,11 +344,6 @@ static inline void tcp_dec_quickack_mode(struct sock *sk,
 
 extern void tcp_enter_quickack_mode(struct sock *sk);
 
-static inline void tcp_clear_options(struct tcp_options_received *rx_opt)
-{
- 	rx_opt->tstamp_ok = rx_opt->sack_ok = rx_opt->wscale_ok = rx_opt->snd_wscale = 0;
-}
-
 #define	TCP_ECN_OK		1
 #define	TCP_ECN_QUEUE_CWR	2
 #define	TCP_ECN_DEMAND_CWR	4

index 2dcf04d..3422c54 100644
@@ -714,6 +714,14 @@ static struct ctl_table ipv4_table[] = {
 	},
 	{
 		.ctl_name	= CTL_UNNUMBERED,
+		.procname	= "tcp_cookie_size",
+		.data		= &sysctl_tcp_cookie_size,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec
+	},
+	{
+		.ctl_name	= CTL_UNNUMBERED,
 		.procname	= "udp_mem",
 		.data		= &sysctl_udp_mem,
 		.maxlen		= sizeof(sysctl_udp_mem),

index 79042f4..bcfbe41 100644
@@ -59,6 +59,14 @@ int sysctl_tcp_base_mss __read_mostly = 512;
 /* By default, RFC2861 behavior.  */
 int sysctl_tcp_slow_start_after_idle __read_mostly = 1;
 
+#ifdef CONFIG_SYSCTL
+/* By default, let the user enable it. */
+int sysctl_tcp_cookie_size __read_mostly = 0;
+#else
+int sysctl_tcp_cookie_size __read_mostly = TCP_COOKIE_MAX;
+#endif
+
+
 /* Account for new data that has been sent to the network. */
 static void tcp_event_new_data_sent(struct sock *sk, struct sk_buff *skb)
 {

1.6.0.4

+#define TCP_EXTEND_TIMESTAMP (1 << 4) /* Initiate 64-bit timestamps */

What is this for ?

Reserving a bit in the sockopt for a future feature (described in the aforementioned end2end-interest email messages).

Certainly, reserving bits seems to be common elsewhere in Linux code. I'm trying to coordinate this with the *BSD developers, too, so it helps to keep API documentation synchronized. Is that a problem?

From: William Allen Simpson <[email protected]>
Date: Mon, 02 Nov 2009 05:45:22 -0500

Yes, it is a problem.

You can allocate the bit when you add the feature.

Sadly, I've been having very bad luck in my choice of code base, and reviewing other similar code -- it seemed the common practice was to specify the interface completely (even those bits not yet used).

I'll remove that line in the next pass.

This is a significantly revised implementation of an earlier (year-old) patch that no longer applies cleanly, with permission of the original author (Adam Langley). That patch was previously reviewed:

http://thread.gmane.org/gmane.linux.network/102586

The principle difference is using a TCP option to carry the cookie nonce, instead of a user configured offset in the data. This is more flexible and less subject to user configuration error. Such a cookie option has been suggested for many years, and is also useful without SYN data, allowing several related concepts to use the same extension option.

"Re: SYN floods (was: does history repeat itself?)", September 9, 1996.
http://www.merit.net/mail.archives/nanog/1996-09/msg00235.html

"Re: what a new TCP header might look like", May 12, 1998. ftp://ftp.isi.edu/end2end/end2end-interest-1998.mail

Data structures are carefully composed to require minimal additions. For example, the struct tcp_options_received cookie_plus variable fits between existing 16-bit and 8-bit variables, requiring no additional space (taking alignment into consideration). There are no additions to tcp_request_sock, and only 1 pointer and 1 flag byte in tcp_sock.

Allocations have been rearranged to avoid requiring GFP_ATOMIC, with only one unavoidable exception in tcp_create_openreq_child(), where the tcp_sock itself is created GFP_ATOMIC.

These functions will also be used in subsequent patches that implement additional features.

Requires:
TCPCT part 1a: add request_values parameter for sending SYNACK
TCPCT part 1b: sysctl_tcp_cookie_size, socket option TCP_COOKIE_TRANSACTIONS, functions

---
 include/linux/tcp.h      |   34 ++++++-
 include/net/tcp.h        |   67 +++++++++++++-
 net/ipv4/syncookies.c    |    5 +-
 net/ipv4/tcp.c           |  128 +++++++++++++++++++++++++-
 net/ipv4/tcp_input.c     |   84 +++++++++++++++--
 net/ipv4/tcp_ipv4.c      |   62 +++++++++++--
 net/ipv4/tcp_minisocks.c |   43 +++++++--
 net/ipv4/tcp_output.c    |  227 +++++++++++++++++++++++++++++++++++++++++++---
 net/ipv6/syncookies.c    |    5 +-
 net/ipv6/tcp_ipv6.c      |   47 +++++++++-
 10 files changed, 639 insertions(+), 63 deletions(-)

index 6fd59d1..5da3ef4 100644
@@ -257,31 +257,36 @@ struct tcp_options_received {
 		sack_ok : 4,	/* SACK seen on SYN packet		*/
 		snd_wscale : 4,	/* Window scaling received from sender	*/
 		rcv_wscale : 4;	/* Window scaling to send to receiver	*/
-/*	SACKs data	*/
+	u8	cookie_plus:6;	/* bytes in authenticator/cookie option	*/
 	u8	num_sacks;	/* Number of SACK blocks		*/
-	u16	user_mss;  	/* mss requested by user in ioctl */
+	u16	user_mss;	/* mss requested by user in ioctl	*/
 	u16	mss_clamp;	/* Maximal mss, negotiated at connection setup */
 };
 
 static inline void tcp_clear_options(struct tcp_options_received *rx_opt)
 {
-	rx_opt->tstamp_ok = rx_opt->sack_ok = rx_opt->wscale_ok = rx_opt->snd_wscale = 0;
+	rx_opt->tstamp_ok = rx_opt->sack_ok = 0;
+	rx_opt->wscale_ok = rx_opt->snd_wscale = 0;
+	rx_opt->cookie_plus = 0;
 }
 
 /* This is the max number of SACKS that we'll generate and process. It's safe
- * to increse this, although since:
+ * to increase this, although since:
  *   size = TCPOLEN_SACK_BASE_ALIGNED (4) + n * TCPOLEN_SACK_PERBLOCK (8)
  * only four options will fit in a standard TCP header */
 #define TCP_NUM_SACKS 4
 
+struct tcp_cookie_values;
+struct tcp_request_sock_ops;
+
 struct tcp_request_sock {
 	struct inet_request_sock 	req;
 #ifdef CONFIG_TCP_MD5SIG
 	/* Only used by TCP MD5 Signature so far. */
 	const struct tcp_request_sock_ops *af_specific;
 #endif
-	u32			 	rcv_isn;
-	u32			 	snt_isn;
+	u32				rcv_isn;
+	u32				snt_isn;
 };
 
 static inline struct tcp_request_sock *tcp_rsk(const struct request_sock *req)

@@ -451,6 +456,19 @@ struct tcp_sock {
 /* TCP MD5 Signature Option information */
 	struct tcp_md5sig_info	*md5sig_info;
 #endif
+
+	/* When the cookie options are generated and exchanged, then this
+	 * object holds a reference to them (cookie_values->kref).  Also
+	 * contains related tcp_cookie_transactions fields.
+	 */
+	struct tcp_cookie_values  	*cookie_values;
+
+	u8				cookie_in_always:1,
+					cookie_out_never:1,
+					extend_timestamp:1,
+					s_data_constant:1,
+					s_data_in:1,
+					s_data_out:1;
 };
 
 static inline struct tcp_sock *tcp_sk(const struct sock *sk)

@@ -469,6 +487,10 @@ struct tcp_timewait_sock {
 	u16			  tw_md5_keylen;
 	u8			  tw_md5_key[TCP_MD5SIG_MAXKEYLEN];
 #endif
+	/* Few sockets in timewait have cookies; in that case, then this
+	 * object holds a reference to it (tw_cookie_values->kref)
+	 */
+	struct tcp_cookie_values  *tw_cookie_values;
 };
 
 static inline struct tcp_timewait_sock *tcp_twsk(const struct sock *sk)

index 5ec678a..cdab491 100644
@@ -253,6 +253,8 @@ EXPORT_SYMBOL(cookie_check_timestamp);
 struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb,
 			     struct ip_options *opt)
 {
+	struct tcp_options_received tcp_opt;
+	u8 *cryptic_value;
 	struct inet_request_sock *ireq;
 	struct tcp_request_sock *treq;
 	struct tcp_sock *tp = tcp_sk(sk);

@@ -263,7 +265,6 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb,
 	int mss;
 	struct rtable *rt;
 	__u8 rcv_wscale;
-	struct tcp_options_received tcp_opt;
 
 	if (!sysctl_tcp_syncookies || !th->ack)
 		goto out;

@@ -278,7 +279,7 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb,
 
 	/* check for timestamp cookie support */
 	memset(&tcp_opt, 0, sizeof(tcp_opt));
-	tcp_parse_options(skb, &tcp_opt, 0);
+	tcp_parse_options(skb, &tcp_opt, &cryptic_value, 0);
 
 	if (tcp_opt.saw_tstamp)
 		cookie_check_timestamp(&tcp_opt);

index c46da53..a0ad07b 100644
@@ -159,6 +159,8 @@ static inline int cookie_check(struct sk_buff *skb, __u32 cookie)
 
 struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb)
 {
+	struct tcp_options_received tcp_opt;
+	u8 *cryptic_value;
 	struct inet_request_sock *ireq;
 	struct inet6_request_sock *ireq6;
 	struct tcp_request_sock *treq;

@@ -171,7 +173,6 @@ struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb)
 	int mss;
 	struct dst_entry *dst;
 	__u8 rcv_wscale;
-	struct tcp_options_received tcp_opt;
 
 	if (!sysctl_tcp_syncookies || !th->ack)
 		goto out;

@@ -186,7 +187,7 @@ struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb)
 
 	/* check for timestamp cookie support */
 	memset(&tcp_opt, 0, sizeof(tcp_opt));
-	tcp_parse_options(skb, &tcp_opt, 0);
+	tcp_parse_options(skb, &tcp_opt, &cryptic_value, 0);
 
 	if (tcp_opt.saw_tstamp)
 		cookie_check_timestamp(&tcp_opt);

1.6.0.4

Sorry this link might be interesting to you, but I found nothing that explains your patches.

Same here....

I tried to find an RFC or document about this stuff and failed.

Before reading implementation code, I like to have english text that describes the new concept/design.

(BTW I found http://ttcplinux.sourceforge.net/theses/ETTCP.pdf and found it interesting, I wonder what happened to this)

They explain the "several related concepts" -- indeed the entire scope of the whole project. That's why this patch series is labeled "part 1".

This patch series was fairly clearly described in Adam's draft last year. It's expired now, but I'll send you a copy privately.

Before writing text, I like to have implementation code.... :-)

In fact, it has long been my position that we shouldn't publish IETF RFCs without running code (and I never have). Even PPP over SOnet/SDH had preliminary hardware before publication. Unfortunately, those with standards-bodies-itis have a sad history of the opposite.

The Usenix ;login: overview and other documents are embargoed until (December) publication, but I'll send you some recent galleys privately.

I found it too, and deliberately extended Adam's sockopt to encompass it. It's one reason this was renamed TCP Cookie *Transactions* (TCPCT). That will come along later, probably about parts 4 or 5.

This part is really hard to review, and might be splitted ?

cleanups could be done in a cleanup patch only

Examples:

- tmp_opt.mss_clamp = 536;
- tmp_opt.user_mss = tcp_sk(sk)->rx_opt.user_mss;
+ tmp_opt.mss_clamp = TCP_MIN_RCVMSS;
+ tmp_opt.user_mss = tp->rx_opt.user_mss;

- tp->mss_cache = 536;
+ tp->mss_cache = TCP_MIN_RCVMSS;

Also your tests are reversed, if you look at the existing coding style.

Example :

+ /* TCP Cookie Transactions */
+ if (0 < sysctl_tcp_cookie_size) {
+ /* Default, cookies without s_data. */
+ tp->cookie_values =
+ kzalloc(sizeof(*tp->cookie_values),
+ sk->sk_allocation);
+ if (NULL != tp->cookie_values)
+ kref_init(&tp->cookie_values->kref);
+ }

should be ->

+ /* TCP Cookie Transactions */
+ if (sysctl_tcp_cookie_size > 0) {
+ /* Default, cookies without s_data. */
+ tp->cookie_values =
+ kzalloc(sizeof(*tp->cookie_values),
+ sk->sk_allocation);
+ if (tp->cookie_values != NULL)
+ kref_init(&tp->cookie_values->kref);
+ }

I checked Documentation/CodingStyle, and that's not specified. I've seen plenty of examples of modern security coding style around here.

As a long-time (25+ years) consultant and 30 years C programmer, I'm heedful of the project coding style, and had to endure many variants.

Where I'm working with others' code, you'll note that I keep the same style, no matter how ugly, as that makes patches easier to read.

Are you talking about particular case?!? ...You can safely split into even more parts if there are cleanups which is essential. ...We'll not stop you from doing that nor be angry if do that.

That kind of response certainly won't help you any. ...First, you said you adapt the current style but for some reason immediately start to say why you would careless about that principle. ...Also, telling that you have lots of experience here and there will not get you there either ;-).

 i.

Actually, my earliest posting split the original single patch, and Miller *did* seem angry. I had to put it back together again -- and then he only commented on one thing that *was* in my first post, causing me to have to redo the entire thing a third time. So, I've been posting patches in bigger groups than I originally write and test.

I meant I adapt to existing style (no matter how odd) in places where I'm patching, so that *patches* are easier to review -- and write in a more elegant style where I'm making a significant stand-alone addition.

I'd thought that constant-left style was pretty common around here, as grep tells me there are hundreds upon hundreds of examples in arch, drivers, net, and sound....

Seems like I'm not alone.

Eric Dumazet wrote:
# Cooking patches to linux is not only matter of good ideas and programming (and Dropping

# patches for the masses).
#
# Its also a matter of convincing _people_ that your additions will be maintainable
# when you leave kernel programming and let people like us correct bugs.
#
# For the moment, I am not convinced at all. I prefer to talk now.
#
OK, I'm talking.  Thank you.

Linux already has a fair amount of my code in it, often hard to recognize now after 15 years, so I'm pretty sure that my code has been found maintainable in the past.

Anyway, I don't want to argue about it on an open mailing list. I'm more interested in getting work done!

# Note: I did read your TCPCT 25 pages documentation and very am interested by this # improvement, but its _also_ important to implement it in the normal way. # (I wish this document could be public in a RFC form)
#
It will be, when we have running code, as I'm loath to publish until I'm certain it *can* be implemented.

I've something like 40 RFCs published over the years.

This is why RFC is better before coding. To avoid wasting time on experiments that have a fatal flaw. Once included in an official kernel, we wont be able to change some parameters very easily (think about 253 constant you use)

Or do you think only *you* can understand what's going on, and we should just trust you ?

I believe I know who you are, Mr William Allen Simpson, you dont need to repeat how much work you did in the past. This is a bit annoying.

Some patches need 6-12 months of polishing before inclusion, there is nothing wrong about it. It only depends on your cooperation and patience.

And yes, even if a patch comes from Linus Torvald himself, I can talk if it does not please me.

SYNFLOOD problem is more than 13 years old, I am quite surprised its becoming so urgent we should accept your patches "as is".

May I suggest to switch to normal mode, ie you prepare a next round of patches, you submit them, we review them, [repeat 0-N time(s)], we Ack them ?

We are talking at cross purposes. IEEE had/has a tendency to publish without running code. CTIA/TIA/EIA has interim standards without running code, and had/has rules against even speaking about implementations. Only IETF expected/expects running code. An RFC is rarely issued before coding.

http://www.iana.org/assignments/tcp-parameters/

253 N RFC3692-style Experiment 1 (*) [RFC4727]

When my code is done, I'll post the completed draft and ask IANA for a non-experimental number. That's the usual process. My code shouldn't go into an official release until we know that number.

PS. Rumor has it that Cisco shipped a release with 254 in it. Let's not do that here.

PPS. Adam used 255, not a correct official experimental number.

cleanups are trivial, and should be separated from functionnal changes.

Maybe, but check in linux source code and you'll see this poor pratice is the facto. Dont try to change our minds, because it wont happen.

Oh, good to learn that ! operator only applies to boolean. I didnt know that.

You can _talk_, I can stop reviewing your patches, and wait another gentle guy do the job, because I am 30 years experimented (and tired ?) programmer, and dont want to lose my time to discuss Coding-Style with you ?

Cooking patches to linux is not only matter of good ideas and programming (and Dropping patches for the masses).

Its also a matter of convincing _people_ that your additions will be maintainable when you leave kernel programming and let people like us correct bugs.

For the moment, I am not convinced at all. I prefer to talk now.

Note: I did read your TCPCT 25 pages documentation and very am interested by this improvement, but its _also_ important to implement it in the normal way. (I wish this document could be public in a RFC form)

Linus wrote a long time back (5+ years):

The reason for "if (x == 8)" comes from the way we're taught to think. Arguing against that _fact_ is just totally non-productive, and you have to _force_ yourself to write it the other way around.

And that just means that you will do other mistakes. You'll spend your time thinking about trying to express your conditionals in strange ways, and then not think about the _real_ issue.

So let's make a few rules:

- write your logical expressions the way people EXPECT them to be written. No silly rules that make no sense.

Ergo:

        if (x == 8)

is the ONE AND ONLY SANE WAY.

- avoid using assignment inside logical expressions unless you have a damn good reason to.

Ergo: write

        error = myfunction(xxxx)
        if (error) {
                ...

instead of writing

if (error = myfunction(xxxx))
....

which is just unreadable and stupid.

- Don't get hung about stupid rules.

Ergo: sometimes assignments in conditionals make sense, especially in loops. Don't avoid them just because of some silly rule. But strive to use an explicit equality test when you do so:

        while ((a = function(b)) != 0) 
                ...

is fine.

- The compiler warns about the mistakes that remain, if you follow these rules.

- mistakes happen. Deal with it. Having tons of rules just makes them more likely. Expect mistakes, and make sure they are fixed quickly

Interesting. I've not been able to Google this quote.

I actually think as I write it, finding the other ragged and hard to visually review. But apparently it's an issue for ESL or something, taught to think in another way.

Therefore, I'll re-code as Linus has prescribed. Sadly, I'm having very bad luck verifying coding examples by checking against the installed base, as I found thousands of lines following more usual secure coding practices....

Thank you.

Another style question:

+struct tcp_extend_values {
+ u8 cookie_bakery[TCP_COOKIE_MAX];
+ u8 cookie_plus;
+ u8 cookie_in_always:1,
+ cookie_out_never:1;
+};
+
+static inline struct tcp_extend_values *tcp_xv(const struct request_values *rvp) +{
+ return (struct tcp_extend_values *)rvp;
+}

Some examples have "struct request_values" as the first element, others don't. I started with it, and then removed it (as essentially nil).

Is there a preference?

I don't know, but I do have a bias against casting const to non-const.

cheers, Joe

Oh dear. That's how everything in both include/linux/tcp.h and include/net/tcp.h is done.... As I said, we've had really bad luck using examples from the existing code base.

If somebody else submitted a patch to change all the rest, I'd be content to follow along.

From: William Allen Simpson <[email protected]>
Date: Mon, 02 Nov 2009 15:15:17 -0500

That's not how things work.

You cannot put a requirement that the rules are followed everywhere perfectly in existing code before you're willing to follow them. Nothing is special about you or your work.

You're being very unreasonable on several fronts especially with your seeming unwillingness to follow our procedures, coding style, and rules. Actually, you seem to be willing to follow it, sometimes, when it suits and doesn't inconvenience you.

And this behavior is starting to rub people the wrong way. People less and less want to review your work, and I want to make sure you are shown exactly why that is happening.