public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Hannes Reinecke <hare@suse.de>, Daniel Wagner <dwagner@suse.de>,
	Daniel Wagner <wagi@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	James Smart <james.smart@broadcom.com>,
	Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] nvme: only allow entering LIVE from CONNECTING state
Date: Tue, 29 Apr 2025 11:42:25 -0700	[thread overview]
Message-ID: <aBEdkUky_-bfgISv@kbusch-mbp> (raw)
In-Reply-To: <253e0551-d4d7-4ffe-8842-daecf1f6c753@roeck-us.net>

On Tue, Apr 29, 2025 at 11:23:25AM -0700, Guenter Roeck wrote:
> On 4/29/25 11:13, Keith Busch wrote:
> > On Mon, Apr 28, 2025 at 03:21:18PM +0200, Hannes Reinecke wrote:
> > > > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > > > index b502ac07483b..d3c4eacf607f 100644
> > > > --- a/drivers/nvme/host/core.c
> > > > +++ b/drivers/nvme/host/core.c
> > > > @@ -4493,7 +4493,8 @@ static void nvme_fw_act_work(struct work_struct *work)
> > > >                   msleep(100);
> > > >           }
> > > > 
> > > > -       if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_LIVE))
> > > > +       if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_CONNECTING) ||
> > > > +           !nvme_change_ctrl_state(ctrl, NVME_CTRL_LIVE))
> > > >                   return;
> > > > 
> > > >           nvme_unquiesce_io_queues(ctrl);
> > > 
> > > I would rather have a separate state for firmware activation.
> > > (Ab-)using the 'RESETTING' state here has direct implications
> > > with the error handler, as for the error handler 'RESETTING'
> > > means that the error handler has been scheduled.
> > > Which is not true for firmware activation.
> > 
> > But the point of having firmware activation set the state to RESETTING
> > was to fence off error handling from trying to schedule a real reset.
> > The fw activation work schedules its own recovery if it times out, but
> > we don't want any other recovery action or user requested resets to
> > proceed while an activation is still pending.
> 
> Not only that; there are various checks against NVME_CTRL_RESETTING
> sprinkled through the code. What is the impact of introducing a new state
> without handling all those checks ?

Good point, bad things will happen if these checks are not updated to
know about the new state. For example, nvme-pci will attempt aborting IO
or disabling the controller on a timeout instead of restarting the timer
as desired.

Can we just revert the commit that prevented the RESETTING -> LIVE
transtion for now?


  reply	other threads:[~2025-04-29 18:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-14  8:02 [PATCH 0/2] nvme-fc: fix schedule in atomic context Daniel Wagner
2025-02-14  8:02 ` [PATCH 1/2] nvme: only allow entering LIVE from CONNECTING state Daniel Wagner
2025-02-20 10:34   ` Sagi Grimberg
2025-04-27 15:59   ` Guenter Roeck
2025-04-28 12:44     ` Daniel Wagner
2025-04-28 13:21       ` Hannes Reinecke
2025-04-29 13:55         ` Daniel Wagner
2025-04-29 17:54           ` Hannes Reinecke
2025-04-29 18:13         ` Keith Busch
2025-04-29 18:23           ` Guenter Roeck
2025-04-29 18:42             ` Keith Busch [this message]
2025-04-30  6:43               ` Daniel Wagner
2025-04-30 16:01                 ` Keith Busch
2025-04-30 16:12                   ` Guenter Roeck
2025-05-02  9:02                     ` Daniel Wagner
2025-04-30 16:11                 ` Guenter Roeck
2025-04-30  6:08           ` Hannes Reinecke
2026-01-09 19:18   ` John Meneghini
2026-01-11  9:33     ` Nilay Shroff
2026-01-12  8:14       ` Daniel Wagner
2026-01-13  6:10         ` Nilay Shroff
2026-01-13 13:55           ` John Meneghini
2025-02-14  8:02 ` [PATCH 2/2] nvme-fc: rely on state transitions to handle connectivity loss Daniel Wagner
2025-02-20 10:36   ` Sagi Grimberg
2025-02-20  8:00 ` [PATCH 0/2] nvme-fc: fix schedule in atomic context Daniel Wagner
2025-02-20 12:50 ` Shinichiro Kawasaki
2025-02-20 17:23 ` Keith Busch

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=aBEdkUky_-bfgISv@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=dwagner@suse.de \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=james.smart@broadcom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux@roeck-us.net \
    --cc=sagi@grimberg.me \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=wagi@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox