| Message ID | 20210124142806.GA29180@ls3530.fritz.box (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | crypto: xor - avoid division by zero crash | expand |
On Sun, 24 Jan 2021 at 15:28, Helge Deller <deller@gmx.de> wrote: > > On some of my parisc machines, this patch c055e3eae0f1 ("crypto: xor - > use ktime for template benchmarking") triggers a dividy-by-zero > exception because "min" becomes zero, which then leads to a kernel > crash. > > It's not clear yet, why I see the issue only on some machines. At least > on those the measured time to run the xor speed tests becomes zero > nanoseconds. Maybe it's because gcc-10 optimizes the speed test out, or > because of some other changes in the time keeping routines. > > In either case, the kernel should not crash. > > This patch adds a workaround by reporting such cases with a kernel > warning and continues as if the xor tests would have run in 1 ns. > > Signed-off-by: Helge Deller <deller@gmx.de> > Cc: stable@vger.kernel.org # 5.10+ > > --- > > diff --git a/crypto/xor.c b/crypto/xor.c > index eacbf4f93990..3639341bac7e 100644 > --- a/crypto/xor.c > +++ b/crypto/xor.c > @@ -100,6 +100,8 @@ do_xor_speed(struct xor_block_template *tmpl, void *b1, void *b2) > mb(); > } > diff = ktime_sub(ktime_get(), start); > + if (WARN_ON(diff == 0)) > + diff = 1; > if (diff < min) > min = diff; > } This should already be fixed in mainline - please check whether that fix works for you.
On 1/24/21 3:30 PM, Ard Biesheuvel wrote: > On Sun, 24 Jan 2021 at 15:28, Helge Deller <deller@gmx.de> wrote: >> >> On some of my parisc machines, this patch c055e3eae0f1 ("crypto: xor - >> use ktime for template benchmarking") triggers a dividy-by-zero >> exception because "min" becomes zero, which then leads to a kernel >> crash. >> >> It's not clear yet, why I see the issue only on some machines. At least >> on those the measured time to run the xor speed tests becomes zero >> nanoseconds. Maybe it's because gcc-10 optimizes the speed test out, or >> because of some other changes in the time keeping routines. >> >> In either case, the kernel should not crash. >> >> This patch adds a workaround by reporting such cases with a kernel >> warning and continues as if the xor tests would have run in 1 ns. >> >> Signed-off-by: Helge Deller <deller@gmx.de> >> Cc: stable@vger.kernel.org # 5.10+ >> >> --- >> >> diff --git a/crypto/xor.c b/crypto/xor.c >> index eacbf4f93990..3639341bac7e 100644 >> --- a/crypto/xor.c >> +++ b/crypto/xor.c >> @@ -100,6 +100,8 @@ do_xor_speed(struct xor_block_template *tmpl, void *b1, void *b2) >> mb(); >> } >> diff = ktime_sub(ktime_get(), start); >> + if (WARN_ON(diff == 0)) >> + diff = 1; >> if (diff < min) >> min = diff; >> } > > This should already be fixed in mainline - please check whether that > fix works for you. Yes, it's basically the same fix and a good step. It fixes the kernel crash at least, but it's still strange that the timing calculation will be wrong. Helge
diff --git a/crypto/xor.c b/crypto/xor.c index eacbf4f93990..3639341bac7e 100644 --- a/crypto/xor.c +++ b/crypto/xor.c @@ -100,6 +100,8 @@ do_xor_speed(struct xor_block_template *tmpl, void *b1, void *b2) mb(); } diff = ktime_sub(ktime_get(), start); + if (WARN_ON(diff == 0)) + diff = 1; if (diff < min) min = diff; }
On some of my parisc machines, this patch c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking") triggers a dividy-by-zero exception because "min" becomes zero, which then leads to a kernel crash. It's not clear yet, why I see the issue only on some machines. At least on those the measured time to run the xor speed tests becomes zero nanoseconds. Maybe it's because gcc-10 optimizes the speed test out, or because of some other changes in the time keeping routines. In either case, the kernel should not crash. This patch adds a workaround by reporting such cases with a kernel warning and continues as if the xor tests would have run in 1 ns. Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # 5.10+ ---