summaryrefslogtreecommitdiff
path: root/CREDITS
diff options
context:
space:
mode:
authorEric Dumazet <edumazet@google.com>2014-11-17 23:06:20 -0800
committerSasha Levin <sasha.levin@oracle.com>2015-03-24 08:22:22 -0400
commite8f117f002cafb7a4a5a008b0251e5239207ebe1 (patch)
tree4bef9fb804a180c3031fa302a7da8f7591f48be2 /CREDITS
parent34ca18c8fbcd9debf4c558ab218f77c1d613f552 (diff)
tcp: make connect() mem charging friendly
[ Upstream commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a ] While working on sk_forward_alloc problems reported by Denys Fedoryshchenko, we found that tcp connect() (and fastopen) do not call sk_wmem_schedule() for SYN packet (and/or SYN/DATA packet), so sk_forward_alloc is negative while connect is in progress. We can fix this by calling regular sk_stream_alloc_skb() both for the SYN packet (in tcp_connect()) and the syn_data packet in tcp_send_syn_data() Then, tcp_send_syn_data() can avoid copying syn_data as we simply can manipulate syn_data->cb[] to remove SYN flag (and increment seq) Instead of open coding memcpy_fromiovecend(), simply use this helper. This leaves in socket write queue clean fast clone skbs. This was tested against our fastopen packetdrill tests. Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Diffstat (limited to 'CREDITS')
0 files changed, 0 insertions, 0 deletions