linux-kernel - blktests: block/009 next-20210304 failure rate average of 1/448

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:   Tue, 16 Mar 2021 17:46:45 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     linux-block@...r.kernel.org, jejb@...ux.ibm.com,
        martin.petersen@...cle.com
Cc:     Luis Chamberlain <mcgrof@...nel.org>, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: blktests: block/009 next-20210304 failure rate average of 1/448

I've managed to reproduce blktests block/009 failures with kdevops [0]
on linux-next tag next-20210304 with a current failure rate average of
1/448 (3 counted failures so far). I've documented the failure on
korg#212305 [1] and provide instructions on how to reproduce. The
failure happens on KVM virtualized guests, for the host OS I am
using debian testing, but the target kernel is linux-next.

My personal suspicion is not on the block layer but on scsi_debug
because this can fail:

modprobe scsi_debug; rmmod scsi_debug

This second issue may be a secondary separate issue, but I figured 
I'd mention it. To fix this later issue I've looked at ways to
make scsi_debug_init() wait until its scsi devices are probed,
however its not clear how to do this correctly. If someone has
an idea let me know. If that fixes this issue then we know it was
that.

[0] https://github.com/mcgrof/kdevops
[1] https://bugzilla.kernel.org/show_bug.cgi?id=212305

  Luis