From: Sagi Grimberg <sagi@grimberg.me>
To: Christoph Hellwig <hch@infradead.org>
Cc: Yi Zhang <yi.zhang@redhat.com>,
linux-block <linux-block@vger.kernel.org>,
"open list:NVM EXPRESS DRIVER" <linux-nvme@lists.infradead.org>
Subject: Re: [bug report] blktests nvme/tcp triggered WARNING at kernel/workqueue.c:2628 check_flush_dependency+0x110/0x14c
Date: Fri, 22 Jul 2022 01:13:26 +0300 [thread overview]
Message-ID: <bd233bf9-d554-89cc-4498-c15a45fe860b@grimberg.me> (raw)
In-Reply-To: <YteeHq8TJBncRvZu@infradead.org>
>>> Hello
>>>
>>> I reproduced this issue on the linux-block/for-next, pls help check
>>> it, feel free to let me know if you need info/test, thanks.
>>
>>
>> These reports are making me tired... Should we just remove
>> MEM_RECLAIM from all nvme/nvmet workqueues are be done with
>> it?
>>
>> The only downside is that nvme reset/error-recovery will
>> also be susceptible for low-memory situation...
>
> We can't just do that. We need to sort out the dependency chains
> properly.
The problem is that nvme_wq is MEM_RECLAIM, and nvme_tcp_wq is
for the socket threads, that does not need to be MEM_RECLAIM workqueue.
But reset/error-recovery that take place on nvme_wq, stop nvme-tcp
queues, and that must involve flushing queue->io_work in order to
fence concurrent execution.
So what is the solution? make nvme_tcp_wq MEM_RECLAIM?
next prev parent reply other threads:[~2022-07-21 22:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-08 16:03 [bug report] blktests nvme/tcp triggered WARNING at kernel/workqueue.c:2628 check_flush_dependency+0x110/0x14c Yi Zhang
2022-07-10 9:41 ` Sagi Grimberg
2022-07-19 16:08 ` Yi Zhang
2022-07-20 6:18 ` Christoph Hellwig
2022-07-21 22:13 ` Sagi Grimberg [this message]
2022-07-22 4:46 ` Christoph Hellwig
2022-07-24 8:21 ` Sagi Grimberg
2022-07-29 7:37 ` Yi Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd233bf9-d554-89cc-4498-c15a45fe860b@grimberg.me \
--to=sagi@grimberg.me \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=yi.zhang@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.