[PATCH] nvme: Revert: Fix controller creation races with teardown flow

[Sagi Grimberg]

> The indicated patch introduced a barrier in the sysfs_delete attribute
> for the controller that rejects the request if the controller isn't
> created. "Created" is defined as at least 1 call to nvme_start_ctrl().
> 
> This is problematic in error-injection testing.  If an error occurs on
> the initial attempt to create an association and the controller enters
> reconnect(s) attempts, the admin cannot delete the controller until
> either there is a successful association created or ctrl_loss_tmo
> times out.
> 
> Where this issue is particularly hurtful is when the "admin" is the
> nvme-cli, it is performing a connection to a discovery controller, and
> it is initiated via auto-connect scripts.  With the FC transport, if the
> first connection attempt fails, the controller enters a normal reconnect
> state but returns control to the cli thread that created the controller.
> In this scenario, the cli attempts to read the discovery log via ioctl,
> which fails, causing the cli to see it as an empty log and then proceeds
> to delete the discovery controller. The delete is rejected and the
> controller is left live. If the discovery controller reconnect then
> succeeds, there is no action to delete it, and it sits live doing nothing.

This is indeed a regression.

Perhaps we should also revert:
12a0b6622107 ("nvme: don't hold nvmf_transports_rwsem for more than 
transport lookups")

Which inherently caused this by removing the serialization of
.create_ctrl()...