Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: linux-next: Tree for Oct 25
To:     Ming Lei <ming.lei@redhat.com>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Jens Axboe <axboe@kernel.dk>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-mmc <linux-mmc@vger.kernel.org>,
        linux-block <linux-block@vger.kernel.org>
References: <20211025204921.73cb3011@canb.auug.org.au>
 <82bbf33e-918f-da01-95e6-9b2cc1b8b610@gmail.com> <YXdZxzAPejKyE8Oi@T590>
From:   Dmitry Osipenko <digetx@gmail.com>
Message-ID: <82558c85-d3be-e158-54f1-b3067f15fa21@gmail.com>
Date:   Tue, 26 Oct 2021 11:40:09 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <YXdZxzAPejKyE8Oi@T590>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

26.10.2021 04:28, Ming Lei пишет:
> On Tue, Oct 26, 2021 at 01:11:07AM +0300, Dmitry Osipenko wrote:
>> Hello,
>>
>> Recent -next has this new warning splat coming from MMC, please take a look.
>>
>>  ------------[ cut here ]------------
>>  WARNING: CPU: 0 PID: 525 at kernel/sched/core.c:9477 __might_sleep+0x65/0x68
>>  do not call blocking ops when !TASK_RUNNING; state=2 set at [<4316eb02>] prepare_to_wait+0x2e/0xb8
>>  Modules linked in:
>>  CPU: 0 PID: 525 Comm: Xorg Tainted: G        W         5.15.0-rc6-next-20211025-00226-g89ccd6948ec3 #5
>>  Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
>>  (unwind_backtrace) from [<c01089f9>] (show_stack+0x11/0x14)
>>  (show_stack) from [<c0afacb9>] (dump_stack_lvl+0x2b/0x34)
>>  (dump_stack_lvl) from [<c011f689>] (__warn+0xa1/0xe8)
>>  (__warn) from [<c0af6729>] (warn_slowpath_fmt+0x65/0x7c)
>>  (warn_slowpath_fmt) from [<c01421b9>] (__might_sleep+0x65/0x68)
>>  (__might_sleep) from [<c07eb377>] (mmc_blk_rw_wait+0x2f/0x118)
>>  (mmc_blk_rw_wait) from [<c07eba11>] (mmc_blk_mq_issue_rq+0x219/0x71c)
>>  (mmc_blk_mq_issue_rq) from [<c07ec199>] (mmc_mq_queue_rq+0xf9/0x200)
>>  (mmc_mq_queue_rq) from [<c04ad247>] (__blk_mq_try_issue_directly+0xcb/0x100)
>>  (__blk_mq_try_issue_directly) from [<c04adb89>] (blk_mq_request_issue_directly+0x2d/0x48)
>>  (blk_mq_request_issue_directly) from [<c04adcf3>] (blk_mq_flush_plug_list+0x14f/0x1f4)
>>  (blk_mq_flush_plug_list) from [<c04a5313>] (blk_flush_plug+0x83/0xb8)
>>  (blk_flush_plug) from [<c0b013cb>] (io_schedule+0x2b/0x3c)
>>  (io_schedule) from [<c0b01a17>] (bit_wait_io+0xf/0x48)
> 
> The following patch should fix the issue:
> 
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index a71aeed7b987..bee9cb2a44cb 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -2223,7 +2223,7 @@ void blk_mq_flush_plug_list(struct blk_plug *plug, bool from_schedule)
>  		return;
>  	plug->rq_count = 0;
>  
> -	if (!plug->multiple_queues && !plug->has_elevator) {
> +	if (!plug->multiple_queues && !plug->has_elevator && !from_schedule) {
>  		blk_mq_plug_issue_direct(plug, from_schedule);
>  		if (rq_list_empty(plug->mq_list))
>  			return;
> 

Thank you!

Tested-by: Dmitry Osipenko <digetx@gmail.com>