Re: [PATCH v10 2/5] s390/crypto: New s390 specific protected key hash phmac

[Eric Biggers <ebiggers@kernel.org>]

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