check sock_queue_rcv_skb return value

[lancerchao]

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.

[lancerchao]

I'll work on this and add a test case for it.

[fridex]

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.

[lancerchao]

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

[djwatson]

This should be fixed in https://github.com/ktls/af_ktls/pull/76