[PATCH 12/17] nvme-fabrics: reset connection for secure concatenation

[Hannes Reinecke]

On 4/7/24 23:46, Sagi Grimberg wrote:
> 
> 
> On 18/03/2024 17:03, Hannes Reinecke wrote:
>> When secure concatenation is requested the connection needs to be
>> reset to enable TLS encryption on the new cnnection.
>> That implies that the original connection used for the DH-CHAP
>> negotiation really shouldn't be used, and we should reset as soon
>> as the DH-CHAP negotiation has succeeded on the admin queue.
>> The current implementation does not allow to easily skip
>> connection attempts on the I/O queues, so we connect I/O
>> queues, but disable namespace scanning on these queues.
>> With that no I/O can be issued on these queues, so we
>> can tear them down quickly without having to wait for
>> quiescing etc.
> 
> We shouldn't have to connect io queues here. The scan prevention
> is just a hack...
> 
Oh, believe me, I tried. What _should_ be possible is to create a
controller with just admin queues, and skip the io queue setup part.
But once you do that it's impossible to create io queues after reset
(which is what you'd need here).
I tried to fix this, but that ended up with a massive rewrite/reordering
of the init path. Which sure has its merits, but I deemed out of scope
for this patchset.

So I decided for this 'hack', and shelved the init path reorg for a
later patchset.

>> Once that is done we can reset the controller directly
>> after the ->create_ctrl() callback.
> 
> Why not set opts->nr_io_queues = 0 for secure concatenation and
> setting it to the original value before resetting?

See above. The io tagset is allocated in the init path _only_.
And creating of the io tagset is tied with connecting the io queues.
The reset code requires the tagset to be present; it just reconnects
the io queues.
So either you do some trickery here like skipping connecting io queues
(or, indeed, skipping namespace scanning),
or you end up with a massive reshuffling of the init code path trying
to separate tagset creation from io queue connections.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare at suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich