On Wed, 30 Dec 2020, Ignat Korchagin wrote:
> diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
> index 53791138d78b..e4fd690c70e1 100644
> --- a/drivers/md/dm-crypt.c
> +++ b/drivers/md/dm-crypt.c
> @@ -1539,7 +1549,10 @@ static blk_status_t crypt_convert(struct crypt_config
> *cc,
>
> while (ctx->iter_in.bi_size && ctx->iter_out.bi_size) {
>
> - crypt_alloc_req(cc, ctx);
> + r = crypt_alloc_req(cc, ctx);
> + if (r)
> + return BLK_STS_RESOURCE;
> +
> atomic_inc(&ctx->cc_pending);
>
> if (crypt_integrity_aead(cc))
> --
> 2.20.1
I'm not quite convinced that returning BLK_STS_RESOURCE will help. The
block layer will convert this value back to -ENOMEM and return it to the
caller, resulting in an I/O error.
Note that GFP_ATOMIC allocations may fail anytime and you must handle
allocation failure gracefully - i.e. process the request without any
error.
An acceptable solution would be to punt the request to a workqueue and do
GFP_NOIO allocation from the workqueue. Or add the request to some list
and process the list when some other request completes.
You should write a test that simulates allocation failure and verify that
the kernel handles it gracefully without any I/O error.
Mikulas
