Re: [PATCH 2/7] block: Remove bio->bi_ioc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018/11/21 11:49, Jens Axboe wrote:
> On 11/20/18 7:45 PM, Damien Le Moal wrote:
>> On 2018/11/21 11:11, Jens Axboe wrote:
>>> On 11/20/18 4:58 PM, Damien Le Moal wrote:
>>>> On 2018/11/21 2:31, Jens Axboe wrote:
>>>>> I think the below should fix it, we haven't necessarily setup an
>>>>> ioc if we're just doing as passthrough request.
>>>>>
>>>>>
>>>>> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
>>>>> index 13b8dc332541..f096d8989773 100644
>>>>> --- a/block/blk-mq-sched.c
>>>>> +++ b/block/blk-mq-sched.c
>>>>> @@ -34,9 +34,16 @@ EXPORT_SYMBOL_GPL(blk_mq_sched_free_hctx_data);
>>>>>  void blk_mq_sched_assign_ioc(struct request *rq)
>>>>>  {
>>>>>  	struct request_queue *q = rq->q;
>>>>> -	struct io_context *ioc = current->io_context;
>>>>> +	struct io_context *ioc;
>>>>>  	struct io_cq *icq;
>>>>>  
>>>>> +	/*
>>>>> +	 * May not have an IO context if it's a passthrough request
>>>>> +	 */
>>>>> +	ioc = current->io_context;
>>>>> +	if (!ioc)
>>>>> +		return;
>>>>> +
>>>>>  	spin_lock_irq(&q->queue_lock);
>>>>>  	icq = ioc_lookup_icq(ioc, q);
>>>>>  	spin_unlock_irq(&q->queue_lock);
>>>>
>>>> This seems reasonable to me, but I wonder why this problem was not triggering
>>>> before. The previous code getting the ioc with the rq_ioc(bio) call was
>>>> essentially the same and there was no "if (!ioc) return;" in
>>>> blk_mq_sched_assign_ioc() before the patch.
>>>> Any idea why this is popping up now ?
>>>>
>>>> Ming,
>>>>
>>>> Is this a new test your are running ? If this same problem triggers on stable
>>>> kernels, Jens patch needs to go to stable too.
>>>
>>> No, it's definitely introduced in your patches:
>>>
>>> -                       if (e->type->icq_cache && rq_ioc(bio))
>>> -                               blk_mq_sched_assign_ioc(rq, bio);
>>> +                       if (e->type->icq_cache)
>>> +                               blk_mq_sched_assign_ioc(rq);
>>>
>>> Please run blktests on a series. Always. There's no excuse not to.
>>
>> By the way, should I send an updated patch 2 to include your fix ?
>> Or will you add an incremental fix ?
> 
> I had to add the incremental fix, I already merged your patches
> earlier. It's all pushed out now.

Thank you.


-- 
Damien Le Moal
Western Digital Research




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux