On 9/23/21 11:51 AM, Bart Van Assche wrote:
> 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.
Ah ok, so it's block/020, not block/010 for the later one. I'll take a
look.
--
Jens Axboe
