Re: [PATCH] blk-mq: put driver tag when this request is completed

From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH] blk-mq: put driver tag when this request is completed
Date: Wed, 1 Jul 2020 16:58:22 +0200	[thread overview]
Message-ID: <cd3761d3-6bf8-33d5-29c7-58beaa4aa965@samsung.com> (raw)
In-Reply-To: <2fcd389f-b341-7cd1-692b-8c9d1918198a@samsung.com>

Hi,

On 01.07.2020 16:16, Marek Szyprowski wrote:
> On 01.07.2020 15:45, Ming Lei wrote:
>> On Wed, Jul 01, 2020 at 03:01:03PM +0200, Marek Szyprowski wrote:
>>> On 29.06.2020 11:47, Ming Lei wrote:
>>>> It is natural to release driver tag when this request is completed by
>>>> LLD or device since its purpose is for LLD use.
>>>>
>>>> One big benefit is that the released tag can be re-used quicker since
>>>> bio_endio() may take too long.
>>>>
>>>> Meantime we don't need to release driver tag for flush request.
>>>>
>>>> Cc: Christoph Hellwig <hch@lst.de>
>>>> Signed-off-by: Ming Lei <ming.lei@redhat.com>
>>> This patch landed recently in linux-next as commit 36a3df5a4574. Sadly
>>> it causes a regression on one of my test systems (ARM 32bit, Samsung
>>> Exynos5422 SoC based Odroid XU3 board with eMMC). The system boots fine
>>> and then after a few seconds every executed command hangs. No
>>> panic/ops/any other message. I will try to provide more information 
>>> asap
>>> I find something to share. Simple reverting it in linux-next is not
>>> possible due to dependencies.
>> What is the exact eMMC's driver code(include the host driver)?
>
> dwmmc-exynos (drivers/mmc/host/dw_mmc-exynos.c)
>
>> The usual way for handling completion is that host driver notifies block
>> layer via blk_mq_complete_request() after the LLD specific handling for
>> this request is done.
>>
>> However, there might be driver which may use rq->tag in its rq 
>> completion
>> handler. I will see if the special case can be dealt with once you share
>> the driver info.

One more information: revering 37f4a24c2469a10a4c16c641671bd766e276cf9f, 
723bf178f158abd1ce6069cb049581b3cb003aab and 
36a3df5a4574d5ddf59804fcd0c4e9654c514d9a on top of today's linux-next 
fixes the issues on the tested system, what shows that the bisect is 
indeed correct and there is no other hidden issue.

The most surprising thing to me is that other Exynos5422-based boards I 
have, which also use same eMMC controller, work fine...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland