lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1581078974-14778-3-git-send-email-iuliana.prodan@nxp.com>
Date:   Fri,  7 Feb 2020 14:36:14 +0200
From:   Iuliana Prodan <iuliana.prodan@....com>
To:     Herbert Xu <herbert@...dor.apana.org.au>,
        Baolin Wang <baolin.wang@...aro.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Corentin Labbe <clabbe.montjoie@...il.com>,
        Horia Geanta <horia.geanta@....com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Maxime Ripard <mripard@...nel.org>
Cc:     Aymen Sghaier <aymen.sghaier@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Silvano Di Ninno <silvano.dininno@....com>,
        Franck Lenormand <franck.lenormand@....com>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-imx <linux-imx@....com>,
        Iuliana Prodan <iuliana.prodan@....com>
Subject: [PATCH v3 2/2] crypto: engine - support for batch requests

Added support for batch requests, per crypto engine.
A new callback is added, do_batch_requests, which executes a
batch of requests. This has the crypto_engine structure as argument
(for cases when more than one crypto-engine is used).
The crypto_engine_alloc_init_and_set function, initializes
crypto-engine, but also, sets the do_batch_requests callback.
On crypto_pump_requests, if do_batch_requests callback is
implemented in a driver, this will be executed. The link between
the requests will be done in driver, if possible.
do_batch_requests is available only if the hardware has support
for multiple request (if can_enqueue_more callback is implemented).

Signed-off-by: Iuliana Prodan <iuliana.prodan@....com>
---
 crypto/crypto_engine.c  | 20 ++++++++++++++++++--
 include/crypto/engine.h |  3 +++
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index dc33249..05f2895 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -192,6 +192,12 @@ static void crypto_pump_requests(struct crypto_engine *engine,
 	return;
 out:
 	spin_unlock_irqrestore(&engine->queue_lock, flags);
+	if (engine->do_batch_requests) {
+		ret = engine->do_batch_requests(engine);
+		if (ret)
+			dev_err(engine->dev, "failed to do batch requests: %d\n",
+				ret);
+	}
 }
 
 static void crypto_pump_work(struct kthread_work *work)
@@ -426,6 +432,12 @@ EXPORT_SYMBOL_GPL(crypto_engine_stop);
  *               callback(struct crypto_engine *engine)
  *               where:
  *               @engine: the crypto engine structure.
+ * @cbk_do_batch: pointer to a callback function to be invoked when executing a
+ *                a batch of requests.
+ *                This has the form:
+ *                callback(struct crypto_engine *engine)
+ *                where:
+ *                @engine: the crypto engine structure.
  * @rt: whether this queue is set to run as a realtime task
  * @qlen: maximum size of the crypto-engine queue
  *
@@ -434,6 +446,7 @@ EXPORT_SYMBOL_GPL(crypto_engine_stop);
  */
 struct crypto_engine *crypto_engine_alloc_init_and_set(struct device *dev,
 						       bool (*cbk_can_enq)(struct crypto_engine *engine),
+						       int (*cbk_do_batch)(struct crypto_engine *engine),
 						       bool rt, int qlen)
 {
 	struct sched_param param = { .sched_priority = MAX_RT_PRIO / 2 };
@@ -452,7 +465,10 @@ struct crypto_engine *crypto_engine_alloc_init_and_set(struct device *dev,
 	engine->busy = false;
 	engine->idling = false;
 	engine->priv_data = dev;
-	engine->can_enqueue_more = cbk_can_enq;
+	if (cbk_can_enq) {
+		engine->can_enqueue_more = cbk_can_enq;
+		engine->do_batch_requests = cbk_do_batch;
+	}
 	snprintf(engine->name, sizeof(engine->name),
 		 "%s-engine", dev_name(dev));
 
@@ -486,7 +502,7 @@ EXPORT_SYMBOL_GPL(crypto_engine_alloc_init_and_set);
  */
 struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt)
 {
-	return crypto_engine_alloc_init_and_set(dev, NULL, rt,
+	return crypto_engine_alloc_init_and_set(dev, NULL, NULL, rt,
 						CRYPTO_ENGINE_MAX_QLEN);
 }
 EXPORT_SYMBOL_GPL(crypto_engine_alloc_init);
diff --git a/include/crypto/engine.h b/include/crypto/engine.h
index 00d35703..019f884 100644
--- a/include/crypto/engine.h
+++ b/include/crypto/engine.h
@@ -34,6 +34,7 @@
  * @unprepare_crypt_hardware: there are currently no more requests on the
  * queue so the subsystem notifies the driver that it may relax the
  * hardware by issuing this call
+ * @do_batch_requests: execute a batch of requests
  * @can_enqueue_more: callback to check whether the hardware can process
  * a new request
  * @kworker: kthread worker struct for request pump
@@ -57,6 +58,7 @@ struct crypto_engine {
 
 	int (*prepare_crypt_hardware)(struct crypto_engine *engine);
 	int (*unprepare_crypt_hardware)(struct crypto_engine *engine);
+	int (*do_batch_requests)(struct crypto_engine *engine);
 	bool (*can_enqueue_more)(struct crypto_engine *engine);
 
 	struct kthread_worker           *kworker;
@@ -106,6 +108,7 @@ int crypto_engine_stop(struct crypto_engine *engine);
 struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt);
 struct crypto_engine *crypto_engine_alloc_init_and_set(struct device *dev,
 						       bool (*cbk_can_enq)(struct crypto_engine *engine),
+						       int (*cbk_do_batch)(struct crypto_engine *engine),
 						       bool rt, int qlen);
 int crypto_engine_exit(struct crypto_engine *engine);
 
-- 
2.1.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ