Please don't top post. On Sun, 15 Nov 2020 02:26:30 +0000 Vadim Fedorenko wrote: > No, I don't have any BPFs in test. > If we have Application Data in TCP queue then tls_sw_advance_skb > will change ctx->control from 0x16 to 0x17 (TLS_RECORD_TYPE_DATA) > and the loop will continue.
Ah! Missed that, unpausing the parser will make it serve us another message and overwrite ctx. > The patched if will make zc = true and > data will be decrypted into msg->msg_iter. > After that the loop will break on: > if (!control) > control = tlm->control; > else if (control != tlm->control) > goto recv_end; > > and the data will be lost. > Next call to recvmsg will find ctx->decrypted set to true and will > copy the unencrypted data from skb assuming that it has been decrypted > already. > > The patch that I put into Fixes: changed the check you mentioned to > ctx->control, but originally it was checking the value of control that > was stored before calling to tls_sw_advance_skb. Is there a reason why we wouldn't just go back to checking the stored control? Or better - put your condition there (control != ctx->control)? Decrypting the next record seems unnecessary given we can't return it.
