Re: [PATCH] null_blk: Fix a NULL pointer dereference

[Bart Van Assche <bvanassche@acm.org>]

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.