@@ -6697,6 +6697,7 @@ int tcp_conn_request(struct request_sock_ops *rsk_ops,
/* Note: tcp_v6_init_req() might override ir_iif for link locals */
inet_rsk(req)->ir_iif = inet_request_bound_dev_if(sk, skb);
+ refcount_set(&req->rsk_refcnt, 1);
af_ops->init_req(req, sk, skb, want_cookie);
if (security_inet_conn_request(sk, skb, req))
@@ -6767,10 +6768,6 @@ int tcp_conn_request(struct request_sock_ops *rsk_ops,
af_ops->send_synack(sk, dst, &fl, req, &foc,
!want_cookie ? TCP_SYNACK_NORMAL :
TCP_SYNACK_COOKIE);
- if (want_cookie) {
- reqsk_free(req);
- return 0;
- }
}
reqsk_put(req);
return 0;
@@ -6778,7 +6775,7 @@ int tcp_conn_request(struct request_sock_ops *rsk_ops,
drop_and_release:
dst_release(dst);
drop_and_free:
- __reqsk_free(req);
+ reqsk_put(req);
drop:
tcp_listendrop(sk);
return 0;
This will allow the syn_recv_sock callback to keep the request socket around even when syncookies are used. This will be needed to make MPTCP JOIN requests work in cookie mode. When a JOIN request is received, we cannot use cookies because we need to remember the peers nonce value for HMAC validation. Next patch will handle the cookie+join case by allowing the rsk to stay around provided: 1. We can find a valid mptcp socket for the 32bit token provided by the join and 2. the found mptcp socket doesn't exceed the maximum number of subflows. To handle 2) the request socket will not only be accounted with the listener but also with the mptcp (parent) socket. Signed-off-by: Florian Westphal <fw@strlen.de> --- net/ipv4/tcp_input.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)