[PATCH 05/19] nvmet: accept I/O queues on the controller's port only

[Christoph Hellwig]

On Thu, Oct 29, 2026 at 08:52:38AM -0700, Keith Busch wrote:
> From: Josef Bacik <josef at toxicpanda.com>
> 
> nvmet_ctrl_find_get() looks the subsystem up through the port of the
> request, but then takes the controller from the subsystem list whatever
> port it was created on. A controller belongs to one port and one
> transport: ctrl->ops is that of the admin queue, and both
> ->install_queue() and ->delete_ctrl() assume the queues are their own.
> So an I/O queue arriving on another port of the same subsystem, possibly
> on another transport, is installed into a controller it has no part in,
> nvmet_tcp_install_queue() writes to it as a TCP queue, and an error on
> it deletes that controller. The Connect comes before any authentication.
> 
> Skip controllers of other ports, and compare the transport too since a
> port's transport can be changed while it's disabled.
> 
> Fixes: a07b4970f464 ("nvmet: add a generic NVMe target")
> Cc: Christoph Hellwig <hch at lst.de>
> Cc: Sagi Grimberg <sagi at grimberg.me>
> Cc: Chaitanya Kulkarni <kch at nvidia.com>
> Reviewed-by: Hannes Reinecke <hare at kernel.org>
> Signed-off-by: Josef Bacik <josef at toxicpanda.com>
> Signed-off-by: Jens Axboe <axboe at kernel.dk>
> Signed-off-by: Keith Busch <kbusch at kernel.org>
> ---
>  drivers/nvme/target/core.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
> index a8171b88035c5..27b27c83ff831 100644
> --- a/drivers/nvme/target/core.c
> +++ b/drivers/nvme/target/core.c
> @@ -1512,6 +1512,11 @@ struct nvmet_ctrl *nvmet_ctrl_find_get(const char *subsysnqn,
>  				pr_warn("hostnqn mismatch.\n");
>  				continue;
>  			}
> +			/* All queues of a controller come in by its port. */

This comment is vert confusing.  I'd drop it.

> +			if (ctrl->port != req->port || ctrl->ops != req->ops) {
> +				pr_warn("port mismatch.\n");
> +				continue;
> +			}

And I don't think this warning is very useful (same for the hostnqn one
above that looks like an accidental debug printk).