From: Elena Petrova <lenaptr@google.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric Biggers <ebiggers@kernel.org>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
Stephan Mueller <smueller@chronox.de>,
Ard Biesheuvel <ardb@kernel.org>,
Jeffrey Vander Stoep <jeffv@google.com>
Subject: Re: [PATCH v5] crypto: af_alg - add extra parameters for DRBG interface
Date: Tue, 8 Sep 2020 18:23:25 +0100 [thread overview]
Message-ID: <CABvBcwYqeGw-9oGngEm01dAt8JLxkKCLFFn9409efcLPTsJg+w@mail.gmail.com> (raw)
In-Reply-To: <20200821042443.GA25695@gondor.apana.org.au>
On Fri, 21 Aug 2020 at 05:24, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > Since proto_ops are almost identical, and only one is used in a given kernel
> > build, why not just do:
> >
> > static struct proto_ops algif_rng_ops = {
> > ...
> > #ifdef CONFIG_CRYPTO_USER_API_RNG_CAVP
> > .sendmsg = rng_sendmsg,
> > #else
> > .sendmsg = sock_no_sendmsg,
> > #endif
> > ...
> > };
> >
> > Similarly for .recvmsg(), although I don't understand what's wrong with just
> > adding the lock_sock() instead... The RNG algorithms do locking anyway, so it's
> > not like that would regress the ability to recvmsg() in parallel. Also,
> > conditional locking depending on the kernel config makes it more difficult to
> > find kernel bugs like deadlocks.
>
> I want this to have minimal impact on anyone who's not using it.
> After all, this is something that only Google is asking for.
>
> Anyway, I wasn't looking for a compile-time ops switch, but a
> run-time one.
>
> I think what we can do is move the new newsock->ops assignment
> in af_alg_accept up above the type->accept call which would then
> allow it to be overridden by the accept call.
>
> After that you could just change newsock->ops depending on whether
> pctx->entropy is NULL or not in rng_accept_parent.
Ack, done in v6.
> As for the proto_ops duplication I don't think it's that big a
> deal, but if you're really bothered just create a macro for the
> identical bits in the struct.
I didn't create a macro to avoid complicating the code.
Thanks,
Elena
next prev parent reply other threads:[~2020-09-08 17:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 16:48 [PATCH 0/1] crypto: af_alg - add extra parameters for DRBG interface Elena Petrova
2020-07-13 16:48 ` [PATCH 1/1] " Elena Petrova
2020-07-13 17:10 ` Eric Biggers
2020-07-16 14:23 ` Elena Petrova
2020-07-16 16:40 ` [PATCH v2] " Elena Petrova
2020-07-20 17:35 ` Stephan Mueller
2020-07-21 12:55 ` Elena Petrova
2020-07-21 13:18 ` Stephan Mueller
2020-07-28 16:16 ` Elena Petrova
2020-07-20 17:42 ` Stephan Müller
2020-07-22 15:59 ` Eric Biggers
2020-07-28 15:51 ` [PATCH v3] " Elena Petrova
2020-07-28 17:36 ` Eric Biggers
2020-07-29 15:45 ` [PATCH v4] " Elena Petrova
2020-07-29 19:26 ` Stephan Müller
2020-07-31 7:23 ` Herbert Xu
2020-08-03 14:48 ` Elena Petrova
2020-08-03 15:10 ` Stephan Mueller
2020-08-03 15:30 ` Elena Petrova
2020-08-04 2:18 ` Herbert Xu
2020-07-13 17:25 ` [PATCH 1/1] " Eric Biggers
2020-07-31 7:26 ` Herbert Xu
2020-08-13 16:00 ` Elena Petrova
2020-08-13 16:01 ` [PATCH v4] " Elena Petrova
2020-08-13 16:04 ` Elena Petrova
2020-08-13 16:08 ` [PATCH v5] " Elena Petrova
2020-08-13 19:32 ` Eric Biggers
2020-08-21 4:24 ` Herbert Xu
2020-09-08 17:04 ` [PATCH v6] " Elena Petrova
2020-09-09 4:35 ` Eric Biggers
2020-09-09 18:29 ` [PATCH v7] " Elena Petrova
2020-09-09 21:00 ` Eric Biggers
2020-09-16 11:07 ` [PATCH v8] " Elena Petrova
2020-09-18 6:43 ` Herbert Xu
2020-09-18 15:42 ` [PATCH v9] " Elena Petrova
2020-09-25 8:16 ` Herbert Xu
2020-09-08 17:23 ` Elena Petrova [this message]
2020-09-08 17:18 ` [PATCH v5] " Elena Petrova
2020-07-14 5:17 ` [PATCH 0/1] " Stephan Mueller
2020-07-14 15:23 ` Elena Petrova
2020-07-14 15:34 ` Stephan Mueller
2020-07-16 14:41 ` Elena Petrova
2020-07-16 14:49 ` Stephan Mueller
2020-07-16 14:59 ` Stephan Mueller
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=CABvBcwYqeGw-9oGngEm01dAt8JLxkKCLFFn9409efcLPTsJg+w@mail.gmail.com \
--to=lenaptr@google.com \
--cc=ardb@kernel.org \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=jeffv@google.com \
--cc=linux-crypto@vger.kernel.org \
--cc=smueller@chronox.de \
/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).