From: Yaohan Li <shunsheng1218@gmail.com>
To: hare@suse.de, kbusch@kernel.org, axboe@kernel.dk, hch@lst.de,
sagi@grimberg.me
Cc: mkp@kernel.org, linux-nvme@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme: stop asynchronous event work before ANA teardown
Date: Thu, 12 Nov 2026 09:56:38 +0800 [thread overview]
Message-ID: <20261112020000.1003.yaohan@gmail.com> (raw)
In-Reply-To: <508595ec-0540-4534-afd4-44ef8ee01da6@suse.de>
Hi Hannes,
That's a fair point. I agree that we shouldn't submit new AER requests once teardown has started.
The case I was trying to cover is a completion for an AER that was already outstanding. nvme_stop_ctrl() flushes async_event_work, but a completion can still queue it again before the transport has finished shutting down the admin queue.
In v2, I added the final cancellation in nvme_uninit_ctrl(), after the transport teardown, and kept the separate cancellation of ana_work before releasing its resources. Keith has since applied that version to nvme-7.4.
I agree that stopping the producer is preferable where possible. I don't think the final cancellation should be treated as a substitute for quiescing the completion path, and I'll check whether any transport can still deliver a callback beyond that point.
Thanks,
Yaohan
next prev parent reply other threads:[~2026-11-12 1:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 9:51 [PATCH] nvme: stop asynchronous event work before ANA teardown Yaohan Li
2026-11-04 10:10 ` sashiko-bot
2026-11-05 7:55 ` Christoph Hellwig
2026-11-10 12:55 ` Hannes Reinecke
2026-11-12 1:56 ` Yaohan Li [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-11-05 11:41 [PATCH v2] " Yaohan Li
2026-11-06 10:29 ` Christoph Hellwig
2026-11-06 16:41 ` 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=20261112020000.1003.yaohan@gmail.com \
--to=shunsheng1218@gmail.com \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mkp@kernel.org \
--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.