From: Keith Busch <kbusch@kernel.org>
To: Nilay Shroff <nilay@linux.ibm.com>
Cc: linux-nvme@lists.infradead.org, axboe@fb.com, hch@lst.de,
sagi@grimberg.me, linux-block@vger.kernel.org,
gjoyce@linux.ibm.com
Subject: Re: [PATCH RESEND] nvme-pci: Fix EEH failure on ppc after subsystem reset
Date: Sun, 10 Mar 2024 22:41:38 -0600 [thread overview]
Message-ID: <Ze6LglWPqkHVFh-P@kbusch-mbp.mynextlight.net> (raw)
In-Reply-To: <301b8f41-a146-497a-916f-97d91829d28c@linux.ibm.com>
On Sun, Mar 10, 2024 at 12:35:06AM +0530, Nilay Shroff wrote:
> On 3/9/24 21:14, Keith Busch wrote:
> > Your patch may observe a ctrl in "RESETTING" state from
> > error_detected(), then disable the controller, which quiesces the admin
> > queue. Meanwhile, reset_work may proceed to CONNECTING state and try
> > nvme_submit_sync_cmd(), which blocks forever because no one is going to
> > unquiesce that admin queue.
> >
> OK I think I got your point. However, it seems that even without my patch
> the above mentioned deadlock could still be possible.
I sure hope not. The current design should guarnatee forward progress on
initialization failed devices.
> Without my patch, if error_detcted() observe a ctrl in "RESETTING" state then
> it still invokes nvme_dev_disable(). The only difference with my patch is that
> error_detected() returns the PCI_ERS_RESULT_NEED_RESET instead of PCI_ERS_RESULT_DISCONNECT.
There's one more subtle difference: that condition disables with the
'shutdown' parameter set to 'true' which accomplishes a couple things:
all entered requests are flushed to their demise via the final
unquiesce, and all request_queue's are killed which forces error returns
for all new request allocations. No thread will be left waiting for
something that won't happen.
next prev parent reply other threads:[~2024-03-11 4:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-09 5:02 [PATCH RESEND] nvme-pci: Fix EEH failure on ppc after subsystem reset Nilay Shroff
2024-02-22 21:00 ` Greg Joyce
[not found] ` <2c76725c-7bb6-4827-b45a-dbe1acbefba7@imap.linux.ibm.com>
2024-02-27 18:14 ` Nilay Shroff
2024-02-27 18:29 ` Keith Busch
2024-02-28 11:19 ` Nilay Shroff
2024-02-29 12:27 ` Nilay Shroff
2024-03-06 11:20 ` Nilay Shroff
2024-03-06 15:19 ` Keith Busch
2024-03-08 15:41 ` Keith Busch
2024-03-09 14:29 ` Nilay Shroff
2024-03-09 15:44 ` Keith Busch
2024-03-09 19:05 ` Nilay Shroff
2024-03-11 4:41 ` Keith Busch [this message]
2024-03-11 12:58 ` Nilay Shroff
2024-03-12 14:30 ` Keith Busch
2024-03-13 11:59 ` Nilay Shroff
2024-03-22 5:02 ` Nilay Shroff
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=Ze6LglWPqkHVFh-P@kbusch-mbp.mynextlight.net \
--to=kbusch@kernel.org \
--cc=axboe@fb.com \
--cc=gjoyce@linux.ibm.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
--cc=sagi@grimberg.me \
/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.