Re: [PATCH] nvme: Add support for ACRE Command Interrupted status

Re: [PATCH] nvme: Add support for ACRE Command Interrupted status

[Keith Busch]

[cc'ing linux-block, Jens]

On Tue, Nov 26, 2019 at 02:36:50PM +0100, Hannes Reinecke wrote:
> This patch fixes a bug in nvme_complete_rq logic introduced by
> Enhanced Command Retry code. According to TP-4033 the controller
> only sets CDR when the Command Interrupted status is returned.
> The current code interprets Command Interrupted status as a
> BLK_STS_IOERR, which results in a controller reset if
> REQ_NVME_MPATH is set.

I see that Command Interrupted status requires ACRE enabled, but I don't
see the TP saying that the CQE CRD fields are used only with that status
code. I'm pretty sure I've seen it used for Namespace Not Ready status
as well. That would also fail MPATH for the same reason as this new
status...

> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 108f60b46804..752a40daf2b3 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -201,6 +201,8 @@ static blk_status_t nvme_error_status(u16 status)
>  	switch (status & 0x7ff) {
>  	case NVME_SC_SUCCESS:
>  		return BLK_STS_OK;
> +	case NVME_SC_COMMAND_INTERRUPTED:
> +		return BLK_STS_RESOURCE;
>  	case NVME_SC_CAP_EXCEEDED:
>  		return BLK_STS_NOSPC;
>  	case NVME_SC_LBA_RANGE:
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index d688b96d1d63..3a0d84528325 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -84,6 +84,7 @@ static inline bool blk_path_error(blk_status_t error)
>  	case BLK_STS_NEXUS:
>  	case BLK_STS_MEDIUM:
>  	case BLK_STS_PROTECTION:
> +	case BLK_STS_RESOURCE:
>  		return false;
>  	}

I agree we need to make this status a non-path error, but we at least
need an Ack from Jens or have this patch go through linux-block if we're
changing BLK_STS_RESOURCE to mean a non-path error.

> diff --git a/include/linux/nvme.h b/include/linux/nvme.h
> index f61d6906e59d..6b21f3888cad 100644
> --- a/include/linux/nvme.h
> +++ b/include/linux/nvme.h
> @@ -1292,6 +1292,8 @@ enum {
>  
>  	NVME_SC_NS_WRITE_PROTECTED	= 0x20,
>  
> +	NVME_SC_COMMAND_INTERRUPTED	= 0x21,

This command status was actually already defined in commit
48c9e85b23464, though with a slightly different name.

Re: [PATCH] nvme: Add support for ACRE Command Interrupted status

[Christoph Hellwig]

On Wed, Nov 27, 2019 at 01:05:46AM +0900, Keith Busch wrote:
> > +++ b/include/linux/blk_types.h
> > @@ -84,6 +84,7 @@ static inline bool blk_path_error(blk_status_t error)
> >  	case BLK_STS_NEXUS:
> >  	case BLK_STS_MEDIUM:
> >  	case BLK_STS_PROTECTION:
> > +	case BLK_STS_RESOURCE:
> >  		return false;
> >  	}
> 
> I agree we need to make this status a non-path error, but we at least
> need an Ack from Jens or have this patch go through linux-block if we're
> changing BLK_STS_RESOURCE to mean a non-path error.

most resource errors are per-path, so blindly changing this is wrong.

That's why I really just wanted to decode the nvme status codes inside
nvme instead of going through a block layer mapping, as that is just
bound to lose some information.

Re: [PATCH] nvme: Add support for ACRE Command Interrupted status

[Meneghini, John]

On 11/26/19, 11:24 AM, "Christoph Hellwig" <hch@lst.de> wrote:

    On Wed, Nov 27, 2019 at 01:05:46AM +0900, Keith Busch wrote:
    > > +++ b/include/linux/blk_types.h
    > > @@ -84,6 +84,7 @@ static inline bool blk_path_error(blk_status_t error)
    > >     case BLK_STS_NEXUS:
    > >     case BLK_STS_MEDIUM:
    > >     case BLK_STS_PROTECTION:
    > > +   case BLK_STS_RESOURCE:
    > >             return false;
    > >     }
    >
    > I agree we need to make this status a non-path error, but we at least
    > need an Ack from Jens or have this patch go through linux-block if we're
    > changing BLK_STS_RESOURCE to mean a non-path error.
 
   >>> most resource errors are per-path, so blindly changing this is wrong.
    
  >>> That's why I really just wanted to decode the nvme status codes inside
  >>>  nvme instead of going through a block layer mapping, as that is just
  >>> bound to lose some information.
    
It wasn't my intention to turn NVME_SC_CMD_INTERRUPTED into non-path related error.
The goal was to make the command retry after CDR on the same controller.  So why 
does this patch change the meaning of BLK_STS_RESOURCE?

/John

Re: [PATCH] nvme: Add support for ACRE Command Interrupted status

[Keith Busch]

On Wed, Nov 27, 2019 at 03:29:58PM +0000, Meneghini, John wrote:
> On 11/26/19, 11:24 AM, "Christoph Hellwig" <hch@lst.de> wrote:
>     > I agree we need to make this status a non-path error, but we at least
>     > need an Ack from Jens or have this patch go through linux-block if we're
>     > changing BLK_STS_RESOURCE to mean a non-path error.
>  
>    >>> most resource errors are per-path, so blindly changing this is wrong.
>     
>   >>> That's why I really just wanted to decode the nvme status codes inside
>   >>>  nvme instead of going through a block layer mapping, as that is just
>   >>> bound to lose some information.
>     
> It wasn't my intention to turn NVME_SC_CMD_INTERRUPTED into non-path related error.
> The goal was to make the command retry after CDR on the same controller.  So why 
> does this patch change the meaning of BLK_STS_RESOURCE?

What I meant by a "non-path error" is that those types of errors for
nvme go through the "normal" requeuing that checks CRD. The failover
requeuing does not check CRD. But thinking again, I don't see why the
failover side can't also be CRD aware.

Re: [PATCH] nvme: Add support for ACRE Command Interrupted status

[Meneghini, John]

On 11/27/19, 2:09 PM, "Keith Busch" <kbusch@kernel.org> wrote:
    >> It wasn't my intention to turn NVME_SC_CMD_INTERRUPTED into non-path related error.
    >> The goal was to make the command retry after CDR on the same controller.  So why
    >> does this patch change the meaning of BLK_STS_RESOURCE?
    
    > What I meant by a "non-path error" is that those types of errors for
    > nvme go through the "normal" requeuing that checks CRD. The failover
    > requeuing does not check CRD. But thinking again, I don't see why the
    > failover side can't also be CRD aware.

Yes, the failover side can be CRD aware, but I don't see the point in failing
over to a different path when CRD is set.  As you said, this isn't a pathing
error.  

We can argue about whether the command is retried on the current controller
or a different controller, but CRD must be observed before the command is retried.

Agreed?

/John

Re: [PATCH] nvme: Add support for ACRE Command Interrupted status

[Hannes Reinecke]

On 11/26/19 5:05 PM, Keith Busch wrote:
> [cc'ing linux-block, Jens]
> 
> On Tue, Nov 26, 2019 at 02:36:50PM +0100, Hannes Reinecke wrote:
>> This patch fixes a bug in nvme_complete_rq logic introduced by
>> Enhanced Command Retry code. According to TP-4033 the controller
>> only sets CDR when the Command Interrupted status is returned.
>> The current code interprets Command Interrupted status as a
>> BLK_STS_IOERR, which results in a controller reset if
>> REQ_NVME_MPATH is set.
> 
> I see that Command Interrupted status requires ACRE enabled, but I don't
> see the TP saying that the CQE CRD fields are used only with that status
> code. I'm pretty sure I've seen it used for Namespace Not Ready status
> as well. That would also fail MPATH for the same reason as this new
> status...
> 
No, true, CRD is not directly related to 'command interrupted'.
According to the powers that be CRD evaluation is depending on the ACRE 
setting (and hence should be evaluated whenever a command needs to be 
retried), but 'command interrupted' will only be returned if ACRE is 
enabled.
Consequently, whenever you get a 'command interrupted' you need to check 
the CRD setting to figure out the delay.

>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
>> index 108f60b46804..752a40daf2b3 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -201,6 +201,8 @@ static blk_status_t nvme_error_status(u16 status)
>>   	switch (status & 0x7ff) {
>>   	case NVME_SC_SUCCESS:
>>   		return BLK_STS_OK;
>> +	case NVME_SC_COMMAND_INTERRUPTED:
>> +		return BLK_STS_RESOURCE;
>>   	case NVME_SC_CAP_EXCEEDED:
>>   		return BLK_STS_NOSPC;
>>   	case NVME_SC_LBA_RANGE:
>> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
>> index d688b96d1d63..3a0d84528325 100644
>> --- a/include/linux/blk_types.h
>> +++ b/include/linux/blk_types.h
>> @@ -84,6 +84,7 @@ static inline bool blk_path_error(blk_status_t error)
>>   	case BLK_STS_NEXUS:
>>   	case BLK_STS_MEDIUM:
>>   	case BLK_STS_PROTECTION:
>> +	case BLK_STS_RESOURCE:
>>   		return false;
>>   	}
> 
> I agree we need to make this status a non-path error, but we at least
> need an Ack from Jens or have this patch go through linux-block if we're
> changing BLK_STS_RESOURCE to mean a non-path error.
> 
Alternatively we can define a new return value, if we shouldn't re-use 
existing ones. Either way I'm fine with.

>> diff --git a/include/linux/nvme.h b/include/linux/nvme.h
>> index f61d6906e59d..6b21f3888cad 100644
>> --- a/include/linux/nvme.h
>> +++ b/include/linux/nvme.h
>> @@ -1292,6 +1292,8 @@ enum {
>>   
>>   	NVME_SC_NS_WRITE_PROTECTED	= 0x20,
>>   
>> +	NVME_SC_COMMAND_INTERRUPTED	= 0x21,
> 
> This command status was actually already defined in commit
> 48c9e85b23464, though with a slightly different name.
> 
Ah. Will be modifying the patch then.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare@suse.de                              +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

Re: [PATCH] nvme: Add support for ACRE Command Interrupted status

[Meneghini, John]

On 11/26/19, 11:32 AM, "Hannes Reinecke" <hare@suse.de> wrote:
    On 11/26/19 5:05 PM, Keith Busch wrote:
    > [cc'ing linux-block, Jens]
    >
    > On Tue, Nov 26, 2019 at 02:36:50PM +0100, Hannes Reinecke wrote:
    >> This patch fixes a bug in nvme_complete_rq logic introduced by
    >> Enhanced Command Retry code. According to TP-4033 the controller
    >> only sets CDR when the Command Interrupted status is returned.
    >> The current code interprets Command Interrupted status as a
    >> BLK_STS_IOERR, which results in a controller reset if
    >> REQ_NVME_MPATH is set.
    >
    > I see that Command Interrupted status requires ACRE enabled, but I don't
    > see the TP saying that the CQE CRD fields are used only with that status
    > code. I'm pretty sure I've seen it used for Namespace Not Ready status
    > as well. That would also fail MPATH for the same reason as this new
    > status...
    >

    > No, true, CRD is not directly related to 'command interrupted'.
    > According to the powers that be CRD evaluation is depending on the ACRE
    > setting (and hence should be evaluated whenever a command needs to be
    > retried), but 'command interrupted' will only be returned if ACRE is
    > enabled.

Yes, we had a long debate about this with Fred.  CRD does not require the Command
Interrupted status, but Command Interrupted requires CRD.

   > Consequently, whenever you get a 'command interrupted' you need to check
   > the CRD setting to figure out the delay.

Whenever _any_ CQE sets CRD and clears DNR the host is required to implement
the delay.  The requirement is on the controller to always set CRD when Command
Interrupted status is returned.

Also, the host is required to handle Command Interrupted if it enables ACRE.

But then that's the bug....

    >> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
    >> index 108f60b46804..752a40daf2b3 100644
    >> --- a/drivers/nvme/host/core.c
    >> +++ b/drivers/nvme/host/core.c
    >> @@ -201,6 +201,8 @@ static blk_status_t nvme_error_status(u16 status)
    >>      switch (status & 0x7ff) {
    >>      case NVME_SC_SUCCESS:
    >>              return BLK_STS_OK;
    >> +    case NVME_SC_COMMAND_INTERRUPTED:
    >> +            return BLK_STS_RESOURCE;
    >>      case NVME_SC_CAP_EXCEEDED:
    >>              return BLK_STS_NOSPC;
    >>      case NVME_SC_LBA_RANGE:
    >> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
    >> index d688b96d1d63..3a0d84528325 100644
    >> --- a/include/linux/blk_types.h
    >> +++ b/include/linux/blk_types.h
    >> @@ -84,6 +84,7 @@ static inline bool blk_path_error(blk_status_t error)
    >>      case BLK_STS_NEXUS:
    >>      case BLK_STS_MEDIUM:
    >>      case BLK_STS_PROTECTION:
    >> +    case BLK_STS_RESOURCE:
    >>              return false;
    >>      }
    >
    > I agree we need to make this status a non-path error, but we at least
    > need an Ack from Jens or have this patch go through linux-block if we're
    > changing BLK_STS_RESOURCE to mean a non-path error.
    >
    > Alternatively we can define a new return value, if we shouldn't re-use
    > existing ones. Either way I'm fine with.
  
It seems to me that the block layer is never going to see BLK_STS_RESOURCE unless 
nvme_req(req)->retries run out... and at that point it doesn't matter, does it?

What's the result if the controller returns Command Interrupted status
for the same request repeatedly and we returning BLK_STS_RESOURCE
after nvme_max_retries?

/John