[PATCH v2] nvme: recompute multipath zoned limits from ready paths

[Yao Sang]

On Fri, May 22, 2026 at 11:21:36AM +0200, Christoph Hellwig wrote:
> On Fri, May 22, 2026 at 03:58:06PM +0800, Yao Sang wrote:
> > This was found while debugging a zoned NVMe multipath setup, where the
> > namespace head reported 0/0 for max_open_zones and max_active_zones
> > while the live path still reported finite limits.
> 
> How?  Having the different path report different limits is bogus.
> I guess we just need to fix it and reject a device with mismatching
> parameters.
Hi Christoph,

Thanks for looking at this.

Sorry, the changelog was imprecise.

What I saw was not different live paths of the same namespace
reporting different zoned limits. On a QEMU VM with native NVMe
multipath enabled, two emulated NVMe controllers shared the same ZNS
namespace and advertised CMIC.MULTI_CTRL, so the kernel created a
multipath namespace head. In that setup, both controller paths
reported max_open_zones=16 and max_active_zones=16, while the
multipath namespace head for the same namespace reported 0/0.

I also checked Identify Namespace data through both controllers. In
both cases, nvme zns id-ns reported mor=15 and mar=15, so I did not
observe any path-to-path MOR/MAR mismatch. The mismatch was between
the namespace head and the controller paths.

So the issue here is not inconsistent zoned limits across paths. It
is that the namespace head can still show bogus 0/0 even when
multiple live paths report the same 16/16 limits.

After the patch, I reran nvme/005, nvme/057, and nvme/058, and
rechecked the head and path limits after reset, ANA failover/failback,
and namespace remap. In all cases, head and path stayed at 16/16.

If you prefer, I can respin this with changelog text that states only
that observed head/path mismatch.

Thanks,
Yao