[PATCH AUTOSEL 7.0-5.10] nvme: add missing MODULE_ALIAS for fabrics transports

[Sasha Levin <sashal@kernel.org>]

From: Geliang Tang <tanggeliang@kylinos.cn>

[ Upstream commit 723277b15ed97185ce6f75abbf19f06e00f0a6f5 ]

The generic fabrics layer uses request_module("nvme-%s", opts->transport)
to auto-load transport modules. Currently, the nvme-tcp, nvme-rdma, and
nvme-fc modules lack MODULE_ALIAS entries for these names, which prevents
the kernel from automatically finding and loading them when requested.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
Phase 1 Record: subsystem `nvme` / NVMe host fabrics; action verb `add
missing`; intent is to add module aliases for existing fabrics
transports. Tags: `Reviewed-by: Christoph Hellwig <hch@lst.de>`,
`Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>`, `Signed-off-by:
Keith Busch <kbusch@kernel.org>`. No `Fixes:`, `Reported-by:`, `Tested-
by:`, `Link:`, or `Cc: stable`. Body describes a real autoload bug:
`fabrics.c` calls `request_module("nvme-%s", opts->transport)`, but the
transport modules do not advertise aliases matching `nvme-tcp`, `nvme-
rdma`, or `nvme-fc`. This is a hidden bug fix despite using “add”.

Phase 2 Record: files changed are `drivers/nvme/host/fc.c` `+1`,
`drivers/nvme/host/rdma.c` `+1`, `drivers/nvme/host/tcp.c` `+1`; no
functions changed, only module metadata at EOF. Before: modules had
license/description metadata but no matching alias. After: each existing
module exports the alias that the existing autoload path requests. Bug
category is logic/module-autoload correctness. Fix quality is excellent:
three literal aliases, each matching the existing transport name and
module filename; regression risk is very low.

Phase 3 Record: `request_module("nvme-%s", opts->transport)` was
introduced by `d1f1071f81513` (`nvme-fabrics: request transport
module`), first in `v4.15`. RDMA host came in `7110230719602` (`v4.8`),
FC in `e399441de9115` (`v4.10`), TCP in `3f2304f8c6d6` (`v5.0`). No
`Fixes:` tag to follow. Recent file history shows normal NVMe churn, not
a prerequisite series. The author has prior NVMe host commits, and the
patch was reviewed/committed by listed NVMe maintainers. No dependency
beyond the existing files and `MODULE_ALIAS`.

Phase 4 Record: `b4 dig -c 723277b15ed97` found the original patch at `h
ttps://patch.msgid.link/e3076c80ee2e0c4a2cae0374afb617a3365946ea.1774944
415.git.tanggeliang@kylinos.cn`. `b4 dig -a` found only v1. `b4 dig -w`
showed NVMe maintainers and `linux-nvme` were included. Lore mirror
shows Christoph Hellwig replied “Looks good” with `Reviewed-by`, and
Keith Busch replied “applied to nvme-7.1”. No NAKs, no stable
nomination, and no separate bug report link found.

Phase 5 Record: modified “functions” are module metadata only. The
affected call path is verified as `nvmf_dev_write()` ->
`nvmf_create_ctrl()` -> `request_module("nvme-%s", opts->transport)` ->
`nvmf_lookup_transport()` -> transport `create_ctrl`. Transport
registration uses `.name = "fc"`, `.name = "rdma"`, `.name = "tcp"` and
module objects are `nvme-fc.o`, `nvme-rdma.o`, `nvme-tcp.o`, so the
alias strings exactly match the requested names. This path is reachable
from userspace via the `nvme-fabrics` misc device write path; I did not
verify whether unprivileged users can trigger it.

Phase 6 Record: stable refs checked. `stable/linux-4.19.y` has the
autoload request and FC/RDMA files, but no TCP file.
`stable/linux-5.4.y` through `stable/linux-7.0.y` have the autoload
request and all three transport files. None of those checked stable refs
had the `MODULE_ALIAS("nvme-*")` entries. The patch applies cleanly to
current `stable/linux-7.0.y`; `5.4` through `6.6` lack the newer
`MODULE_DESCRIPTION` context, so they need a trivial backport placing
aliases after `MODULE_LICENSE`. `4.14.y` lacks the verified autoload
request and has no TCP file, so benefit there is not established.

Phase 7 Record: subsystem is NVMe host fabrics under storage/block;
criticality is IMPORTANT because it affects NVMe-oF connectivity for
users of these transports. The subsystem is active, with recent NVMe
host changes verified in history.

Phase 8 Record: affected users are NVMe-oF users with FC/RDMA/TCP
transports built as modules and not already loaded. Trigger is creating
a fabrics controller for one of those transports while relying on kernel
module autoload. Failure mode is not a crash: `nvmf_lookup_transport()`
fails, logs `no handler found for transport %s`, and returns `-EINVAL`,
preventing the connection. Severity is MEDIUM user-visible functional
failure for storage connectivity. Benefit is high for affected
configurations; risk is very low because it only adds module alias
metadata for existing modules.

Phase 9 Record: evidence for backporting: real autoload bug, existing
request path, exact alias/name/module matches, important storage
subsystem, very small patch, maintainer review, no API or new feature.
Evidence against: no crash/security/data-corruption impact, no explicit
stable tag, no explicit Tested-by, and older stable trees need minor
context adjustment. Stable rules: obviously correct yes; tested tag no
but maintainer-reviewed; fixes a real user-visible bug yes; important
enough for affected NVMe-oF users yes; small and contained yes; no new
feature/API yes; can apply cleanly to `7.0.y` and trivially to older
applicable trees. Exception category: closest to module/device autoload
enablement for existing drivers, not a new driver.

## Verification
- Phase 1: inspected upstream commit `723277b15ed97`; verified subject,
  body, tags, and absence of `Fixes:`/`Reported-by:`/stable tags.
- Phase 2: inspected diff; verified exactly three added `MODULE_ALIAS`
  lines.
- Phase 3: used blame/log/tag checks; verified autoload request
  introduced in `v4.15`, RDMA in `v4.8`, FC in `v4.10`, TCP in `v5.0`.
- Phase 4: ran `b4 dig -c`, `-a`, `-w`; fetched lore mirror; verified
  v1-only patch, maintainer review, maintainer application, no NAKs.
- Phase 5: read `fabrics.c`, `Makefile`, `Kconfig`, and transport ops;
  verified call path, transport names, and module names.
- Phase 6: checked stable refs `4.14.y`, `4.19.y`, `5.4.y`, `5.10.y`,
  `5.15.y`, `6.1.y`, `6.6.y`, `6.12.y`, `6.19.y`, `7.0.y`; verified
  applicable code and missing aliases; `git apply --check` passed on
  current `7.0.y`. One intermediate shell formatting command failed due
  to a bad `sed` expression; I reran the stable metadata check correctly
  afterward.
- Phase 8: verified the failure path returns `-EINVAL` after
  `nvmf_lookup_transport()` fails; privilege requirements were not
  verified.

This should be backported to applicable stable trees. It fixes an
existing intended autoload mechanism for existing NVMe fabrics
transports with a tiny, low-risk metadata-only change.

**YES**

 drivers/nvme/host/fc.c   | 1 +
 drivers/nvme/host/rdma.c | 1 +
 drivers/nvme/host/tcp.c  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index e1bb4707183ca..e4f4528fe2a2d 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -3968,3 +3968,4 @@ module_exit(nvme_fc_exit_module);
 
 MODULE_DESCRIPTION("NVMe host FC transport driver");
 MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("nvme-fc");
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 57111139e84fa..1ec6e867aedb6 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -2432,3 +2432,4 @@ module_exit(nvme_rdma_cleanup_module);
 
 MODULE_DESCRIPTION("NVMe host RDMA transport driver");
 MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("nvme-rdma");
diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index 243dab830dc84..02c95c32b07e3 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -3071,3 +3071,4 @@ module_exit(nvme_tcp_cleanup_module);
 
 MODULE_DESCRIPTION("NVMe host TCP transport driver");
 MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("nvme-tcp");
-- 
2.53.0