Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ab82c5fd-03d6-683d-2c8a-1b71b940d94a@grimberg.me>
Date:   Sat, 8 Apr 2023 00:34:22 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [PATCH] nvme: fix double blk_mq_complete_request for timeout
 request with low probability
Content-Language: en-US
To:     Keith Busch <kbusch@kernel.org>, Lei Lei2 Yin <yinlei2@lenovo.com>
Cc:     "axboe@fb.com" <axboe@fb.com>, "hch@lst.de" <hch@lst.de>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "cybeyond@foxmail.com" <cybeyond@foxmail.com>
References: <PS1PR03MB4939C825BD5D9A135AA0EB9188919@PS1PR03MB4939.apcprd03.prod.outlook.com>
 <ZDBvTS1j26d3392/@kbusch-mbp.dhcp.thefacebook.com>
From:   Sagi Grimberg <sagi@grimberg.me>
In-Reply-To: <ZDBvTS1j26d3392/@kbusch-mbp.dhcp.thefacebook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
>> index 53ef028596c6..c1cc384f4f3e 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -450,8 +450,8 @@ bool nvme_cancel_request(struct request *req, void *data)
>>   	dev_dbg_ratelimited(((struct nvme_ctrl *) data)->device,
>>   				"Cancelling I/O %d", req->tag);
>>   
>> -	/* don't abort one completed request */
>> -	if (blk_mq_request_completed(req))
>> +	/* don't abort one completed or idle request */
>> +	if (blk_mq_rq_state(req) != MQ_RQ_IN_FLIGHT)
>>   		return true;
> 
> I was suspicious about this path too, and had the same change long ago, but
> shelved it when I couldn't produce any errors there. But the change makes sense
> to me!
> 
> Reviewed-by: Keith Busch <kbusch@kernel.org>

We need to change nvmf_complete_timed_out_request() too.

Reviewed-by: Sagi Grimberg <sagi@grimberg.me>