check sock_queue_rcv_skb return value
Closed this issue · 4 comments
sock_queue_rcv_skb, which appends the decrypted data to the sk->sk_receive_queue can fail if the queue is full.
In DTLS we can just drop the packet and free it. In TLS we can't.
One strategy to use to have a temporary location to store 1 skb if receive queue is full. Then we "pause" data processing until sk_receive_queue is no longer full. The wake up can happen for example in tls_recvmsg
Another simpler way is to proactively check whether the receive queue would be full before trying to add it to receive queue. For example, during tls_read_size.
I'll work on this and add a test case for it.
The simplier way looks much cleaner.
BTW not sure with TCP queuing. Using skbuffs in ktls would lead to have two kernel buffers - that means we double the kernel memory that can be used for data per single socket instance. Would that be an issue?
EDIT: This shouldn't be an issue since we are decrypting only requested size + we store only data that were not read by user space, but were part of the decrypted record.
#74 This would also solve this issue. If we can read from TCP sock without pulling data off, we can just pause and pull the data off later when KTLS sk_receive_queue is not full