From: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-crypto <linux-crypto@vger.kernel.org>,
James Bottomley <James.Bottomley@suse.de>,
Christoph Hellwig <hch@lst.de>,
Randy Dunlap <rdunlap@xenotime.net>,
linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 0/2] Add struct crypto_alg->cra_check_optimized for crc32c_intel
Date: Mon, 14 Mar 2011 05:14:17 -0700 [thread overview]
Message-ID: <1300104857.28255.77.camel@haakon2.linux-iscsi.org> (raw)
In-Reply-To: <20110313090158.GA12473@gondor.apana.org.au>
On Sun, 2011-03-13 at 17:01 +0800, Herbert Xu wrote:
> On Thu, Mar 10, 2011 at 02:05:17AM -0800, Nicholas A. Bellinger wrote:
> >
> > We are still expecting the libcrypto consumer (iscsi_target_mod.ko) to
> > call the arch independent crypto_alloc_hash("crc32c", ...) in order to
> > have libcrypto backend logic perform a request_module() upon
> > architecture dependent offload modules (like crc32c_intel.ko) that
> > libcrypto consumers are not (and should not) be calling directly via
> > crypto_alloc_host("crc32c_intel", ...), correct..?
>
> Right.
>
> > Where I am getting confused is wrt to a new crypto_alg_mod_lookup() ->
> > request_module() call for a struct shash_alg that has not yet be loaded
> > via arch/x86/crypto/crc32c-intel.c:crc32c_intel_mod_init() ->
> > crypto_register_shash().
>
> If you look at crypto_alg_mod_lookup, basically there are two paths.
> Either we already have a registered algorithm of the requested name,
> or we don't.
>
> In the first case, we won't invoke request_module and in the second
> case we will.
>
> So what I'm suggesting is that in the first case we also invoke
> request_module conditionally. Now exactly what that condition is
> is the tricky bit.
>
> The easiest is to flip a bit in the algorithm we just found. This
> isn't optimal as it'll mean that for each unregistered algorithm
> we'll end up modprobing twice, but that shouldn't be too bad I
> think.
>
Hi Herbert,
Thanks for your feedback on this issue, and again my apologies for the
lack of experience beyond the external libcrypto API. I will take
another look this week and see if something can be produced more along
the lines of what you had in mind to resolve this special case. In the
mean time the extra crypto_alloc_hash("crc32c-intel", ...) calls have
been removed from RFC-v2 iscsi-target code posted earlier this morning.
Please feel free to add any other pointers and I will have a look.
Best Regards,
--nab
prev parent reply other threads:[~2011-03-14 12:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 8:21 [PATCH 0/2] Add struct crypto_alg->cra_check_optimized for crc32c_intel Nicholas A. Bellinger
2011-03-10 8:21 ` [PATCH 1/2] crypto: Add struct crypto_alg->cra_check_optimized Nicholas A. Bellinger
2011-03-10 8:21 ` [PATCH 2/2] crypto/crc32c: Add crc32c_cra_check_optimized for crc32c_intel Nicholas A. Bellinger
2011-03-10 8:43 ` [PATCH 0/2] Add struct crypto_alg->cra_check_optimized " Herbert Xu
2011-03-10 8:54 ` Nicholas A. Bellinger
2011-03-10 9:09 ` Herbert Xu
2011-03-10 9:13 ` Nicholas A. Bellinger
2011-03-10 10:05 ` Nicholas A. Bellinger
2011-03-13 9:01 ` Herbert Xu
2011-03-14 12:14 ` Nicholas A. Bellinger [this message]
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=1300104857.28255.77.camel@haakon2.linux-iscsi.org \
--to=nab@linux-iscsi.org \
--cc=James.Bottomley@suse.de \
--cc=hch@lst.de \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rdunlap@xenotime.net \
/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