linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tero Kristo <t-kristo@ti.com>
To: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@google.com>,
	David Miller <davem@davemloft.net>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	<linux-omap@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 09/10] crypto: add timeout to crypto_wait_req
Date: Wed, 6 Nov 2019 09:25:18 +0200	[thread overview]
Message-ID: <076f0bc6-ad04-9543-db02-d7c7060db036@ti.com> (raw)
In-Reply-To: <CAOtvUMeBXjDBhSVgMOW=hshEx_AkNPg-Zk2c2jCDzY8vyXWW5g@mail.gmail.com>

On 06/11/2019 08:39, Gilad Ben-Yossef wrote:
> Hi,
> 
> 
> On Thu, Oct 17, 2019 at 3:26 PM Tero Kristo <t-kristo@ti.com> wrote:
>>
>> Currently crypto_wait_req waits indefinitely for an async crypto request
>> to complete. This is bad as it can cause for example the crypto test
>> manager to hang without any notification as to why it has happened.
>> Instead of waiting indefinitely, add a 1 second timeout to the call,
>> and provide a warning print if a timeout happens.
> 
> While the incentive is clear and positive, this suggested solution
> creates problems of its own.
> In many (most?) cases where we are waiting here, we are waiting for a
> DMA operation to finish from hardware.
> Exiting while this pending DMA operation is not finished, even with a
> proper error return value, is dangerous because
> unless the calling code takes great care to not release the memory the
> DMA is being done from/to, this can have disastrous effects.
> 
> As Eric has already mentioned, one second might seem like a long time,
> but we don't really know if it is enough.
> 
> How about adding a second API (ig. crypto_wait_req_timeout) which
> supports a calee specified timeout where
> the calle knows how to correctly deal with timeout and port the
> relevant call sites to use this?

Yeah, that would work for me. I guess we could just swap the testmgr to 
use this timeout API, as it is quite clear it should timeout rather than 
wait indefinitely, and afaics, the data buffers it uses are limited 
size. It doesn't really matter for it whether the timeout is 1 second or 
10 seconds, as long as it eventually times out.

-Tero

> 
> Thanks!
> Gilad
> 
> 
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   include/linux/crypto.h | 9 ++++++++-
>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
>> index 19ea3a371d7b..b8f0e5c3cc0c 100644
>> --- a/include/linux/crypto.h
>> +++ b/include/linux/crypto.h
>> @@ -682,8 +682,15 @@ static inline int crypto_wait_req(int err, struct crypto_wait *wait)
>>          switch (err) {
>>          case -EINPROGRESS:
>>          case -EBUSY:
>> -               wait_for_completion(&wait->completion);
>> +               err = wait_for_completion_timeout(&wait->completion,
>> +                                                 msecs_to_jiffies(1000));
>>                  reinit_completion(&wait->completion);
>> +               if (!err) {
>> +                       pr_err("%s: timeout for %p\n", __func__, wait);
>> +                       err = -ETIMEDOUT;
>> +                       break;
>> +               }
>> +
>>                  err = wait->err;
>>                  break;
>>          };
>> --
>> 2.17.1
>>
>> --
> 
> 
> 
> --
> Gilad Ben-Yossef
> Chief Coffee Drinker
> 
> values of β will give rise to dom!
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

  reply	other threads:[~2019-11-06  7:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17 12:25 [PATCH 00/10] crypto: omap fixes towards 5.5 Tero Kristo
2019-10-17 12:25 ` [PATCH 01/10] crypto: omap-sham: split up data to multiple sg elements with huge data Tero Kristo
2019-10-17 12:25 ` [PATCH 02/10] crypto: omap-sham: remove the sysfs group during driver removal Tero Kristo
2019-10-17 12:25 ` [PATCH 03/10] crypto: omap-aes: " Tero Kristo
2019-10-17 12:25 ` [PATCH 04/10] crypto: omap-des: add IV output handling Tero Kristo
2019-10-17 12:25 ` [PATCH 05/10] crypto: omap-aes: " Tero Kristo
2019-10-17 12:25 ` [PATCH 06/10] crypto: omap-sham: fix buffer handling for split test cases Tero Kristo
2019-10-17 12:25 ` [PATCH 07/10] crypto: omap-aes-gcm: fix corner case with only auth data Tero Kristo
2019-10-26 15:04   ` Ard Biesheuvel
2019-10-17 12:25 ` [PATCH 08/10] crypto: omap-sham: fix split update cases with cryptomgr tests Tero Kristo
2019-10-17 12:25 ` [PATCH 09/10] crypto: add timeout to crypto_wait_req Tero Kristo
2019-11-05 17:42   ` Eric Biggers
2019-11-06  6:39   ` Gilad Ben-Yossef
2019-11-06  7:25     ` Tero Kristo [this message]
2019-11-06  7:33       ` Gilad Ben-Yossef
2019-11-08  2:27         ` Eric Biggers
2019-11-08  7:40           ` Tero Kristo
2019-11-08  9:16             ` Herbert Xu
2019-11-08  9:22               ` Tero Kristo
2019-11-09  2:27                 ` Eric Biggers
2019-11-09  5:01                   ` Herbert Xu
2019-10-17 12:25 ` [PATCH 10/10] crypto: omap-aes: fixup aligned data cleanup Tero Kristo
2019-10-25 11:33 ` [PATCH 00/10] crypto: omap fixes towards 5.5 Ard Biesheuvel
2019-10-25 11:55   ` Tero Kristo
2019-10-25 11:56     ` Tero Kristo
2019-10-25 12:05       ` Ard Biesheuvel
2019-10-25 12:18         ` Tero Kristo
2019-10-26 15:06           ` Ard Biesheuvel

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=076f0bc6-ad04-9543-db02-d7c7060db036@ti.com \
    --to=t-kristo@ti.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=davem@davemloft.net \
    --cc=ebiggers@google.com \
    --cc=gilad@benyossef.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    /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).