From: Vinay Kumar Yadav <vinay.ya...@chelsio.com> Date: Sat, 23 May 2020 01:40:31 +0530
> tls_sw_recvmsg() and tls_decrypt_done() can be run concurrently. > // tls_sw_recvmsg() > if (atomic_read(&ctx->decrypt_pending)) > crypto_wait_req(-EINPROGRESS, &ctx->async_wait); > else > reinit_completion(&ctx->async_wait.completion); > > //tls_decrypt_done() > pending = atomic_dec_return(&ctx->decrypt_pending); > > if (!pending && READ_ONCE(ctx->async_notify)) > complete(&ctx->async_wait.completion); > > Consider the scenario tls_decrypt_done() is about to run complete() > > if (!pending && READ_ONCE(ctx->async_notify)) > > and tls_sw_recvmsg() reads decrypt_pending == 0, does reinit_completion(), > then tls_decrypt_done() runs complete(). This sequence of execution > results in wrong completion. Consequently, for next decrypt request, > it will not wait for completion, eventually on connection close, crypto > resources freed, there is no way to handle pending decrypt response. > > This race condition can be avoided by having atomic_read() mutually > exclusive with atomic_dec_return(),complete().Intoduced spin lock to > ensure the mutual exclution. > > Addressed similar problem in tx direction. > > v1->v2: > - More readable commit message. > - Corrected the lock to fix new race scenario. > - Removed barrier which is not needed now. > > Signed-off-by: Vinay Kumar Yadav <vinay.ya...@chelsio.com> Applied to 'net' as this is a bug fix, with Fixes tag from Jakub added, and queued up for -stable. Thanks.
