[PATCHv2 0/3] nvme fix handling for user changed module params

[PATCHv2 0/3] nvme fix handling for user changed module params

[Keith Busch]

From: Keith Busch <kbusch@kernel.org>

Changes from v1:

 * Added some code comments to explain why the queue count calculation
   needs to happen this way

 * Replaced the switch with more compact 'if' checks

 * Added reviews

Keith Busch (3):
  nvme-pci: ensure we're polling a polled queue
  nvme-pci: cap queue creation to used queues
  nvme-pci: do not try to add queue maps at runtime

 drivers/nvme/host/pci.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

-- 
2.47.3

[PATCHv2 1/3] nvme-pci: ensure we're polling a polled queue

[Keith Busch]

From: Keith Busch <kbusch@kernel.org>

A user can change the polled queue count at run time. There's a brief
window during a reset where a hipri task may try to poll that queue
before the block layer has updated the queue maps, which would race with
the now interrupt driven queue and may cause double completions.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
 drivers/nvme/host/pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c0f2104326ab4..4ee4d7ead5a92 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1627,7 +1627,8 @@ static int nvme_poll(struct blk_mq_hw_ctx *hctx, struct io_comp_batch *iob)
 	struct nvme_queue *nvmeq = hctx->driver_data;
 	bool found;
 
-	if (!nvme_cqe_pending(nvmeq))
+	if (!test_bit(NVMEQ_POLLED, &nvmeq->flags) ||
+	    !nvme_cqe_pending(nvmeq))
 		return 0;
 
 	spin_lock(&nvmeq->cq_poll_lock);
-- 
2.47.3

Re: [PATCHv2 1/3] nvme-pci: ensure we're polling a polled queue

[Kanchan Joshi]

Reviewed-by: Kanchan Joshi <joshi.k@samsung.com>

[PATCHv2 2/3] nvme-pci: cap queue creation to used queues

[Keith Busch]

From: Keith Busch <kbusch@kernel.org>

If the user reduces the special queue count at runtime and resets the
controller, we need to reduce the number of queues and interrupts
requested accordingly rather than start with the pre-allocated queue
count.

Tested-by: Kanchan Joshi <joshi.k@samsung.com>
Reviewed--by: Kanchan Joshi <joshi.k@samsung.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
 drivers/nvme/host/pci.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 4ee4d7ead5a92..c63efa49132f9 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2902,7 +2902,13 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
 	dev->nr_write_queues = write_queues;
 	dev->nr_poll_queues = poll_queues;
 
-	nr_io_queues = dev->nr_allocated_queues - 1;
+	/*
+	 * The initial number of allocated queue slots may be too large if the
+	 * user reduced the special queue parameters. Cap the value to the
+	 * number we need for this round.
+	 */
+	nr_io_queues = min(nvme_max_io_queues(dev),
+			   dev->nr_allocated_queues - 1);
 	result = nvme_set_queue_count(&dev->ctrl, &nr_io_queues);
 	if (result < 0)
 		return result;
-- 
2.47.3

Re: [PATCHv2 2/3] nvme-pci: cap queue creation to used queues

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCHv2 3/3] nvme-pci: do not try to add queue maps at runtime

[Keith Busch]

From: Keith Busch <kbusch@kernel.org>

The block layer allocates the set's maps once. We can't add special
purpose queues at runtime if they weren't allocated at initialization
time.

Signed-off-by: Keith Busch <kbusch@kernel.org>
---
 drivers/nvme/host/pci.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c63efa49132f9..0c1a8d7aa1c0b 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2902,6 +2902,18 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
 	dev->nr_write_queues = write_queues;
 	dev->nr_poll_queues = poll_queues;
 
+	if (dev->ctrl.tagset) {
+		/*
+		 * The set's maps are allocated only once at initialization
+		 * time. We can't add special queues later if their mq_map
+		 * wasn't preallocated.
+		 */
+		if (dev->ctrl.tagset->nr_maps < 3)
+			dev->nr_poll_queues = 0;
+		if (dev->ctrl.tagset->nr_maps < 2)
+			dev->nr_write_queues = 0;
+	}
+
 	/*
 	 * The initial number of allocated queue slots may be too large if the
 	 * user reduced the special queue parameters. Cap the value to the
-- 
2.47.3

Re: [PATCHv2 3/3] nvme-pci: do not try to add queue maps at runtime

[Christoph Hellwig]

On Thu, Feb 12, 2026 at 08:47:33AM -0800, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
> 
> The block layer allocates the set's maps once. We can't add special
> purpose queues at runtime if they weren't allocated at initialization
> time.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCHv2 3/3] nvme-pci: do not try to add queue maps at runtime

[Kanchan Joshi]

On 2/12/2026 10:17 PM, Keith Busch wrote:
> From: Keith Busch<kbusch@kernel.org>
> 
> The block layer allocates the set's maps once. We can't add special
> purpose queues at runtime if they weren't allocated at initialization
> time.

Reviewed-by: Kanchan Joshi <joshi.k@samsung.com>

User may not get an error on adding and, therefore, may feel that 
everything went fine, but such queues cannot be used.
At least, that was my observation on increasing the number of poll 
queues from 0 to !0 value.
I continued getting "not supported" error on issuing hipri I/O from 
io_uring. After this patch, the poll queue became usable.

Tested-by: Kanchan Joshi <joshi.k@samsung.com>

Re: [PATCHv2 3/3] nvme-pci: do not try to add queue maps at runtime

[Keith Busch]

On Fri, Feb 13, 2026 at 04:05:47PM +0530, Kanchan Joshi wrote:
> User may not get an error on adding and, therefore, may feel that 
> everything went fine, but such queues cannot be used.
> At least, that was my observation on increasing the number of poll 
> queues from 0 to !0 value.
> I continued getting "not supported" error on issuing hipri I/O from 
> io_uring. After this patch, the poll queue became usable.

Thanks for confirming! Series applied to nvme-7.0.

Considering how broken modifying the counts at runtime was, I wonder was
it worth fixing? Clearly no one tried to use this feature. Maybe I
should have just changed the parameter permissions to 0444? But hey, it
wasn't a big deal to fix, so it's safe to use now!