On Wed, Jan 15, 2025 at 05:22:28PM +0100, Harald Freudenberger wrote:
>
> +static int s390_phmac_init(struct ahash_request *req)
> +{
> + struct s390_phmac_req_ctx *req_ctx = ahash_request_ctx(req);
> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
> + struct s390_kmac_sha2_ctx *ctx = &req_ctx->sha2_ctx;
> + int rc;
> +
> + /*
> + * First try synchronous. If this fails for any reason
> + * schedule this request asynchronous via workqueue.
> + */
> +
> + rc = phmac_init(tfm, ctx, false);
> + if (!rc)
> + goto out;
> +
> + req_ctx->req = req;
> + INIT_DELAYED_WORK(&req_ctx->work, phmac_wq_init_fn);
> + schedule_delayed_work(&req_ctx->work, 0);
> + rc = -EINPROGRESS;
This creates a resource problem because there is no limit on how
many requests that can be delayed in this manner for a given tfm.
When we hit this case, I presume this is a system-wide issue and
all requests would go pending? If that is the case, I suggest
allocating a system-wide queue through crypto_engine and using
that to limit how many requests that can become EINPROGRESS.
Thanks,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
