[PATCH] nvme: do not reset controllers in NVME_CTRL_NEW state

[Maurizio Lombardi]

On Sat Oct 3, 2026 at 1:55 PM CEST, Yureka Lilian wrote:
> On 9/15/26 11:58, Maurizio Lombardi wrote:
>> During NVMe controller creation, the controller is exposed to sysfs via
>> nvme_add_ctrl() while it is still in the NVME_CTRL_NEW state.
>> This creates a narrow race window where a userspace process can write to
>> the reset_controller sysfs node before the initialization thread
>> transitions the state to NVME_CTRL_CONNECTING.
>>
>> If a reset is triggered during this window, the state machine allows the
>> transition from NVME_CTRL_NEW to NVME_CTRL_RESETTING, and the reset work
>> is queued. However, the original creation thread continues its execution,
>> subsequently moving the state to NVME_CTRL_CONNECTING and finally to
>> NVME_CTRL_LIVE.
>>
>> When the delayed reset work finally executes, it attempts to tear down
>> the controller and transition the state to NVME_CTRL_CONNECTING. Because
>> the state is now NVME_CTRL_LIVE, this transition fails, triggering a
>> WARN_ON in the reset work.
>>
>> Fix this by removing NVME_CTRL_NEW from the allowed prior states for
>> the NVME_CTRL_RESETTING transition.
>>
>> Fixes: 8bfc3b4c6f9d ("nvmet: switch loopback target state to connecting when resetting")
>> Reported-by: syzbot+4a1d521d19d6321f5aad at syzkaller.appspotmail.com
>> Signed-off-by: Maurizio Lombardi <mlombard at redhat.com>
>> ---
>>   drivers/nvme/host/core.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
>> index beea23d04a70..7ea8dd27d08d 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -598,7 +598,6 @@ bool nvme_change_ctrl_state(struct nvme_ctrl *ctrl,
>>   		break;
>>   	case NVME_CTRL_RESETTING:
>>   		switch (old_state) {
>> -		case NVME_CTRL_NEW:
>>   		case NVME_CTRL_LIVE:
>>   			changed = true;
>>   			atomic_long_inc(&ctrl->nr_reset);
>
> Hi!
>
> I was testing something with linux-next 2026-10-02 and ran into an issue 
> with the
> nvme-apple driver where /dev/nvme0 exists but none of the namespaces appear,
> and the dmesg is awfully quiet about the nvme device. I bisected it down to
> this patch, which as far as I can tell leads to the nvme-apple being 
> stuck in
> NVME_CTRL_NEW state. Without being familiar with the matter, this looks like
> the nvme-apple driver was using this transition as part of its 
> initialization
> procedure.  If one of the NVMe people who know how these transitions are
> supposed to work could have a look, that would be much appreciated, as
> otherwise this will break nvme-apple in 7.3-rc6.
>
> Thanks,

Thanks for reporting this,
it seems that nvme-apple is the only driver that still initializes the
controller by performing a reset directly from a NEW state.

This should be easy to fix by moving the state to CONNECTING in
apple_nvme_probe, just before nvme_reset_ctrl() is called.

Would you be able to test the patch if I prepare it?

Maurizio