On 9/23/21 9:39 AM, Jens Axboe wrote:
On 9/23/21 10:22 AM, Bart Van Assche wrote:
On 9/23/21 9:04 AM, Jens Axboe wrote:
What options are you loading null_blk with?
The issues I reported are the result of running test blk/010 from the
blktests suite. That test loads the null_blk kernel module twice:
_init_null_blk queue_mode=2 submit_queues=16 nr_devices=32
[ ... ]
_exit_null_blk
_init_null_blk queue_mode=2 submit_queues=16 nr_devices=32 shared_tags=1
[ ... ]
_exit_null_blk
Please let me know if you need more information.
Tried both that and running block/010, didn't trigger anything for me.
Odd...
Hi Jens,
I took another look at the kernel logs from yesterday of the VM that I use
for testing. In that kernel log I found the following:
* Without any changes on top of the for-next branch of
git://git.kernel.dk/linux-block (commit 4129031563d0 ("Merge branch
'for-5.16/io_uring' into for-next"), test block/010 triggers the oops
reported at the start of this email thread.
* With the patch at the start of this email thread applied, the first test
that triggers a kernel oops is block/020 (blk_mq_free_rqs+0x1f4).
This morning I rebuilt the block for-next kernel with and without my
null_blk patch applied. I was able to reproduce what I observed yesterday.
Test block/020 passes with if commit 5f7acddf706c ("null_blk: poll queue
support") is reverted. This is why I wrote that my patch does not seem to
be sufficient to fix commit 5f7acddf706c.
Thanks,
Bart.
