summaryrefslogtreecommitdiffstats
path: root/net/ipv4/fib_trie.c
diff options
context:
space:
mode:
authorJakub Kicinski <jakub.kicinski@netronome.com>2019-05-24 10:34:32 -0700
committerDavid S. Miller <davem@davemloft.net>2019-05-26 21:47:13 -0700
commit04b25a5411f966c2e586909a8496553b71876fae (patch)
tree18417d59629d044b2b0ce5f0a057e3c62643f1d6 /net/ipv4/fib_trie.c
parent7718a855cd7ae9fc27a2aa1532ee105d52eb7634 (diff)
downloadlinux-04b25a5411f966c2e586909a8496553b71876fae.tar.gz
linux-04b25a5411f966c2e586909a8496553b71876fae.tar.bz2
linux-04b25a5411f966c2e586909a8496553b71876fae.zip
net/tls: fix no wakeup on partial reads
When tls_sw_recvmsg() partially copies a record it pops that record from ctx->recv_pkt and places it on rx_list. Next iteration of tls_sw_recvmsg() reads from rx_list via process_rx_list() before it enters the decryption loop. If there is no more records to be read tls_wait_data() will put the process on the wait queue and got to sleep. This is incorrect, because some data was already copied in process_rx_list(). In case of RPC connections process may never get woken up, because peer also simply blocks in read(). I think this may also fix a similar issue when BPF is at play, because after __tcp_bpf_recvmsg() returns some data we subtract it from len and use continue to restart the loop, but len could have just reached 0, so again we'd sleep unnecessarily. That's added by: commit d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") Reported-by: David Beckett <david.beckett@netronome.com> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Tested-by: David Beckett <david.beckett@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/fib_trie.c')
0 files changed, 0 insertions, 0 deletions