Re: lib/mpi: call cond_resched() from mpi_powm() loop

From: Greg KH
Date: Mon Nov 27 2017 - 07:13:08 EST


On Tue, Nov 14, 2017 at 10:46:16PM +0000, Linux Kernel Mailing List wrote:
> Web: https://git.kernel.org/torvalds/c/1d9ddde12e3c9bab7f3d3484eb9446315e3571ca
> Commit: 1d9ddde12e3c9bab7f3d3484eb9446315e3571ca
> Parent: 63c53823f00f0ffd13e8c86b05c1486614a2df85
> Refname: refs/heads/master
> Author: Eric Biggers <ebiggers@xxxxxxxxxx>
> AuthorDate: Tue Nov 7 14:15:27 2017 -0800
> Committer: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> CommitDate: Fri Nov 10 19:20:26 2017 +0800
>
> lib/mpi: call cond_resched() from mpi_powm() loop
>
> 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.
>
> Do the cond_resched() once per bit rather than once per MPI limb because
> each limb might still easily take 100+ milliseconds on slow CPUs.
>
> Cc: <stable@xxxxxxxxxxxxxxx> # v4.12+
> Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
> Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> ---
> lib/mpi/mpi-pow.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/mpi/mpi-pow.c b/lib/mpi/mpi-pow.c
> index e24388a863a7..468fb7cd1221 100644
> --- a/lib/mpi/mpi-pow.c
> +++ b/lib/mpi/mpi-pow.c
> @@ -26,6 +26,7 @@
> * however I decided to publish this code under the plain GPL.
> */
>
> +#include <linux/sched.h>
> #include <linux/string.h>
> #include "mpi-internal.h"
> #include "longlong.h"
> @@ -256,6 +257,7 @@ int mpi_powm(MPI res, MPI base, MPI exp, MPI mod)
> }
> e <<= 1;
> c--;
> + cond_resched();
> }
>
> i--;

Note, I've applied this to kernels older than 4.12 as well, as the issue
seems to also be there as well, right?

thanks,

greg k-h