* [PATCH 4/4] dm-crypt: sleep and retry on allocation errors
@ 2020-06-01 16:03 Mikulas Patocka
2020-06-02 11:53 ` [PATCH 5/4] dm-integrity: " Mikulas Patocka
0 siblings, 1 reply; 2+ messages in thread
From: Mikulas Patocka @ 2020-06-01 16:03 UTC (permalink / raw)
To: Mike Snitzer, Giovanni Cabiddu, Herbert Xu, David S. Miller,
Milan Broz, djeffery
Cc: dm-devel, qat-linux, linux-crypto, guazhang, jpittman, Mikulas Patocka
[-- Attachment #1: crypt-enomem.patch --]
[-- Type: text/plain, Size: 1354 bytes --]
Some hardware crypto drivers use GFP_ATOMIC allocations in the request
routine. These allocations can randomly fail - for example, they fail if
too many network packets are received.
If we propagated the failure up to the I/O stack, it would cause I/O
errors and data corruption. So, we sleep and retry.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Index: linux-2.6/drivers/md/dm-crypt.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-crypt.c
+++ linux-2.6/drivers/md/dm-crypt.c
@@ -1534,6 +1534,7 @@ static blk_status_t crypt_convert(struct
crypt_alloc_req(cc, ctx);
atomic_inc(&ctx->cc_pending);
+again:
if (crypt_integrity_aead(cc))
r = crypt_convert_block_aead(cc, ctx, ctx->r.req_aead, tag_offset);
else
@@ -1541,6 +1542,17 @@ static blk_status_t crypt_convert(struct
switch (r) {
/*
+ * Some hardware crypto drivers use GFP_ATOMIC allocations in
+ * the request routine. These allocations can randomly fail. If
+ * we propagated the failure up to the I/O stack, it would cause
+ * I/O errors and data corruption.
+ *
+ * So, we sleep and retry.
+ */
+ case -ENOMEM:
+ msleep(1);
+ goto again;
+ /*
* The request was queued by a crypto driver
* but the driver request queue is full, let's wait.
*/
^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH 5/4] dm-integrity: sleep and retry on allocation errors
2020-06-01 16:03 [PATCH 4/4] dm-crypt: sleep and retry on allocation errors Mikulas Patocka
@ 2020-06-02 11:53 ` Mikulas Patocka
0 siblings, 0 replies; 2+ messages in thread
From: Mikulas Patocka @ 2020-06-02 11:53 UTC (permalink / raw)
To: Mike Snitzer, Giovanni Cabiddu, Herbert Xu, David S. Miller,
Milan Broz, djeffery
Cc: dm-devel, qat-linux, linux-crypto, guazhang, jpittman
dm-integrity: sleep and retry on allocation errors
Some hardware crypto drivers use GFP_ATOMIC allocations in the request
routine. These allocations can randomly fail - for example, they fail if
too many network packets are received.
If we propagated the failure up to the I/O stack, it would cause I/O
errors. So, we sleep and retry.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/md/dm-integrity.c | 5 +++++
1 file changed, 5 insertions(+)
Index: linux-2.6/drivers/md/dm-integrity.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-integrity.c 2020-04-05 21:11:02.000000000 +0200
+++ linux-2.6/drivers/md/dm-integrity.c 2020-06-02 13:49:36.000000000 +0200
@@ -859,6 +859,7 @@ static void complete_journal_encrypt(str
static bool do_crypt(bool encrypt, struct skcipher_request *req, struct journal_completion *comp)
{
int r;
+retry:
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
complete_journal_encrypt, comp);
if (likely(encrypt))
@@ -874,6 +875,10 @@ static bool do_crypt(bool encrypt, struc
reinit_completion(&comp->ic->crypto_backoff);
return true;
}
+ if (r == -ENOMEM) {
+ msleep(1);
+ goto retry;
+ }
dm_integrity_io_error(comp->ic, "encrypt", r);
return false;
}
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-06-02 11:53 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-01 16:03 [PATCH 4/4] dm-crypt: sleep and retry on allocation errors Mikulas Patocka
2020-06-02 11:53 ` [PATCH 5/4] dm-integrity: " Mikulas Patocka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).