[PATCH 3/4] nvmet: prevent max_qid changes for discovered subsystems

[Daniel Wagner]

On Thu, Sep 25, 2025 at 11:28:04AM +0300, Max Gurtovoy wrote:
> The above mentioned commit 555f66d0f8a3 ("nvme-fc: update hardware queues
> before using them") was added to Linux-v5.15.
> 
> The qid_max support was added to Linux-v6.1 commit 3e980f5995e0 ("nvmet:
> expose max queues to configfs").
> 
> IMO the real objective of adding qid_max support is to make the subsystem
> more configurable and not for testing reconnect attempts of the host, as was
> mentioned in the commit message.

The nvmet change took a bit longer to get added. My main objective when
I wrote this ode was to test the reconnect attempt.

> This re-connect scenario can be easily tested in a different manner, and the
> target driver code is not there for testing the host driver unique
> scenarios. At least it is not its main goal.

As I said, I don't mind to change/adapt the test infrastructure, but not
the test case. FWIW, it found more than the above bug over time.

> I don't know how the driver will handle it but for sure this is a situation
> we would like to avoid.

No objection.

> I guess we can try fixing this problem in other ways, but why should we
> complicate the code so much ? let's try to avoid this scenario to happen and
> simplify the code where we can...

Sure. Maybe the failover tests should setup two controllers instead a
single one. But not sure if this is supported at all from nvmet or
blktests perspective.