nvme-tcp: kernel NULL pointer dereference, address: 0000000000000034

[Sagi Grimberg]

>>> Could you try this patch with your tcp polling queues enabled?
>>>
>>> ---
>>> diff --git a/block/blk-core.c b/block/blk-core.c
>>> index 9e5e0277a4d95..12f7ab369f7ba 100644
>>> --- a/block/blk-core.c
>>> +++ b/block/blk-core.c
>>> @@ -844,30 +844,12 @@ void submit_bio(struct bio *bio)
>>>    }
>>>    EXPORT_SYMBOL(submit_bio);
>>> -/**
>>> - * bio_poll - poll for BIO completions
>>> - * @bio: bio to poll for
>>> - * @iob: batches of IO
>>> - * @flags: BLK_POLL_* flags that control the behavior
>>> - *
>>> - * Poll for completions on queue associated with the bio. Returns number of
>>> - * completed entries found.
>>> - *
>>> - * Note: the caller must either be the context that submitted @bio, or
>>> - * be in a RCU critical section to prevent freeing of @bio.
>>> - */
>>> -int bio_poll(struct bio *bio, struct io_comp_batch *iob, unsigned int flags)
>>> +static int blk_poll(struct request_queue *q, struct io_comp_batch *iob,
>>> +		    struct bio *bio, unsigned int flags)
>>>    {
>>>    	blk_qc_t cookie = READ_ONCE(bio->bi_cookie);
>>
>> You need to pass in the cookie as well.
>> Probably can pass BLK_QC_T_NONE for blk_rq_poll...
> 
> I don't understand. The bio holds the cookie, and the bio is passed through the
> rq. If we send NONE, then polling won't happen. Will the command be completed
> some other way?

You're right, I thought that NONE then the poll will be called at least 
once. That seem to have changed from the past...

> And since we're talking about this, what happens if a command is dispatched to
> a polled queue, but has no data transfer? The nvme driver doesn't attach a bio
> to the request in that case, so no cookie?

IIRC, initially NONE was called once, and the loop in blk_execute_rq 
looped until the completion was met.

I would assume that any other cookie other than NONE would work here, 
because the driver .poll() would be invoked at least once (maybe set
ONESHOT as well).