Re: [PATCH v1 2/2] nvme: stop using queue_limits_stack_bdev for namespace heads

[Christoph Hellwig <hch@lst.de>]

On Mon, Jul 20, 2026 at 10:22:05AM +0800, Yao Sang wrote:
> NVMe namespace heads are not generic stacked block devices.

Not many things actually are, which leads to every recurring problems
with the stacking scheme..

> Execution features and request limits continue to accumulate
> conservatively as paths are refreshed.

What is this supposed to mean?

> Keep the helper local to NVMe so its field ownership remains explicit and

What is "field ownership" supposed to mean?

> does not impose NVMe namespace-head policy on mapped devices.

I think you need to clearly state in what way we'll want to diverge
here.

> +static void nvme_apply_ns_head_identify_limits(struct queue_limits *lim,
> +					       const struct queue_limits *ns_lim)

Two tab indents, please.

>  {
> -	t->max_open_zones = min_not_zero(t->max_open_zones, b->max_open_zones);
> -	t->max_active_zones =
> -		min_not_zero(t->max_active_zones, b->max_active_zones);
> +	/*
> +	 * Identify-derived namespace/head attributes come from the refreshed
> +	 * NVMe namespace limits, not from generic mapped-device stacking.
> +	 */
> +	lim->features &= ~(BLK_FEAT_ZONED | BLK_FEAT_ATOMIC_WRITES);
> +	lim->features |= ns_lim->features & BLK_FEAT_ZONED;
> +	lim->logical_block_size = ns_lim->logical_block_size;
> +	lim->physical_block_size = ns_lim->physical_block_size;

A lot of this still duplicates the core code and creates a nightmare
when we add new fields.

Can you try to refactor the core code into lower level building
blocks and reuse as much as possible while also making the policy
differences clear?