| Message ID | 20240328123805.3886026-1-srish.srinivasan@broadcom.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [6.1.y] net: tls: handle backlogging of crypto requests | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Guessing tree name failed - patch did not apply |
On Thu, Mar 28, 2024 at 06:08:05PM +0530, Srish Srinivasan wrote: > From: Jakub Kicinski <kuba@kernel.org> > > commit 8590541473188741055d27b955db0777569438e3 upstream > > Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our > requests to the crypto API, crypto_aead_{encrypt,decrypt} can return > -EBUSY instead of -EINPROGRESS in valid situations. For example, when > the cryptd queue for AESNI is full (easy to trigger with an > artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued > to the backlog but still processed. In that case, the async callback > will also be called twice: first with err == -EINPROGRESS, which it > seems we can just ignore, then with err == 0. > > Compared to Sabrina's original patch this version uses the new > tls_*crypt_async_wait() helpers and converts the EBUSY to > EINPROGRESS to avoid having to modify all the error handling > paths. The handling is identical. > > Fixes: a54667f6728c ("tls: Add support for encryption using async offload accelerator") > Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls records") > Co-developed-by: Sabrina Dubroca <sd@queasysnail.net> > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> > Link: https://lore.kernel.org/netdev/9681d1febfec295449a62300938ed2ae66983f28.1694018970.git.sd@queasysnail.net/ > Signed-off-by: Jakub Kicinski <kuba@kernel.org> > Reviewed-by: Simon Horman <horms@kernel.org> > Signed-off-by: David S. Miller <davem@davemloft.net> > Signed-off-by: Sasha Levin <sashal@kernel.org> > [Srish: fixed merge-conflict in stable branch linux-6.1.y, > needs to go on top of https://lore.kernel.org/stable/20240307155930.913525-1-lee@kernel.org/] > Signed-off-by: Srish Srinivasan <srish.srinivasan@broadcom.com> > --- > net/tls/tls_sw.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) Now queued up, thanks. greg k-h
On Fri, Mar 29, 2024 at 2:53 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Mar 28, 2024 at 06:08:05PM +0530, Srish Srinivasan wrote: > > From: Jakub Kicinski <kuba@kernel.org> > > > > commit 8590541473188741055d27b955db0777569438e3 upstream > > > > Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our > > requests to the crypto API, crypto_aead_{encrypt,decrypt} can return > > -EBUSY instead of -EINPROGRESS in valid situations. For example, when > > the cryptd queue for AESNI is full (easy to trigger with an > > artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued > > to the backlog but still processed. In that case, the async callback > > will also be called twice: first with err == -EINPROGRESS, which it > > seems we can just ignore, then with err == 0. > > > > Compared to Sabrina's original patch this version uses the new > > tls_*crypt_async_wait() helpers and converts the EBUSY to > > EINPROGRESS to avoid having to modify all the error handling > > paths. The handling is identical. > > > > Fixes: a54667f6728c ("tls: Add support for encryption using async offload accelerator") > > Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls records") > > Co-developed-by: Sabrina Dubroca <sd@queasysnail.net> > > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> > > Link: https://lore.kernel.org/netdev/9681d1febfec295449a62300938ed2ae66983f28.1694018970.git.sd@queasysnail.net/ > > Signed-off-by: Jakub Kicinski <kuba@kernel.org> > > Reviewed-by: Simon Horman <horms@kernel.org> > > Signed-off-by: David S. Miller <davem@davemloft.net> > > Signed-off-by: Sasha Levin <sashal@kernel.org> > > [Srish: fixed merge-conflict in stable branch linux-6.1.y, > > needs to go on top of https://lore.kernel.org/stable/20240307155930.913525-1-lee@kernel.org/] > > Signed-off-by: Srish Srinivasan <srish.srinivasan@broadcom.com> > > --- > > net/tls/tls_sw.c | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > Now queued up, thanks. > Greg, this patch (i.e. v1) has hunk failures. Just now I have sent v2 for this patch (after resolving hunks). Requesting you to queue up v2: https://lore.kernel.org/stable/20240329102540.3888561-1-srish.srinivasan@broadcom.com/T/#m164567a5bd32085931a1b1367ae12e4102870111 Sorry for the inconvenience. > greg k-h
On Fri, Mar 29, 2024 at 04:02:57PM +0530, Srish Srinivasan wrote: > On Fri, Mar 29, 2024 at 2:53 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Thu, Mar 28, 2024 at 06:08:05PM +0530, Srish Srinivasan wrote: > > > From: Jakub Kicinski <kuba@kernel.org> > > > > > > commit 8590541473188741055d27b955db0777569438e3 upstream > > > > > > Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our > > > requests to the crypto API, crypto_aead_{encrypt,decrypt} can return > > > -EBUSY instead of -EINPROGRESS in valid situations. For example, when > > > the cryptd queue for AESNI is full (easy to trigger with an > > > artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued > > > to the backlog but still processed. In that case, the async callback > > > will also be called twice: first with err == -EINPROGRESS, which it > > > seems we can just ignore, then with err == 0. > > > > > > Compared to Sabrina's original patch this version uses the new > > > tls_*crypt_async_wait() helpers and converts the EBUSY to > > > EINPROGRESS to avoid having to modify all the error handling > > > paths. The handling is identical. > > > > > > Fixes: a54667f6728c ("tls: Add support for encryption using async offload accelerator") > > > Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls records") > > > Co-developed-by: Sabrina Dubroca <sd@queasysnail.net> > > > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> > > > Link: https://lore.kernel.org/netdev/9681d1febfec295449a62300938ed2ae66983f28.1694018970.git.sd@queasysnail.net/ > > > Signed-off-by: Jakub Kicinski <kuba@kernel.org> > > > Reviewed-by: Simon Horman <horms@kernel.org> > > > Signed-off-by: David S. Miller <davem@davemloft.net> > > > Signed-off-by: Sasha Levin <sashal@kernel.org> > > > [Srish: fixed merge-conflict in stable branch linux-6.1.y, > > > needs to go on top of https://lore.kernel.org/stable/20240307155930.913525-1-lee@kernel.org/] > > > Signed-off-by: Srish Srinivasan <srish.srinivasan@broadcom.com> > > > --- > > > net/tls/tls_sw.c | 22 ++++++++++++++++++++++ > > > 1 file changed, 22 insertions(+) > > > > Now queued up, thanks. > > > > Greg, this patch (i.e. v1) has hunk failures. What do you mean? it worked here just fine. > Just now I have sent v2 for this patch (after resolving hunks). > Requesting you to queue up v2: > https://lore.kernel.org/stable/20240329102540.3888561-1-srish.srinivasan@broadcom.com/T/#m164567a5bd32085931a1b1367ae12e4102870111 Let me see what the actual difference is...
Hello, As far as I understand this issue also affects kernel 5.15. Are there any plans to backport it to 5.15? Thank you
On Tue, May 21, 2024 at 10:58:38AM +0000, Oleksandr Tymoshenko wrote: > Hello, > > As far as I understand this issue also affects kernel 5.15. Are there any plans > to backport it to 5.15? Why not provide a working backport if you are interested in the 5.15.y kernel tree? thanks, greg k-h
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 2bd27b777..61b01dfc6 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -195,6 +195,17 @@ static void tls_decrypt_done(crypto_completion_data_t *data, int err) struct sock *sk; int aead_size; + /* If requests get too backlogged crypto API returns -EBUSY and calls + * ->complete(-EINPROGRESS) immediately followed by ->complete(0) + * to make waiting for backlog to flush with crypto_wait_req() easier. + * First wait converts -EBUSY -> -EINPROGRESS, and the second one + * -EINPROGRESS -> 0. + * We have a single struct crypto_async_request per direction, this + * scheme doesn't help us, so just ignore the first ->complete(). + */ + if (err == -EINPROGRESS) + return; + aead_size = sizeof(*aead_req) + crypto_aead_reqsize(aead); aead_size = ALIGN(aead_size, __alignof__(*dctx)); dctx = (void *)((u8 *)aead_req + aead_size); @@ -268,6 +279,10 @@ static int tls_do_decryption(struct sock *sk, } ret = crypto_aead_decrypt(aead_req); + if (ret == -EBUSY) { + ret = tls_decrypt_async_wait(ctx); + ret = ret ?: -EINPROGRESS; + } if (ret == -EINPROGRESS) { if (darg->async) return 0; @@ -452,6 +467,9 @@ static void tls_encrypt_done(crypto_completion_data_t *data, int err) bool ready = false; struct sock *sk; + if (err == -EINPROGRESS) /* see the comment in tls_decrypt_done() */ + return; + rec = container_of(aead_req, struct tls_rec, aead_req); msg_en = &rec->msg_encrypted; @@ -560,6 +578,10 @@ static int tls_do_encryption(struct sock *sk, atomic_inc(&ctx->encrypt_pending); rc = crypto_aead_encrypt(aead_req); + if (rc == -EBUSY) { + rc = tls_encrypt_async_wait(ctx); + rc = rc ?: -EINPROGRESS; + } if (!rc || rc != -EINPROGRESS) { atomic_dec(&ctx->encrypt_pending); sge->offset -= prot->prepend_size;