Reorder ACK/RST checking in LISTEN state
Subsystems (2)
PATCH 1/1 Reorder ACK/RST checking in LISTEN state
Hey everyone,
[I'm not subscribed, so please CC me on any replies]
I've attached a patch that changes the order of the ACK and RST checking in the LISTEN state in tcp_rcv_state_process() in tcp_input.c
Before: If an ACK/RST packet is received, then tcp_rcv_state_process() would return 1 because of the ACK. Then (following the function calls in tcp_ipv4.c and tcp_minisocks.c), tcp_v4_send_reset() is called--but since there is a RST in the packet it just returns. After this, the kfree_skb() is called. The same goes in tcp_ipv6.c as well.
But if the order of the ACK and RST checking is reversed, __kfree_skb() is called in tcp_rcv_state_process() because of the RST and the function returns 0, which skips that other useless stuff.
This is the order specified on page 65 of RFC 793 anyway.
Thanks,
Kris Katterjohn
ipv4/tcp_input.c +3 -3
@@ -4962,12 +4962,12 @@ int tcp_rcv_state_process(struct sock *s goto discard;case TCP_LISTEN : -if (th->ack) -return 1 ; -if (th->rst) goto discard; +if (th->ack) +return 1 ; +if (th->syn) {if (icsk->icsk_af_ops->conn_request (sk, skb) <0 )return 1 ;
David Miller
maintainerFrom: Kris Katterjohn <[email protected]>
Date: Wed, 13 Feb 2008 00:38:13 -0600
Quoted 9 lines
I've attached a patch that changes the order of the ACK and RST checking in the LISTEN state in
tcp_rcv_state_process()intcp_input.cBefore: If an ACK/RST packet is received, then
tcp_rcv_state_process()would return 1 because of the ACK. Then (following the function calls intcp_ipv4.candtcp_minisocks.c),tcp_v4_send_reset()is called--but since there is a RST in the packet it just returns. After this, thekfree_skb()is called. The same goes intcp_ipv6.cas well.
Quoted 7 lines
But if the order of the ACK and RST checking is reversed,
__kfree_skb()is called intcp_rcv_state_process()because of the RST and the function returns 0, which skips that other useless stuff.This is the order specified on page 65 of RFC 793 anyway.
Signed-off-by Kris Katterjohn <[email protected]>
This code has been like this for I don't know how many years, the end result is the same both before and after your patch, and the added expense of the existing code is frankly trivial.
I really don't want to apply this, it doesn't buy us anything, sorry.