From: Mohamed Khalfella <mkhalfella@purestorage.com>
To: zhang san <shunsheng1218@gmail.com>
Cc: kbusch@kernel.org, axboe@fb.com, hch@lst.de, sagi@grimberg.me,
linux-nvme@lists.infradead.org
Subject: Re: Question: NVMe AER completion delivery during controller removal
Date: Mon, 9 Nov 2026 11:08:54 -0800 [thread overview]
Message-ID: <20261109190854.GA765534-mkhalfella@purestorage.com> (raw)
In-Reply-To: <CAGTEBTa9dGn8TjKxRPsfeCFiRYAt-cGMAp-XSLBS86SHB6FJ_A@mail.gmail.com>
On Wed 2026-11-04 12:50:42 +0800, zhang san wrote:
> Hello,
>
> We are seeking clarification about asynchronous event request (AER)
> completion behavior during NVMe controller removal, before treating an
> observed test failure as a production-reachable driver bug.
>
> Our source analysis suggests a possible lifetime race between the AEN
> completion path, which can requeue nvme_async_event_work, and the
> controller removal path. We observed KASAN use-after-free in an
> emulated environment on Linux v7.4-rc1 (6628e7d4c6b2).
My reading of the code suggests this can happen. nvme_stop_ctrl()
flushes async_event_work, but the admin queue can still deliver an AER
completion afterwards, either from the admin queue interrupt handler or
from the final admin CQ poll in nvme_dev_disable():
nvme_remove() ->
nvme_dev_disable() ->
nvme_poll_irqdisable(&dev->queues[0]) ->
nvme_poll_cq() ->
nvme_handle_cqe() ->
nvme_complete_async_event() ->
queue_work(nvme_wq, &ctrl->async_event_work);
Nothing flushes async_event_work after that, so the work can run after
nvme_uninit_ctrl() drops the last reference and the nvme_dev is freed.
>
> However, our test induced an ERROR AEN through an out-of-specification
> MMIO doorbell write while the device was being removed. This
> deliberately synthetic trigger does not establish that a compliant
> controller would generate the same completion.
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -3909,20 +3909,21 @@ static void nvme_remove(struct pci_dev *pdev)
if (!pci_device_is_present(pdev)) {
nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DEAD);
nvme_dev_disable(dev, true);
}
flush_work(&dev->ctrl.reset_work);
nvme_stop_ctrl(&dev->ctrl);
nvme_remove_namespaces(&dev->ctrl);
nvme_dev_disable(dev, true);
+ flush_work(&dev->ctrl.async_event_work);
nvme_free_host_mem(dev);
nvme_dev_remove_admin(dev);
nvme_dbbuf_dma_free(dev);
nvme_free_queues(dev, 0);
mempool_destroy(dev->dmavec_mempool);
nvme_release_descriptor_pools(dev);
nvme_dev_unmap(dev);
nvme_uninit_ctrl(&dev->ctrl);
}
Since you are able to reproduce this issue reliabely, how about you try
the diff above and see if it fixes the issue.
>
> Our main question is: can a specification-compliant controller deliver
> a completion for a previously submitted AER during the interval in
> which the host is disabling the controller and tearing down the admin
> queue, or must such completions be quiesced before disable completes?
> We would also welcome guidance on the exact point after which the host
> may safely assume that no further AER completions can be delivered.
If the above diff fixes the issue for you, then I think this is a driver
bug.
next prev parent reply other threads:[~2026-11-09 19:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 4:50 Question: NVMe AER completion delivery during controller removal zhang san
2026-11-09 19:08 ` Mohamed Khalfella [this message]
2026-11-09 19:32 ` Mohamed Khalfella
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=20261109190854.GA765534-mkhalfella@purestorage.com \
--to=mkhalfella@purestorage.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=shunsheng1218@gmail.com \
/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.