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

[Max Gurtovoy]

On 25/09/2025 14:32, Daniel Wagner wrote:
> 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.

Sure, test case can stay.

for example one can:

1. create a port/subsystem with max_qid = 20
2. connect from a host
3. destroy the subsystem/port (this will issue a 
reconnect/error_recovery flow from host)
4. create the same port/subsystem with max_qid = 10
5. reconnect attempt X will succeed and new host controller will have 10 
IO queues - tagset should be updated as it does today.

WDYT ?

>
>> 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.