From: Eric Biggers <ebiggers3@gmail.com>
To: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Jonathan Corbet <corbet@lwn.net>,
David Howells <dhowells@redhat.com>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, Shaohua Li <shli@kernel.org>,
Steve French <sfrench@samba.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
James Morris <james.l.morris@oracle.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
Ofir Drang <ofir.drang@arm.com>,
Gilad Ben-Yossef <gilad.benyossef@arm.com>,
linux-crypto@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, keyrings@vger.kernel.org,
linux-raid@vger.kernel.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org, linux-fsdevel@vger.kernel.org,
linux-ima-devel@lists.sourceforge.net,
linux-ima-user@lists.sourceforge.net,
linux-security-module@vger.kernel.org
Subject: Re: [RFC 01/10] crypto: factor async completion for general use
Date: Wed, 10 May 2017 20:55:27 -0700 [thread overview]
Message-ID: <20170511035527.GA2936@zzz> (raw)
In-Reply-To: <1494075602-5061-2-git-send-email-gilad@benyossef.com>
Hi Gilad,
On Sat, May 06, 2017 at 03:59:50PM +0300, Gilad Ben-Yossef wrote:
> Invoking a possibly async. crypto op and waiting for completion
> while correctly handling backlog processing is a common task
> in the crypto API implementation and outside users of it.
>
> This patch re-factors one of the in crypto API implementation in
> preparation for using it across the board instead of hand
> rolled versions.
Thanks for doing this! It annoyed me too that there wasn't a helper function
for this. Just a few comments below:
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 3556d8e..bf4acaf 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -480,33 +480,6 @@ int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con)
> }
> EXPORT_SYMBOL_GPL(af_alg_cmsg_send);
>
> -int af_alg_wait_for_completion(int err, struct af_alg_completion *completion)
> -{
> - switch (err) {
> - case -EINPROGRESS:
> - case -EBUSY:
> - wait_for_completion(&completion->completion);
> - reinit_completion(&completion->completion);
> - err = completion->err;
> - break;
> - };
> -
> - return err;
> -}
> -EXPORT_SYMBOL_GPL(af_alg_wait_for_completion);
> -
> -void af_alg_complete(struct crypto_async_request *req, int err)
> -{
> - struct af_alg_completion *completion = req->data;
> -
> - if (err == -EINPROGRESS)
> - return;
> -
> - completion->err = err;
> - complete(&completion->completion);
> -}
> -EXPORT_SYMBOL_GPL(af_alg_complete);
> -
I think it would be cleaner to switch af_alg and algif_* over to the new
interface in its own patch, rather than in the same patch that introduces the
new interface.
> @@ -88,8 +88,8 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
> if ((msg->msg_flags & MSG_MORE))
> hash_free_result(sk, ctx);
>
> - err = af_alg_wait_for_completion(crypto_ahash_init(&ctx->req),
> - &ctx->completion);
> + err = crypto_wait_req(crypto_ahash_init(&ctx->req),
> + &ctx->wait);
> if (err)
> goto unlock;
> }
In general can you try to keep the argument lists indented sanely? (This
applies throughout the patch series.) e.g. here I'd have expected:
err = crypto_wait_req(crypto_ahash_init(&ctx->req),
&ctx->wait);
>
> diff --git a/crypto/api.c b/crypto/api.c
> index 941cd4c..1c6e9cd 100644
> --- a/crypto/api.c
> +++ b/crypto/api.c
> @@ -24,6 +24,7 @@
> #include <linux/sched/signal.h>
> #include <linux/slab.h>
> #include <linux/string.h>
> +#include <linux/completion.h>
> #include "internal.h"
>
> LIST_HEAD(crypto_alg_list);
> @@ -595,5 +596,32 @@ int crypto_has_alg(const char *name, u32 type, u32 mask)
> }
> EXPORT_SYMBOL_GPL(crypto_has_alg);
>
> +int crypto_wait_req(int err, struct crypto_wait *wait)
> +{
> + switch (err) {
> + case -EINPROGRESS:
> + case -EBUSY:
> + wait_for_completion(&wait->completion);
> + reinit_completion(&wait->completion);
> + err = wait->err;
> + break;
> + };
> +
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(crypto_wait_req);
crypto_wait_req() maybe should be inlined, since it doesn't do much (note that
reinit_completion is actually just a variable assignment), and the common case
is that 'err' will be 0, so there will be nothing to wait for.
Also drop the unnecessary semicolon at the end of the switch block.
With regards to the wait being uninterruptible, I agree that this should be the
default behavior, because I think users waiting for specific crypto requests are
generally not prepared to handle the wait actually being interrupted. After
interruption the crypto operation will still proceed in the background, and it
will use buffers which the caller has in many cases already freed. However, I'd
suggest taking a close look at anything that was actually doing an interruptible
wait before, to see whether it was a bug or intentional (or "doesn't matter").
And yes there could always be a crypto_wait_req_interruptible() introduced if
some users need it.
>
> #define CRYPTO_MINALIGN_ATTR __attribute__ ((__aligned__(CRYPTO_MINALIGN)))
>
> +/*
> + * Macro for declaring a crypto op async wait object on stack
> + */
> +#define DECLARE_CRYPTO_WAIT(_wait) \
> + struct crypto_wait _wait = { \
> + COMPLETION_INITIALIZER_ONSTACK((_wait).completion), 0 }
> +
Move this definition down below, so it's next to crypto_wait?
>
> /*
> * Algorithm registration interface.
> */
> @@ -1604,5 +1631,6 @@ static inline int crypto_comp_decompress(struct crypto_comp *tfm,
> src, slen, dst, dlen);
> }
>
> +
Don't add unrelated blank lines.
- Eric
next prev parent reply other threads:[~2017-05-11 3:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-06 12:59 [RFC 00/10] introduce crypto wait for async op function Gilad Ben-Yossef
2017-05-06 12:59 ` [RFC 01/10] crypto: factor async completion for general use Gilad Ben-Yossef
2017-05-11 3:55 ` Eric Biggers [this message]
2017-05-11 7:29 ` Gilad Ben-Yossef
2017-05-11 8:09 ` Eric Biggers
2017-05-11 8:55 ` Gilad Ben-Yossef
2017-05-06 12:59 ` [RFC 02/10] crypto: move pub key to generic async completion Gilad Ben-Yossef
2017-05-06 12:59 ` [RFC 03/10] crypto: move drbg " Gilad Ben-Yossef
2017-05-06 12:59 ` [RFC 04/10] crypto: move gcm " Gilad Ben-Yossef
2017-05-06 12:59 ` [RFC 05/10] crypto: move testmgr " Gilad Ben-Yossef
2017-05-06 12:59 ` [RFC 06/10] dm: move dm-verity " Gilad Ben-Yossef
2017-05-06 12:59 ` [RFC 07/10] fscrypt: move " Gilad Ben-Yossef
2017-05-11 4:04 ` Eric Biggers
2017-05-06 12:59 ` [RFC 08/10] cifs: " Gilad Ben-Yossef
2017-05-08 20:56 ` Pavel Shilovsky
2017-05-06 12:59 ` [RFC 09/10] ima: " Gilad Ben-Yossef
2017-05-10 21:26 ` Mimi Zohar
2017-05-06 12:59 ` [RFC 10/10] crypto: adapt api sample to use async. op wait Gilad Ben-Yossef
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170511035527.GA2936@zzz \
--to=ebiggers3@gmail.com \
--cc=agk@redhat.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dm-devel@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=gilad.benyossef@arm.com \
--cc=gilad@benyossef.com \
--cc=herbert@gondor.apana.org.au \
--cc=jaegeuk@kernel.org \
--cc=james.l.morris@oracle.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ima-devel@lists.sourceforge.net \
--cc=linux-ima-user@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=ofir.drang@arm.com \
--cc=samba-technical@lists.samba.org \
--cc=serge@hallyn.com \
--cc=sfrench@samba.org \
--cc=shli@kernel.org \
--cc=snitzer@redhat.com \
--cc=tytso@mit.edu \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).