On Sun, Feb 09, 2025 at 04:47:57PM +0800, Herbert Xu wrote:
> 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.
Or just make it synchronous which would be way easier, and the calling code uses
it synchronously anyway.
- Eric
