[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAC5umyjsC_ECC4c_fS5QhVY1JgfSLx6ecEPVua=0j=K+JaiFpQ@mail.gmail.com>
Date: Thu, 9 May 2019 01:02:21 +0900
From: Akinobu Mita <akinobu.mita@...il.com>
To: minwoo.im@...sung.com
Cc: Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...com>,
Sagi Grimberg <sagi@...mberg.me>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
Keith Busch <keith.busch@...el.com>,
Minwoo Im <minwoo.im.dev@...il.com>,
Johannes Berg <johannes@...solutions.net>,
Christoph Hellwig <hch@....de>
Subject: Re: [PATCH v2 6/7] nvme-pci: add device coredump support
2019年5月8日(水) 9:25 Minwoo Im <minwoo.im@...sung.com>:
>
> > This is a bit of a mine field. The shutdown_lock is held when reclaiming
> > requests that didn't see a response. If you're holding it here and your
> > telemetry log page times out, we're going to deadlock. And since the
> > controller is probably in a buggered state when you try to retrieve one,
> > I would guess an unrecoverable timeout is the most likely outcome.
>
> Akinobu,
>
> I actually agree with Keith's one. In my experience, there was always internal
> error inside device when timeout occurs in nvme driver which means the
> following command might not be completed due to lack of response from
> device.
The nvme_coredump() is .coredump() callback of device_driver which is
called when anything is written to the /sys/devices/.../coredump.
Providing this callback is optional, but simply removing this manual
device coredump method is a bit inconvenient.
So instead of directly retrieving the snapshot with the shutdown_lock held
in this callback, I'll change this to just scheduling the reset work, and
the actual device coredump will be triggered by the same procedure that is
implemented in the patch 7/7. Therefore telemetry log is retrieved only
when the controller is successfully recovered from the crash.
Powered by blists - more mailing lists