From: Eric Biggers <ebiggers3@gmail.com>
To: Mat Martineau <mathew.j.martineau@linux.intel.com>
Cc: linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
Tudor-Dan Ambarus <tudor.ambarus@microchip.com>,
Salvatore Benedetto <salvatore.benedetto@intel.com>,
keyrings@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric Biggers <ebiggers@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] lib/mpi: call cond_resched() from mpi_powm() loop
Date: Tue, 07 Nov 2017 22:03:52 +0000 [thread overview]
Message-ID: <20171107220352.GB83529@gmail.com> (raw)
In-Reply-To: <alpine.OSX.2.21.1711070921100.18896@afarcy-mobl1.amr.corp.intel.com>
On Tue, Nov 07, 2017 at 10:38:30AM -0800, Mat Martineau wrote:
>
> Eric,
>
> On Mon, 6 Nov 2017, Eric Biggers wrote:
>
> >From: Eric Biggers <ebiggers@google.com>
> >
> >On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the
> >largest permitted inputs (16384 bits), the kernel spends 10+ seconds
> >doing modular exponentiation in mpi_powm() without rescheduling. If all
> >threads do it, it locks up the system. Moreover, it can cause
> >rcu_sched-stall warnings.
> >
> >Notwithstanding the insanity of doing this calculation in kernel mode
> >rather than in userspace, fix it by calling cond_resched() as each bit
> >from the exponent is processed. It's still noninterruptible, but at
> >least it's preemptible now.
>
> cond_resched() is in the outer loop and gets called every
> BITS_PER_LONG bits. That seems to be often enough for the system
> that was taking 10+ seconds, and might be ok for slower processors.
>
> Was your intent to call cond_resched() for every bit as you
> described in the commit message?
>
You're right, the cond_resched() is actually once per "limb", not once per bit.
With the largest permitted inputs (16384 bits), each limb of the exponent takes
about 38 milliseconds on an x86_64 CPU. Therefore on some other CPUs it will
probably take 100+ milliseconds, which is much too long. So I guess it should
do cond_resched() for each bit. I'll send a revised patch...
Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: Mat Martineau <mathew.j.martineau@linux.intel.com>
Cc: linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
Tudor-Dan Ambarus <tudor.ambarus@microchip.com>,
Salvatore Benedetto <salvatore.benedetto@intel.com>,
keyrings@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric Biggers <ebiggers@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] lib/mpi: call cond_resched() from mpi_powm() loop
Date: Tue, 7 Nov 2017 14:03:52 -0800 [thread overview]
Message-ID: <20171107220352.GB83529@gmail.com> (raw)
In-Reply-To: <alpine.OSX.2.21.1711070921100.18896@afarcy-mobl1.amr.corp.intel.com>
On Tue, Nov 07, 2017 at 10:38:30AM -0800, Mat Martineau wrote:
>
> Eric,
>
> On Mon, 6 Nov 2017, Eric Biggers wrote:
>
> >From: Eric Biggers <ebiggers@google.com>
> >
> >On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the
> >largest permitted inputs (16384 bits), the kernel spends 10+ seconds
> >doing modular exponentiation in mpi_powm() without rescheduling. If all
> >threads do it, it locks up the system. Moreover, it can cause
> >rcu_sched-stall warnings.
> >
> >Notwithstanding the insanity of doing this calculation in kernel mode
> >rather than in userspace, fix it by calling cond_resched() as each bit
> >from the exponent is processed. It's still noninterruptible, but at
> >least it's preemptible now.
>
> cond_resched() is in the outer loop and gets called every
> BITS_PER_LONG bits. That seems to be often enough for the system
> that was taking 10+ seconds, and might be ok for slower processors.
>
> Was your intent to call cond_resched() for every bit as you
> described in the commit message?
>
You're right, the cond_resched() is actually once per "limb", not once per bit.
With the largest permitted inputs (16384 bits), each limb of the exponent takes
about 38 milliseconds on an x86_64 CPU. Therefore on some other CPUs it will
probably take 100+ milliseconds, which is much too long. So I guess it should
do cond_resched() for each bit. I'll send a revised patch...
Eric
next prev parent reply other threads:[~2017-11-07 22:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-07 6:19 [PATCH] lib/mpi: call cond_resched() from mpi_powm() loop Eric Biggers
2017-11-07 6:19 ` Eric Biggers
2017-11-07 18:38 ` Mat Martineau
2017-11-07 18:38 ` Mat Martineau
2017-11-07 18:38 ` Mat Martineau
2017-11-07 22:03 ` Eric Biggers [this message]
2017-11-07 22:03 ` Eric Biggers
2017-11-10 11:37 ` Herbert Xu
2017-11-10 11:37 ` Herbert Xu
2017-11-10 18:41 ` Eric Biggers
2017-11-10 18:41 ` Eric Biggers
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=20171107220352.GB83529@gmail.com \
--to=ebiggers3@gmail.com \
--cc=ebiggers@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathew.j.martineau@linux.intel.com \
--cc=salvatore.benedetto@intel.com \
--cc=stable@vger.kernel.org \
--cc=tudor.ambarus@microchip.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.