Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 16 Mar 2021 17:46:45 +0000
From:   Luis Chamberlain <mcgrof@kernel.org>
To:     linux-block@vger.kernel.org, jejb@linux.ibm.com,
        martin.petersen@oracle.com
Cc:     Luis Chamberlain <mcgrof@kernel.org>, linux-scsi@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: blktests: block/009 next-20210304 failure rate average of 1/448
Message-ID: <20210316174645.GI4332@42.do-not-panic.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk

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