summaryrefslogtreecommitdiff
path: root/net/ipv4/syncookies.c
diff options
context:
space:
mode:
authorEric Dumazet <eric.dumazet@gmail.com>2010-06-03 13:03:58 +0400
committerDavid S. Miller <davem@davemloft.net>2010-06-05 02:56:02 +0400
commitca55158c6ecb7832a6ad80ac44a14d23bab8cdfc (patch)
treee701c78b85016247fa5962de0e0793e5b985930e /net/ipv4/syncookies.c
parent536e00e570c87f258554e919c444b81a7002e46d (diff)
downloadlinux-ca55158c6ecb7832a6ad80ac44a14d23bab8cdfc.tar.xz
rps: tcp: fix rps_sock_flow_table table updates
I believe a moderate SYN flood attack can corrupt RFS flow table (rps_sock_flow_table), making RPS/RFS much less effective. Even in a normal situation, server handling short lived sessions suffer from bad steering for the first data packet of a session, if another SYN packet is received for another session. We do following action in tcp_v4_rcv() : sock_rps_save_rxhash(sk, skb->rxhash); We should _not_ do this if sk is a LISTEN socket, as about each packet received on a LISTEN socket has a different rxhash than previous one. -> RPS_NO_CPU markers are spread all over rps_sock_flow_table. Also, it makes sense to protect sk->rxhash field changes with socket lock (We currently can change it even if user thread owns the lock and might use rxhash) This patch moves sock_rps_save_rxhash() to a sock locked section, and only for non LISTEN sockets. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/syncookies.c')
0 files changed, 0 insertions, 0 deletions