linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Stephan Müller" <smueller@chronox.de>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	Harsh Jain <harsh@chelsio.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	linuxarm@huawei.com
Subject: Re: [PATCH v2 2/4] crypto: AF_ALG - inline IV support
Date: Wed, 07 Feb 2018 15:01:16 +0100	[thread overview]
Message-ID: <2143323.ez0I2IImEf@positron.chronox.de> (raw)
In-Reply-To: <20180207135408.00000119@huawei.com>

Am Mittwoch, 7. Februar 2018, 14:54:08 CET schrieb Jonathan Cameron:

Hi Jonathan,

> 
> It's not a 'bug' as such, but this does currently break the crypto-perf
> test for aio and iiv in the libkcapi branch.  We can perhaps make it
> more forgiving...

I just pushed an update for the IIV branch of libkcapi that handles it 
appropriately.
> 
> I suggest we let noop cases where we set IIV on when it is already on
> to not result in an error but to just be ignored.

I do not like the kernel to behave differently on one and the same flag. 
Though, the check could be more forgiving indeed: if the flag from user space 
is set again and identical to what we already have, we would not report an 
error. Only if it is different from what was already set, we report the error.

> > 
> > +
> > +		/*
> > +		 * IIV can only be enabled once with the first sendmsg call.
> > +		 * This prevents a race in locking and unlocking the
> > +		 * ctx->ivlock mutex.
> > +		 */
> > +		if (ctx->iiv == ALG_IIV_UNSET) {
> > +			ctx->iiv = iiv;
> > +		} else if (iiv == ALG_IIV_USE) {
> 
> So the issue in kcapi is that we are running a tight loop around a test case
> that does a certain number of aio messages.  At the start of each run of
> that performance loop we reinitialize.
> 
> There is an optmisation in there though which avoids an accept call (which
> would have given a new context) if we have one available already.
> 
> The result is that we are reusing the context which already has this
> set.
> 
> So, can we be a little less restrictive and let things through
> if and only iff iiv = ctx->iiv - i.e. the set is a noop?

Precisely, will do in the next version of the patch set.

Ciao
Stephan

  reply	other threads:[~2018-02-07 14:01 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 13:21 [RFC] AF_ALG AIO and IV Stephan Mueller
2018-01-15  9:35 ` [PATCH] crypto: AF_ALG - inline IV support Stephan Mueller
2018-01-21 12:14   ` Stephan Müller
2018-01-23 11:02     ` Harsh Jain
2018-01-30  8:27       ` [PATCH] crypto: AF_ALG AIO - lock context IV Stephan Müller
2018-01-30 14:04         ` Stephan Mueller
2018-01-30 15:51         ` Jonathan Cameron
2018-01-31 12:29           ` Jonathan Cameron
2018-02-01  9:35             ` Gilad Ben-Yossef
2018-02-01  9:46               ` Stephan Mueller
2018-02-01 10:06                 ` Gilad Ben-Yossef
2018-02-01 10:15                   ` Stephan Mueller
2018-02-01 10:04               ` Stephan Mueller
2018-02-01 10:07                 ` Gilad Ben-Yossef
2018-02-01 10:25                   ` Jonathan Cameron
2018-02-01 10:55                     ` Harsh Jain
2018-02-07  7:42                     ` [PATCH v2 0/4] crypto: AF_ALG AIO improvements Stephan Müller
2018-02-07  7:43                       ` [PATCH v2 1/4] crypto: AF_ALG AIO - lock context IV Stephan Müller
2018-02-07  7:43                       ` [PATCH v2 2/4] crypto: AF_ALG - inline IV support Stephan Müller
2018-02-07 13:54                         ` Jonathan Cameron
2018-02-07 14:01                           ` Stephan Müller [this message]
2018-02-07  7:43                       ` [PATCH v2 3/4] crypto: AF_ALG - allow driver to serialize IV access Stephan Müller
2018-02-07  7:44                       ` [PATCH v2 4/4] crypto: add CRYPTO_TFM_REQ_PARALLEL flag Stephan Müller
2018-02-07 12:48                         ` Stephan Mueller
2018-02-07 15:39                           ` Jonathan Cameron
2018-02-07 15:43                             ` Stephan Mueller
2018-02-07 16:14                               ` Jonathan Cameron
2018-02-07 16:25                                 ` Stephan Mueller
2018-02-07  8:52                       ` [PATCH v2 0/4] crypto: AF_ALG AIO improvements Harsh Jain
2018-02-07 15:37                       ` Jonathan Cameron
2018-02-09 22:02                       ` [PATCH v3 " Stephan Müller
2018-02-09 22:03                         ` [PATCH v3 1/4] crypto: AF_ALG AIO - lock context IV Stephan Müller
2018-02-14  5:43                           ` Harsh Jain
2018-02-14 12:52                             ` Stephan Mueller
2018-02-15  5:30                               ` Harsh Jain
2018-02-15  6:28                                 ` Stephan Mueller
2018-02-15  7:03                                   ` Harsh Jain
2018-02-15  7:17                                     ` Stephan Mueller
2018-02-15 11:38                                       ` Harsh Jain
2018-02-15 11:45                                         ` Stephan Mueller
2018-02-15 12:45                                           ` Harsh Jain
2018-02-15 13:04                                             ` Stephan Mueller
2018-02-15 13:26                                               ` Jeffrey Walton
2018-02-15 18:09                                               ` Stephan Mueller
2018-02-09 22:03                         ` [PATCH v3 2/4] crypto: AF_ALG - inline IV support Stephan Müller
2018-02-09 22:04                         ` [PATCH v3 3/4] crypto: AF_ALG - allow driver to serialize IV access Stephan Müller
2018-02-09 22:04                         ` [PATCH v3 4/4] crypto: add CRYPTO_TFM_REQ_IV_SERIALIZE flag Stephan Müller
2018-02-14  5:50                           ` Harsh Jain
2018-02-14 12:47                             ` Stephan Mueller
2018-01-22 14:11   ` [PATCH] crypto: AF_ALG - inline IV support Jonathan Cameron
2018-01-22 14:30     ` Stephan Mueller
2018-01-22 14:52       ` Jonathan Cameron
2018-01-15  9:39 ` [RFC] AF_ALG AIO and IV Stephan Mueller
2018-01-15 11:05 ` Jonathan Cameron
2018-01-15 12:07   ` Stephan Mueller
2018-01-15 12:59     ` Jonathan Cameron
2018-01-15 13:15       ` Stephan Mueller
2018-01-15 14:25         ` Jonathan Cameron
2018-01-15 14:31           ` Stephan Mueller
2018-01-15 14:42             ` Jonathan Cameron
2018-01-16  6:28               ` Stephan Mueller
2018-01-16 10:51                 ` Jonathan Cameron
2018-01-15 14:37           ` Jonathan Cameron

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=2143323.ez0I2IImEf@positron.chronox.de \
    --to=smueller@chronox.de \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=gilad@benyossef.com \
    --cc=harsh@chelsio.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linuxarm@huawei.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).