)]}'
{
  "commit": "ca55158c6ecb7832a6ad80ac44a14d23bab8cdfc",
  "tree": "e701c78b85016247fa5962de0e0793e5b985930e",
  "parents": [
    "536e00e570c87f258554e919c444b81a7002e46d"
  ],
  "author": {
    "name": "Eric Dumazet",
    "email": "eric.dumazet@gmail.com",
    "time": "Thu Jun 03 09:03:58 2010 +0000"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Fri Jun 04 15:56:02 2010 -0700"
  },
  "message": "rps: tcp: fix rps_sock_flow_table table updates\n\nI believe a moderate SYN flood attack can corrupt RFS flow table\n(rps_sock_flow_table), making RPS/RFS much less effective.\n\nEven in a normal situation, server handling short lived sessions suffer\nfrom bad steering for the first data packet of a session, if another SYN\npacket is received for another session.\n\nWe do following action in tcp_v4_rcv() :\n\n\tsock_rps_save_rxhash(sk, skb-\u003erxhash);\n\nWe should _not_ do this if sk is a LISTEN socket, as about each\npacket received on a LISTEN socket has a different rxhash than\nprevious one.\n -\u003e RPS_NO_CPU markers are spread all over rps_sock_flow_table.\n\nAlso, it makes sense to protect sk-\u003erxhash field changes with socket\nlock (We currently can change it even if user thread owns the lock\nand might use rxhash)\n\nThis patch moves sock_rps_save_rxhash() to a sock locked section,\nand only for non LISTEN sockets.\n\nSigned-off-by: Eric Dumazet \u003ceric.dumazet@gmail.com\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "202cf09c4cd4be9f8a556d2740a51ca4bba96e56",
      "old_mode": 33188,
      "old_path": "net/ipv4/tcp_ipv4.c",
      "new_id": "fe193e53af447f49fe05a8cba7b495c38f421be2",
      "new_mode": 33188,
      "new_path": "net/ipv4/tcp_ipv4.c"
    }
  ]
}