[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jun 2022 08:51:02 +0200
From: "hch@....de" <hch@....de>
To: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
Cc: Keith Busch <kbusch@...nel.org>, "axboe@...com" <axboe@...com>,
"hch@....de" <hch@....de>, "sagi@...mberg.me" <sagi@...mberg.me>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Caroline Subramoney <Caroline.Subramoney@...rosoft.com>,
Richard Wurdack <riwurd@...rosoft.com>,
Nathan Obr <Nathan.Obr@...rosoft.com>
Subject: Re: [PATCH v2 2/2] nvme: handle persistent internal error AER from
NVMe controller
On Sat, Jun 04, 2022 at 02:28:11PM +0000, Michael Kelley (LINUX) wrote:
> > driver's irq handler. The other transports block on register reads, though, so
> > they can't call this from an atomic context. The TCP context looks safe, but
> > I'm not sure about RDMA or FC.
>
> Good point. But even if the RDMA and FC contexts are safe,
For RDMA this is typically called from softirq context, so it is indeed
not save.
> if a
> persistent error is reported, the controller is already in trouble and
> may not respond to a request to retrieve the CSTS anyway. Perhaps
> we should just trust the AER error report and not bother checking
> CSTS to decide whether to do the reset. We can still check ctrl->state
> and skip the reset if there's already one in progress.
Yes, that might be a better option.
Powered by blists - more mailing lists