Re: [PATCH 20/20] scsi_error: format abort error message

Hannes Reinecke
2014-09-14T10:49:39Z

On 09/13/2014 03:07 AM, Elliott, Robert (Server Storage) wrote:
>> -----Original Message-----
>> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
>> owner@vger.kernel.org] On Behalf Of Christoph Hellwig
>> Sent: Friday, 05 September, 2014 7:33 PM
>> Subject: Re: [PATCH 20/20] scsi_error: format abort error message
>>
>> On Wed, Sep 03, 2014 at 12:06:15PM +0200, Hannes Reinecke wrote:
> ...
>>> Decode the return value if the command abort failed.
>>> @@ -157,8 +157,8 @@ scmd_eh_abort_handler(struct work_struct *work)
>>> } else {
>>> SCSI_LOG_ERROR_RECOVERY(3,
>>> scmd_printk(KERN_INFO, scmd,
>>> - "scmd %p abort failed, rtn %d\n",
>>> - scmd, rtn));
>>> + "scmd %p abort failed, rtn %s\n",
>>> + scmd, scsi_retval_string(rtn)));
> ...
>> I've not seen an answer to my question in reply to the previous version
>> of this. Why would you do pretty printing of a variable that can just
>> return SUCCESS or FAILURE?
>
> Is there anything prohibiting the scsi_eh_abort_handler provided by
> the LLD from returning any of the other values like NEEDS_RETRY?
>
> #define NEEDS_RETRY 0x2001
> #define SUCCESS 0x2002
> #define FAILED 0x2003
> #define QUEUED 0x2004
> #define SOFT_ERROR 0x2005
> #define ADD_TO_MLQUEUE 0x2006
> #define TIMEOUT_ERROR 0x2007
> #define SCSI_RETURN_NOT_HANDLED 0x2008
> #define FAST_IO_FAIL 0x2009
>
There is not, and hence I've added this patch.
Although the intention here would be that we should be
enforcing it, either by stating it in the description
of the function or programmatically.

Cheers,

Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html