lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Feb 2024 10:03:01 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Mark Brown <broonie@...nel.org>
Cc: linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>
Subject: Spurious problems when running regmap unit tests in qemu

Hi,

I am observing spurious regmap unit test failures in my qemu test runs.
Examples:

  # raw_noinc_write: ASSERTION FAILED at drivers/base/regmap/regmap-kunit.c:1243
  Expected val_test == val, but
      val_test == 65581 (0x1002d)
      val == 45 (0x2d)
      not ok 8 maple-big
  # raw_noinc_write: pass:7 fail:1 skip:0 total:8

  or

  # raw_noinc_write: ASSERTION FAILED at drivers/base/regmap/regmap-kunit.c:1243
  Expected val_test == val, but
      val_test == 65556 (0x10014)
      val == 20 (0x14)
      not ok 5 rbtree-little
      ok 6 rbtree-big
      ok 7 maple-little
      ok 8 maple-big
  # raw_noinc_write: pass:7 fail:1 skip:0 total:8

The problem is not seen all the time. I see it with various qemu machines,
but not always the same. Endianness does not seem to make a difference.
The failure is always in raw_noinc_write. So far, I have observed the
following individual test failures:

not ok 2 none-big
not ok 4 flat-big
not ok 5 rbtree-little
not ok 8 maple-big

The most recent test run (on v6.8-rc3) failed on the following
architectures and machines (again, those are not always the same).

arm:npcm750-evb:regmap
mips:malta:regmap
mipsel64:malta:regmap
i386:q35:regmap

I only recently started to track unit test failures, so I don't know yet
if this problem has been introduced recently or if it has existed since
the tests were introduced.

Any idea how to debug this problem would be welcome. I'll try to bisect,
but of course that will only help if the problem was introduced recently.

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ